4 Key Stages Of The Product Development Process
As product managers, we're constantly building, launching, and iterating on products, features, and use cases.
Along the way, we make a sequence of decisions about what to build, how to build, and how to improve and iterate on our features and products.
We can broadly classify these decisions into four stages of the product development process:
Most product and feature work tend to go through these stages of development, often in a linear fashion.
While there are exceptions, these stages of the product development process provide a good mental model to evaluate and classify decisions.
When we follow a project or product from conception to design to execution to launch, we can see that these decisions begin to stack up on each other.
Our choices about what problems to solve inform what functionality we prioritize in our features, or how we can improve their performance.
Since these decisions build on each other, it's important to understand what assumptions we're operating under, what facts we already have, and what past decisions we've already made.
Now let's review the stages of product development in more detail!
Product Development Stage 1: Discover
The first product development stage is Discover, or the process of defining what problems you want to solve, and for whom you want to solve them.
A useful analogy here is to think of yourself as an explorer, setting out on an expedition to a place you've never visited.
You have reason to believe it exists, but you haven't seen it yourself yet.
You want to go experience it and learn everything you can about the shape of the land so that you can eventually draw a useful map of the area.
Before you can draw a full map, you need to draw a boundary around the place you want to map.
This is the first major stage of exploring and map-making and thus, the broadest.
Now let's turn this back into product manager speak. In Discover, you want to learn about consumer behavior and the problems they face.
You likely have reason to believe there is a problem here worth looking into, probably based on some sort of hypothesis you have or part of the product strategy of your company.
At this stage, you focus on getting your bearings—learning what you need to in order to identify what you can and should solve.
A lot of the questions you are asking at this stage help you better understand users so you can define a problem: what are they doing, how are they doing it, and why are they doing it?
Product Development Stage 2: Design
The second stage of the product development process is Design or the process of defining how we want to solve the problem.
Let's go back to the explorer metaphor. In the Discover stage, you selected an area to map.
You've gone to that new place and have learned a lot about it. Importantly, you have been able to draw boundaries on this map. In the design stage, you start to focus on those boundaries and figure out what kind of map you're going to make.
Maybe it's a topographical map that shows elevation because there's a big hill and people will want to know that.
Maybe it's a map of who already lives there and what languages they speak.
Or it could be a map showing climate or helping with navigation.
Turning this back to business speak, in the design stage you already know which problem you want to solve, but this is where you define and explore various solutions to the problem.
A lot of the decisions you make will be about solution exploration and prioritization: which options make the most sense, and where should we invest?
Then, as you move through this stage, you can start to narrow in even more on which solution you want to build and what that solution should look like.
Product Development Stage 3: Develop
The third stage of the product development process is to actually Develop the solution and get it ready for launch.
In the discover stage, you selected an area to map; and in the design stage, you decided that you were going to make a navigational map.
Now, as you move into the next stage, you’ve started building a navigational map, and you’re adding color to it. You have something that you think might function, but you need to test if this map is usable.
For example, perhaps you ask an explorer friend to use the map and see if they can navigate to the same place. However, maybe they tell you that the map is hard to use because you hadn't included a scale on it.
You then include a scale on the next version of the map and try again. This helps you get closer to a point where you feel ready to share the map more broadly.
Now, let’s go back to business examples. In Develop, you have already built a version of the solution, even if it is an
You want to find out if and how well it works—if it does the thing you want it to do in a somewhat-controlled setting.
At this development stage, you are making decisions about usability and readiness: does the solution work well enough, and can a user satisfactorily complete this task? The corresponding approaches for this stage help you get feedback on whether the prototype is usable.
You may end up doing this research in pieces; for example, you could ask whether this menu works, whether this menu works as part of the interaction, or whether the whole interaction works.
But then, as you move through this stage, you eventually get to a point of confidence that this solution does work and is ready for a broader audience beyond your test group.
Product Development Stage 4: Deploy
The fourth development stage, Deploy, is the process of evaluating whether your solution was effective, and deciding whether and how to iterate on and optimize this feature.
Now, as an intrepid explorer-slash-mapmaker, you've already gone through a couple of iterations of the map, and you felt like you got to the point where the map was ready for the rest of the world. So, you've made it available to the broader public and want to evaluate how it's doing.
This means you are now in Deploy! Do people choose to use your map? Why or why not? Are you hearing anything about what could make the map better? Are those changes worth implementing?
At this stage, you are now at the point where you have shared your solution with the world. Here, you can learn more about how it performs in the real world.
Is it achieving its goal?
Are people using it or not?
Why or why not?
Answering these questions is the first step to understanding whether (and to what extent) you should invest in making this thing better, and then how you can go about doing that.
As you move through this stage, you will gain a better understanding of what is next for your solution, whether this means doing nothing, optimizing it in some way, or perhaps even scrapping it.
Identifying Your Stage Of Product Development
To prevent assumptions from leading us to the wrong stage of product development, we have developed a diagnostic toolkit to help assess your stage of development.
It consists of a set of 4 diagnostic questions that will help you uncover the assumptions that exist, and stress-test your confidence in them. The questions are:
Do you have a well-defined user problem?
Do you know how you'll solve the problem?
Do you know if your solution is usable?
Do you know how your solution works in the real world?
If you don't have confidence in your answer, then focus your research on that stage of development—and if you do have confidence, move forward to the next stage of development.
Additionally, there are three principles to remember as you assess your stage of development:
First, most teams move from left to right through the stages over time.
For example, as you continue to learn, you will normally move from choosing a problem to address, to deciding how you will solve that problem, to building a prototype, to launching the solution into the world.
Second, teams often loop back from the deploy stage to one of the other stages as they iterate on their feature or product.
As you learn more about how the solution is working in the real world, you make decisions about what to do next, which can lead you to loop back to Discover or to another stage depending on what path forward you are choosing.
Third, as you move from discovery to deployment, your decisions begin to tree out over time and you narrow your focus on one branch of that tree.
For example, one Discover decision (what is the problem) can conceivably lead to multiple Design decisions (which solution should we prioritize). This can grow almost exponentially, yielding a bunch of related decisions (and corresponding research) that you will have to manage and prioritize over time.
Wrap-Up
A lot of Product Managers don't invest enough time in making decisions at the Deploy stage. They often think their job ends once the solution has been launched and its performance has been reported.
But, in reality, the best Product Managers follow through with their solution by evaluating whether and how to improve and optimize their solution.