The Product Development Process: Discovery
How product teams build awesome products, part 1 of 2
This post was part of my recent guest lecture at MIT, and I’m about to share that entire Crash Course on Product Management right here, free. Don’t miss it, subscribe.
Have you ever wondered, “How do great products come to life? How do they go from idea to launch?”
Well, let me tell you:
As a product manager, I usually wake up with a brilliant idea which I quickly jot down on a Post-it Note. I hand it to the engineering team when I get to the office. They immediately understand and start coding, and two weeks later, we launch with massive success.
Sigh… If only it were that easy.
Modern product teams follow a lengthy product development process to figure out the right thing to build, then build it, test it, and get it ready to launch. The end-to-end process can take weeks or months and requires way more preparation than you can fit on a Post-it Note.
Sometimes the process is called the “Product Development Life Cycle” or “PDLC,” not to be confused with the “product life cycle” model; that’s different. The “Software Development Life Cycle” (SDLC) is also different because it’s specific to software products and focuses more on the engineering and technical activities involved.
The product development process is the modern way to bring new products and features to life. Everyone on the product team (PM, engineers, designers, UXR, data analysts, PMM, etc.) is involved in this process, and the product manager is their guide.
The process is standard. It might look different at your company because there are more or fewer steps and they might have different names, but it’s roughly the same work wherever you go. However, my formula is the best, obviously. 😊
My experience is primarily with building software products, and that’s what we’ll focus on here. I like to think about the product development process as six phases:
Define the opportunity
Design the solution
Build the solution
Prepare for launch
Launch 🚀
Learn, Maintain, Improve
Notice that phases 1 and 2 are bucketed into “discovery,” you’ll hear that term a lot because it’s when product teams discover the most important user problem to solve and how to solve that most important problem. The next phases (3, 4, & 5) are called “delivery,” which is all the work to ship or “deliver” that most important solution to your customer.
(You can read more about the origin of the terms “discovery” and “delivery” here.)
You’re here to learn about discovery (phases 1 & 2). We’ll break down why each step is useful, your role as the PM, and what outcome you should aim for.
Phase 0: Aim
Too many product managers start their magical journey of discovery with grand plans to build, only to be told that their discovery was completely disconnected from the company’s objectives.
Before building anything, know the objectives.
For now, we’re focusing on projects and launches, and how to use the product development process to come up with feature ideas and launch them. We’re assuming that someone has already done a lot of work to define the business objectives: roadmap, goals, product strategy, product vision, and company mission. (Smash that Subscribe, because we’ll cover these important topics soon.)
Even if you’re working on a small project, it has to ladder up through this chain of objectives to be valuable to the company. We’re running a business here, people. Everything we invest in building needs to align with company goals.
Without aiming toward these objectives, the product development process could create value for the customer without creating value for the business. Those are called distractions. They're shiny and fun, but too many distractions can lead a business to death.
Ok, let’s aim toward our objectives to lead our business to success 🎉, not death 💀.
Now it’s time to talk about the exciting product development process. Here we go!
Phase 1: Define the opportunity
Identify the most impactful problem you can solve for your customers.
Why defining the opportunity is important
Before jumping to solutions, we have to make sure we’re solving the right problem (or “opportunity” if we want to put a positive spin on it). The right problem is one that you understand clearly, that you’ve confirmed as something your users/customers actually care about, and that your technology and business are uniquely positioned to solve.
A lot of teams skip this phase entirely, and that’s why there are so many products that people don’t care about. So don’t skip this step.
Starting with the problem does two critical things:
It forces you to validate that there is a real market need for whatever solution you come up with.
When you start with the problem space, it gives your team more room for creativity. You’ll all think bigger about the possibilities and come up with better solution ideas if you don’t limit yourself to the first solution you think of.
So in this phase, you’ll choose the right problem to solve and determine the Who, the What, and the Why for your launch.
What you should do
In this first phase, you’ll do most of the work. As the product manager, it’s your job to determine what problem(s) is most important for your team to solve, who you are solving it for, and why you should solve it. Other members of your team, especially engineers and designers, should provide input, but at this phase, you are in the driver’s seat for the project.
Things you’ll typically do in this phase:
Clearly articulate the problem that your customers are facing. Product managers deeply understand who their customers are and what they care about. You must be able to describe the problem users are struggling with and explain the opportunity to your colleagues.
Build a business case to show why it’s valuable for your company to invest in solving this problem. Show how a solution to the problem fits into the company’s strategy and goals and how it will bring value to the business.
Research and ideate–yes, PMs talk like this, sorry–to give your team options of what a solution could look like. Spark creativity and show that a solution is possible, but remember to focus on the problem space (not the solution space) for now. User research and validating assumptions may start here and continue into the next phase.
Decide when the work should happen. Where does this fit into your existing roadmap? Should your team aim to design and build a solution this quarter? Next quarter? It is probably too early to know how much work will be involved to build the solution (because you haven’t decided on a solution yet, right? 😉), but having a rough estimate for timing will help you get the approvals you’ll probably need.
And speaking of approvals, you’ll need to get buy-in from your team, cross-functional stakeholders, and leadership to start designing a solution (next phase). Your company might have a process where you need approval from leadership before your team moves forward with designing solutions; if that’s the case, you might need to write a formal proposal or present a strategy that includes solving this problem. Even if you don’t need formal approval, it’s still critical that you can influence your team, stakeholders, and leadership and convince everyone that this opportunity is worth pursuing.
📚 Build that skill 📚
Influence without authority is a critical product manager skill that you’ll need to get through the entire product development process, but especially to get past this first phase. If you’re new to Product or an experienced PM struggling to influence, check out my course, Product Influence, to build that skill.
📚 📚 📚 📚 📚
Outcome
Here’s what you want from phase 1:
☑️ A clearly defined user problem (explaining what and who)
☑️ Rationale for why your company should invest in solving this problem (the why)
☑️ Enough information for your team to explore possible solutions (which you’ll do in phase 2)
☑️ Buy-in from your team and approval from leadership and/or stakeholders if your company requires it
You might have ideas for potential solutions at the end of this phase, but you shouldn’t be locked in on a single solution. The next phase is all about designing & validating the best solution(s).
Phase 2: Design the solution
Before writing any code, design and validate possible solutions to your customer’s problem.
Why designing the solution is important
The goal here is to find the best viable solution(s) to solve the problem, as a team. To find the best viable solution, you’ll come up with lots of possible solutions to the user problem and weed out the bad ideas.
What your team is doing
In phase 1 you figured out what the problem is, who the customer is, and why it’s important, now it’s time for teamwork. Now the designers and engineers can design the how.
In this phase, Design and Engineering will figure out the following:
How the solution should look,
How customers should interact with it, and
How it should be built.
The designers will create wireframes and low-fidelity to high-fidelity designs to show how the solution will look. The engineers might need to write a Technical Design Document (TDD) to describe how to build the solution.
Note: a TDD explains the service architecture and how this new thing will fit into your existing codebase.
A giant design mistake
The “Design” phase is just as much about designing a technical solution as it is about designing UI & UX. A common mistake is to take this phase literal, and leave engineering out of the “Design” phase.
Two big problems may occur if engineering is excluded from the Design phase:
If engineers don’t plan (design) the technical solution, they could break things when they start building (in phase 3). To prevent problems, the engineers on your team can coordinate with other teams to make sure their technical solution fits nicely into the rest of the codebase and stands the test of time–which may not be long in tech, but you get the point.
Our fantastic design with gorgeous UI may be fantastically unrealistic for your timeline. It’s best to find out about feasibility from engineering up front before you waste everyone’s time with a UI design that takes too long to build.
What you should do
Your job in this phase is to make sure the how lines up with the who, what, and why–which you clearly defined in the last phase.
You’ll usually be the decision-maker or tie-breaker when there are disagreements in your team. You should expect the designers and engineers to often come back to you with questions about the problem you’re solving – either looking for clarification about something unclear or missing from the plan or to discuss a change in direction from the original plan that may be necessary. It’s your job to ensure the solution design aligns with the vision you defined in the opportunity phase.
As your team comes up with potential solutions, work with them to validate those solutions as much as possible to separate good ideas from bad ones. The goal is to de-risk the solution before any time is spent on building it. The best way to do this is to focus on answering these four questions, which Marty Cagan laid out in his book Inspired:
Will the user buy this (or choose to use it)? (Value risk)
Can the user figure out how to use it? (Usability risk)
Can our engineers build this? (Feasibility risk)
Can our stakeholders support this? (Business viability risk)
Take the lead to de-risk the above questions. You’ll need help from your design and engineering partners to answer #2 and #3, and you’ll have to talk to users and business stakeholders to answer the rest.
Another big role you’ll play at this stage is to get all the necessary approvals for your team’s solution design. There might be an approval process with leadership or launch approvers like Security, Privacy, and Legal teams. It’s also a good idea to give your team’s key stakeholders a preview of what you’re planning to build so that they’re not surprised, and so they can give you valuable feedback.
Outcome
When this phase is complete, you should have the following:
☑️ UI/UX and technical designs for a solution to the customer problem your team has decided to solve.
☑️ Evidence that your chosen solution is a good idea, based on research and discussion with stakeholders to de-risk the solution as much as possible.
☑️ You’ll probably have a completed Product Requirements Document (PRD) at this point, which includes a description of what you’re planning to build, clear requirements for the solution, and all the de-risking info you’ve compiled.
☑️ Approval from leadership to build the solution, if your company requires it.
In a nutshell
I’ve gone into detail in this post to make sure you’re thinking deeply about the problem space and testing your assumptions about the solution ideas you have, so it might sound like you need to spend weeks on phases 1 and 2 before you can build anything. Not true. For small launches with just a few people on your team, you could get through these phases in hours, not weeks. The point is to make sure you’re thinking through each phase.
The discovery stage of the product development process is what separates great product teams from the rest. By focusing on the problem (phase 1) and working as a team to generate and validate solution ideas (phase 2), you’ll end up with much better products. It’s tempting to jump straight into building a solution, especially when you wake up with what feels like the most brilliant idea ever, but taking a moment to make sure you're solving the right problem and validating your idea is critical.
Bookmark this guide to help you navigate the discovery stage of the product development process. And don’t miss next week’s post, where we’ll dive into the rest of the product development process.
You got this!