Product strategy frameworks are tools for answering specific questions: where to grow, what customers need, what to build next and whether the product is improving. Used for the wrong question, they produce confident-looking but meaningless answers. This guide maps the common frameworks to the questions they answer, checks each against its original source, and works through a prioritisation example with numbers you can verify.
Start with the strategy stack
Frameworks sit inside a hierarchy. If a higher level is missing, no framework below it will rescue the plan.
- Vision: the change you want to create for customers over several years.
- Strategy: where you will play (which customers and problems) and how you will win (why they will choose you).
- Roadmap: the sequence of bets that carries out the strategy over the next few quarters.
- Backlog: the specific features and fixes, prioritised.
Most frameworks people quote in interviews, such as RICE, work at the backlog level. Strategy questions need different tools.
Keep preparing
Continue with Sarkari Resume Templates₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coachingMatch the framework to the question
| Question you need answered | Framework | What it produces |
|---|---|---|
| Where should we grow? | Ansoff matrix (existing or new products × existing or new markets) | A choice between market penetration, market development, product development and diversification |
| What are customers really trying to get done? | Jobs to be done | Job statements in the customer's words, and the circumstances in which a job arises |
| Which features are expected, and which delight? | Kano model | Features grouped as must-be, performance, attractive or indifferent |
| What should we build next? | RICE scoring | A ranked backlog with explicit assumptions |
| Is the user experience improving? | HEART | Metrics for happiness, engagement, adoption, retention and task success |
| Where are users dropping out of the funnel? | AARRR (acquisition, activation, retention, referral, revenue) | Conversion rates at each stage |
The frameworks, checked against their sources
Jobs to be done. Clayton Christensen and co-authors set out the idea in the Harvard Business Review article "Know Your Customers' 'Jobs to Be Done'" (September 2016). The core idea is that customers "hire" a product to make progress in a particular circumstance. The practical output is interview-based: ask about the last time someone faced the problem, what they tried, and what made them switch.
HEART. Kerry Rodden, Hilary Hutchinson and Xin Fu described HEART in the paper "Measuring the User Experience on a Large Scale", presented at CHI 2010. The paper pairs the five categories with a process for mapping product goals to metrics. Start from the goal, not from the data you happen to have.
RICE. Sean McBride introduced RICE on the Intercom blog in January 2018. As defined there:
- Reach: how many people a feature will affect in a defined period.
- Impact: a scale of massive = 3, high = 2, medium = 1, low = 0.5 and minimal = 0.25.
- Confidence: high = 100%, medium = 80%, low = 50%.
- Effort: person-months, with half a month as the minimum.
The score is reach × impact × confidence ÷ effort, which the article describes as total impact per time worked. (Some secondary sources give minimal impact as 0.1. The original uses 0.25.)
Kano model and Ansoff matrix. The Kano model, developed by Noriaki Kano, sorts features by how their presence or absence affects satisfaction. Igor Ansoff's growth matrix comes from his 1957 Harvard Business Review article on diversification strategies. Both are best used as discussion tools rather than scoring systems.
Worked example: RICE for a bill-payments app
The app, features and numbers below are illustrative.
A product team at a bill-payments app is choosing what to build next quarter. It estimates reach in users per quarter:
| Feature | Reach | Impact | Confidence | Effort (person-months) | RICE score |
|---|---|---|---|---|---|
| A. Bill-due reminders | 40,000 | 1 | 80% | 2 | 16,000 |
| B. Hindi and Tamil interface | 25,000 | 2 | 50% | 4 | 6,250 |
| C. Fix failed receipt downloads | 60,000 | 0.5 | 100% | 1 | 30,000 |
Checking the arithmetic:
- A: 40,000 × 1 × 0.8 ÷ 2 = 16,000
- B: 25,000 × 2 × 0.5 ÷ 4 = 6,250
- C: 60,000 × 0.5 × 1.0 ÷ 1 = 30,000
So the ranking is C, then A, then B.
The real value is in what the scores reveal. Feature B scores low mainly because of 50% confidence. If research confirmed the reach and impact (confidence 100%), B would score 12,500, still below A. But if that research also showed that 50,000 users would use the new languages, B would score 25,000 and overtake A. The right next step is therefore not "build C, then A". It is "build C, and spend a week of research checking B's reach". RICE has told you which assumption to test.
Common mistakes
- Using a backlog tool for strategy. RICE can rank features but can't tell you which market to enter. Use Ansoff or jobs-to-be-done thinking for that.
- Hiding guesses in decimals. Write down where each reach and impact estimate came from. A precise-looking score built on guesses misleads the team.
- Measuring what's easy instead of what matters. HEART works when each metric traces back to a goal you've written down.
- Interviewing only your current users. Jobs-to-be-done research should include people who tried your product and left, and people who chose an alternative. If your users span several languages, interview in those languages.
- Treating frameworks as answers. They structure a discussion. The decision, and the reasoning behind it, is still yours to explain.
A one-page product strategy template
- Vision: one or two sentences.
- Target customer and job: who, in what circumstance, trying to make what progress.
- Where to play and how to win: the choice, and why it beats the alternatives.
- Bets for the next two quarters: three to five, each with the metric it should move.
- Prioritised backlog: the top ten items with RICE inputs and their sources.
- Measures: HEART or funnel metrics tied to the goals above.
- Assumptions to test: the riskiest estimates and how you'll check them.
Using this in product interviews
Product interviews often ask you to prioritise features or improve a product. Use the stack: state the goal first, choose the framework that fits the question, show your assumptions, and then say what you'd test before committing. Demonstrating why the inputs matter, as in the worked example, is more convincing than reciting the definitions.