Surprisingly, there isn’t a universal or formal definition of the product development lifecycle.
If you’re a product manager looking for a framework to structure your product development lifecycle, focus on these four key phases:
With over a decade of product management experience in early and growth-stage startups, I’ve been through this process more times than I can count!
The 4 Phases of The Product Development Lifecycle
There are two key stages: Finding a problem worth solving and defining a solution worth building.
Finding a problem worth solving is about understanding what your customer wants your help with. It’s about figuring out if there’s really a problem, how often it occurs, and whether it’s important enough that they would use your product to solve it.
When defining a solution worth building, you should be developing multiple solutions since the first thing you come up with probably won’t be that great. Don’t overcook these solutions; a rough wireframe, explanation, or prototype is plenty.
When evaluating each solution, a helpful framework to use from design thinking is what I call “DVF.” It’s a collection of three dimensions to assess your solutions against:
- Desirability – does the customer want to use your solution to solve their problem
- Viability – will this solution serve the business (i.e., make money either directly or indirectly)
- Feasibility – can you build & maintain it (work closely with your product engineers on this aspect)
Any solution worth building must be desirable, viable, and feasible.
In this phase, you prioritize your solutions worth building and defining a roadmap. Your solution should be evaluated and prioritized against your product strategy above all else. For example, if you have OKRs, your solution should directly address your key result.
A good roadmap will be well balanced and not unintentionally weighted towards anything – for example, being all easy projects.
This is where the product gets built. Look to scrum and kanban from Agile for guidance here. Be sure to take the time to create well-defined specs (related: Why I don’t write User Stories… and write Job Stories instead). Invest in QA. Keep your work in progress to a minimum to increase throughput and reduce stress on yourself and your team. Aim to work on one thing at once. If your company is big enough, avoid projects with only one engineer working on them. Be cautious about measuring velocity (instead, aim for velocity you can feel).
What was the impact of the solution? How is it measured? How does that compare to the goal set out in the beginning?
What did we learn about our customers, business, team, and processes?
What are we going to do differently on the next project?
What are we going to build next?