Product Development Process

Product Development is a difficult discipline to define. I think that the role differs very slightly in every type of business. It is often confused with project management, however I see them as very different disciplines.

For me a product manager is a number 2. The company founder is a number one, creating those kernels of ideas, the founder of a start-up. The product manager should take that kernel and make it happen – it is as simple as that.

Don’t get me wrong – product managers should be creative, understand their market and propose new feature development and of course many will invent entirely new products which will disrupt. However I believe that a good product manager should be a second in a business and should act as a hub, pulling all the threads inside a business together to create.

The process

I have found a real lack of resource online explaining at a high level the product development process. There are plenty of guides describing ‘creating’ a new product in the entrepreneurial sense, however developing a product is very different.

The following is the process that I go through as a product manager. I explain each of the steps in greater detail below.

EDIT: This is a great article explaining the need for customer research at an early stage in the planning process: ‘ How user research can help prioritise product requirements‘.


This is the starting point for any project. Bring together all your evidence, this could be market research, customer stories, bug reports or all of the above and start sketching out some ideas. You need to crystallise your idea before engaging stake holders, especially senior ones.


Now is the time to engage with your key stake holders. Take the result of your brainstorming and your evidence and get buy in. This may be the CEO, Product Director or MD – remember to provide as much evidence as possible.


With buy in you can start to describe what you want to develop at a high level and plan milestones for the development process from your perspective as a Product Manager. It is good to use visuals at his point, however you can use a spreadsheet or one of the various tools available to do this. You can start to predict a launch date at this point but remember that it will change following the technical planning stage. The roadmap is so important because it allows stake holders to gain a high level understanding of your development plan at any time. Essentially it is a great point of reference for the whole business.

Technical Planning

Time to engage with your technical teams, generally software developers and engineers. Review your roadmap with your engineers and begin to break apart your high level targets into individual development goals. At this point engineers may suggest new issues you hadn’t thought of so be flexible. You need to work with the tech teams to predict the number of man hours it will take to complete each goal. This will help you work up a deadline.


Bearing in mind the technical requirements group development goals into features vital for launch and features you can release later. Take the lean approach and work out what you can release quickly and which tasks may need to be broken down more. Your target is to create a feature list for launch based on the time estimates and business requirements you should understand at this point.


You’re almost at the development stage but before getting to work go back to your customer stories. It is good to reassess the original reasoning behind your product planning to make sure that the plan and roadmap you have created eventually lead to features and a product which will actually solve customer stories. If not, you need to rethink and go back to your technical planning stage to re-prioritise.


Hopefully you’re happy that you will anser some of your customer stories with your first code release so get the devs working to the plan. Make sure that you track progress and make a metric available to judge performance. Time is a good one… set targets and track progress and whether or not objectives are met.

Joe Gardiner
Joe Gardiner
Technical Architect

An experienced technical architect witha focus on vendor and MSP pre-sales.

comments powered by Disqus