Every Product Manager (PM) has experienced that Sunday night feeling: a mix of excitement and mild anxiety. You look at your backlog and see 150 “critical” feature requests, three different emails from the VP of Sales about a “deal-breaker” requirement, and a Slack thread from the engineering lead about technical debt that’s about to break the database. Your job isn’t just to manage this chaos; it’s to extract a rational, winning strategy from it.
In the world of product, ideas are cheap. Execution is expensive, but selection is the most valuable skill of all. It is important for PMs to decide what not to build vs. what to build. In this article, we will deep dive into how PMs use structured and analytical judgements to create products from raw ideas that benefit both the business and the user.
Section 1: Understanding Market Needs
Before you even think about features, you have to think about problems. A common trap for new PMs is “solutioning”—jumping”straight to a cool feature idea before truly understanding if a market gap exists.
The Difference Between Want and Need
Users are great at telling you what they want, but they are often terrible at telling you what they need. If you asked a commuter in 1900 what they wanted, they’d say a faster horse. A PM’s job is to see the need for a car.
We often use the Jobs to be Done (JTBD) framework to identify these needs, which is based on the core idea that people do not buy products; instead, they hire them to perform a job, such as solving a problem or fulfilling a desire.
Identifying the Market Gap
Market research involves looking at the competitive landscape not just to see what others are doing, but to see what they are ignoring.
- The Over-served Market: Competitors are adding so many features that the product has become bloated and expensive. The gap here is for a “disruptive” lite version.
- The Under-served Market: Users are hacking together manual workarounds (like using Excel for everything) because no dedicated tool exists.
Case Study: The Rise of Zoom
Prior to Zoom, the video conferencing services were dominated by giants such as Webex and Skype. Most PMs would have argued that the market is already saturated. However, Eric Yuan identified a gap: the existing tools were unreliable and required heavy downloads. The “market need” wasn’t just video calling; it was frictionless video calling. Zoom focused on “one-click to join” feature that the incumbents had ignored.
Section 2: Gathering and Analysing Data
Think of data as a PM’s armor. It’s what stops you from getting steamrolled by the loudest person in the meeting, usually the “HiPPO” (Highest Paid Person’s Opinion).
However, there is a significant difference between being data-driven and data-informed. Those who are data-driven rely on a spreadsheet to make their decisions, while those who are data-informed incorporate their gut instincts and genuine human empathy into their decision-making process.
Quantitative Data: Figuring out the “What”
This is all about scale. Numbers tell you what’s happening, even if they can’t tell you why.
- The Funnel: Where are you losing people? If 80% of your users vanish the second they see the payment screen, you don’t have a “value proposition” problem, you have a broken checkout.
- Cohorts: Do the new sign-ups last longer than the seasoned users? This is the only method to determine whether the product is truly evolving or merely stagnating.
- Heatmaps: Tools like Hotjar are eye-opening. If users are constantly clicking a static icon that isn’t even a link, they’re telling you exactly what feature they want next without saying a word.
Qualitative Data: Digging into the “Why”
Even with the best charts, you may not know why users are upset.
- The “Five Whys”: When a user asks for “dark mode,” don’t just build it. Keep digging. You’ll probably find they’re using the app in bed, and the glare is killing their eyes. The real “need” here is eye strain reduction and accessibility, not just a UI color swap.
- Stop Leading the Witness: In interviews, skip the “Would you use this?” questions, everyone lies to be polite. Instead, try: “Walk me through the last time you actually got frustrated trying to do this.”
The Synthesis: Connecting the Dots
The best PMs use a “Triangulation” approach. They don’t just look at one metric; they look for where three different lines cross:
- A hard metric, for example: Retention just dipped by 5%.
- A raw user quote, for example: I can’t find the damn export button.
- Market context, for example: Our main competitor just launched one-click exports.
When those three things align, you aren’t guessing anymore. You’ve found your “Aha!” moment.
Section 3: Prioritization Frameworks
Once the ideas are gathered, the “Hunger Games” of product management begins. You have 50 great ideas but only enough engineering capacity for five. How do you choose without offending half the company? You use a framework.
The RICE Framework
RICE is the common standard used by many SaaS PMs because it forces you to quantify your gut feelings.
- Reach: How many people will this impact? For example, 5,000 users per month.
- Impact: How much will the change help the individual user? For instance, the impact can range from 0.25 to 3.
- Confidence: How sure are you about your reach and impact numbers? For example, 100% is high, and 50% is a best guess.
- Effort: How many “person-months” will it take? For instance, the answer could be 2 person-months.
Compute the score using the formula:
Score = (Reach X Impact X Confidence) / Effort
Suddenly, the CEO’s “cool idea” that only affects 10 people but takes 4 months to build gets a very low score, making it easier to say “not now.”
The Kano Model
Sometimes, prioritization isn’t about ROI; it’s about emotional resonance. The Kano Model categorizes features into:
- Basic Needs: If these aren’t there, the user is unhappy. For example: a Forget Password link.
- Performance Features: The more you provide, the happier the user. For example: faster storage.
- Delighters: Things the user didn’t ask for but loves. For example: a clever animation when they finish a task.
The Cost of Delay
A more business-centric approach is asking, “What happens if we don’t build this for another six months?” If the answer is “We lose a $2M contract,” that feature moves to the top of the list, regardless of its RICE score.
Section 4: Collaboration with Stakeholders
A PM has all the responsibility but often none of the authority. You cannot command engineers to build products or instruct sales teams to stop selling. You have to lead through influence.
Engineering: The Art of the Possible
The relationship between a PM and engineering should be a partnership, not a hierarchy. A common mistake PMs make is handing over a “requirement document” like a stone tablet. Instead, bring engineers into the “problem” phase to discuss the technical feasibility; for example an engineer might tell you that your “simple” feature requires a complete rewrite of the API. PMs should have the Trade-off Conversation with engineers for example, we can build Feature A in two weeks, or Feature B in two months. Which one gives the user more value right now?”
Design: The User’s Advocate
Designers aren’t there to make things “pretty.” They are there to make things “usable.” A PM and Designer must be in constant sync. The PMs focus is on the “What” and the “Why,” part of the feature while the Designer focus is on the “How.” Of the feature. If the user needs a user manual to understand the feature, it does not matter how high RICE score was for the feature, the feature has failed.
Sales and Marketing: The Reality Proof
Sales teams are under immense pressure to hit quotas. They often see the product as a toolkit for closing deals. A PM’s job is to listen to Sales to understand market trends but to remain firm on the long-term vision.
The “Roadmap” Meeting: Regularly present the “Why” behind the roadmap to Sales. If they understand that Feature X is being delayed to correct a stability issue that affects all their clients, they are more likely to support you.
Managing the “HiPPO”
The Highest Paid Person’s Opinion (HiPPO) can derail a product roadmap instantly. When an executive demands a feature, a structured PM doesn’t say “No.” They say, “That’s an interesting idea. Let’s see how it scores against our current priorities in the RICE framework.” Data is the best way to handle executive pressure gracefully.
Section 5: Iteration and Testing
In the old days of software development (the “Waterfall” era), you would spend a year building a product, release it, and pray! In contrast, we have now adopted agile methodologies. We build, we measure, we learn, and we iterate over and over again! This cycle is done until the market-product fit is achieved.
The MVP (Minimum Viable Product)
The MVP is the bare minimum you can build that allows you to learn. If you want to build a marketplace for second-hand cars, your MVP shouldn’t be a fully automated website with integrated financing. Your MVP might be a simple landing page where people can post their cars manually. If people use the landing page, you have “validated” the idea.
Prototyping and Pre-mortems
PMs should use high-fidelity prototypes (using tools like Figma) before the team starts writing the code. Watch a user try to use the prototype. If they get stuck on the second screen, you just saved your engineering team weeks of wasted work.
Another great tool is the Pre-mortem. This is team activity where the team members answer questions such as, “It’s one year from now and this feature has completely failed. Why did it fail?” This helps identify risks that your optimism might have blinded you to.
Post-Launch
Shipping is not the finish line, it is when the real work begins. Once a feature is live, a PM spends the next few weeks on the dashboard analysing the metrics such as:
- Adoption Rate: Are people actually using it?
- Retention: Do they come back to use it a second time?
- CSAT/NPS: Are they happy with it?
If the data shows the feature isn’t working, a brave PM isn’t afraid to “pivot” or even remove the feature. Every line of code you keep in the product is something you have to maintain forever. The PM has to decide if the code is not adding value, we need to get rid of it which can later lead to code debt.
Conclusion: The Impact of Structured Decision-Making
Product Manager work is not about looking into a crystal ball to develop future-directed visionary products; instead, it relies on a scientific approach to experimentation and a diplomatic approach to managing numerous cross-functional teams towards a common goal.
Using structured methodologies such as Jobs To Be Done (JTBD) for understanding data, RICE-based methods for prioritization, and Minimum Viable Product (MVP) approaches to validate your hypothesis removes the guesswork from product development, principles that are deeply emphasized in effective Product Management Training. You can progress from a hypothesis of “I believe it may work” to knowing, based on data and ongoing analysis, that the product being developed will address user problems.
That’s how you develop a product that not only exists in the marketplace but also adds value to users. As you look to develop new products and go through a huge number of prior requests, remember that while you are being inundated with requests from users who are attempting to access an application, your role is to identify the one pathway out of the cluttered requests that will get the user to the ultimate end-user destination.