Mastering the ‘why’ is a fundamental process in the daily reality of product managers. I’ve stressed it many times in the past.
It provides many benefits, such as:
- Understanding the real pains behind any capability or feature you consider promoting.
- Understanding the potential impact of solving these pains.
- Walking into any meeting confident that when peers challenge you, you can answer almost all their questions.
Yet, for sizable features, the process can become tedious and time-consuming. In such cases, the work is often called a “discovery process” or simply “research.”
Luckily, with the rise of AI, this is one of the main areas where you can get a real productivity boost. In the next post I’ll dive into how AI can help. First, we need to understand the overall process – today’s goal.
Scoping the journey
For anything larger than a minor tweak, “mastering the why” often means running a discovery process. I covered the fundamentals of the discovery process in depth here.
There I explained why discovery can be costly and outlined when it’s worth the investment. Today I’ll zoom out and list the areas of knowledge you must master to “own the why.”
As we’ll see, for many of the features you’ll work on, your previous research and knowledge still apply and don’t need revisiting. However, for medium-sized or bigger features, a discovery process is almost always necessary, and you’ll likely go through multiple stages.
Knowledge areas you need to master
After coaching numerous product managers through discovery, I distilled the required knowledge into five areas:
- Market
- Problem domain
- Personas
- Pains/needs
- Solution + UX/UI
Let’s briefly go over each:
Market
This phase covers what we know about the market our feature or product aims for.
It includes mastering:
- What this market is about
- Value and size of the market, including trends
- Which trends shape this market, and what forces drive them
- How we expect the market to evolve
Main output:
- TAM (total addressable market) and its key drivers
Problem domain
This phase covers the specific problem we aim to address, including main players solving similar issues, their success, and customer expectations.
It includes mastering:
- The competitive landscape
- Common solutions and the state of the art
- Customer expectations
Main output:
- The competitive landscape, best practices, and customer expectations
Personas
Once we understand the market and competitive landscape, it’s time to focus on who will use our product or feature.
Sometimes the persona is clear and rarely changes. But when entering a new market or segment, refining personas is essential.
This phase includes:
- Persona analysis (I dedicated a post here)
- Identifying your ICP (ideal customer profile)
- Identifying relevant jobs to be done (JTBD, covered in the same post)
Main outputs:
- Persona analysis (including JTBD)
Pains/needs
Understanding who uses our features opens the path to their pains. This is where the gold is.
Understanding true pains helps build laser-focused solutions likely to deliver significant impact. Yet, many product managers fail here because once they think they understand the pain, they stop.
Here’s an example inspired by a real mentoring session (facts slightly adjusted): Imagine your company develops an AI product for customer support. A customer asks to speed your AI solution’s response time from 6 hours to 15 minutes. When asked why, they mention it slows their workflow. Many PMs stop here, treating this reason as an axiom.
However, digging deeper into the customer support persona, workflow, and JTBD might reveal that only partial answers are needed quickly. The heavy lifting can happen later. Such understanding opens new opportunities.
This random but realistic example highlights the importance of deeper exploration.
Once we intimately understand the pain, we usually have a rough idea of what to build.
Main output:
- General outline of the solution
Solution + UX/UI
Finally, we consider the solution itself. By now, we understand the persona, problem, and positive impact of resolving it. Insights from previous stages, especially “pains,” already suggest how the solution should look.
In some cases, reaching feature parity with competitors suffices, requiring only minor adjustments to existing solutions. Often, though, interesting problems merit innovative solutions. This approach is more exciting but requires validation through official or implicit design partners or small MVP segments.
Generally, validation splits into:
- Feature set validation
- UX/UI validation
Validation may lead to usability testing, so bring your UX/UI designer along. Specific validation tools and methods will be covered in a future post. For now, your goal is ensuring the planned solution actually solves the pain – efficiently.
Main output:
- Validated solution
Stitching it all together
The diagram below summarizes the knowledge areas we discussed and their outputs, showing what you must master:
As seen, four of the five stages focus on mastering the “why” (understanding market forces, problems, pains, and affected personas). Only the final stage addresses the “what” – the solution itself.
This reinforces my ongoing point: the most important word for a product manager is “why.” Those naturally tuned to seeking reasons behind actions have great potential as product managers.
Summary – mastering the why
In this post, we covered the stages to master the “why” when considering a new solution, product, or major capability. As mentioned, not every feature requires all phases, as aspects like market, domain, and personas rarely change significantly.
Still, mastering the “why” is non-negotiable. Whether it takes five minutes or several weeks depends on the feature size, but it remains key to developing impactful, efficient features.
That wraps up this post. I’ll follow up with a post on how AI can accelerate your discovery process.
Until then – good luck with mastering the why!
If you liked this post and/or found it useful – don’t forget to ‘like’ it below and share it with your friends.