From Features to Users: How My Approach to Prioritization Changed
I was editing an article about prioritization I wrote three years ago and realized a lot has changed. Sharing an updated view.
Three years ago I wrote an article about how we prioritized product decisions back then.
If you like, you can dig it out of the archive — it’s all honest work: RICE, AAARRR, the Eisenhower matrix, quarterly research. At the time it was a working set of tools. We used it, it produced results, and I genuinely thought it was optimal.
A lot of time has passed since then, dozens of product launches and hundreds of conversations with teams. And here’s what I’ve realized: almost all of those tools have either lost their relevance or given way to more alive and flexible approaches.
So I decided to do what I’d been putting off for a long time: go back to the old article, reread it — and rewrite it so that it reflects the reality of 2025.
Below is my update. Same topics, different answers. If you want to compare with the original, start there and then come back here — the difference will be obvious.
TLDR: What I’d put in the article if I were writing it today
If you can’t be bothered to read, too many words — here’s the cheat sheet:
- RICE, AAARRR and the Eisenhower matrix now have more modern alternatives — in plenty of cases they work better. The article has been rewritten around what I actually use now.
- Instead of RICE — Teresa Torres’s opportunity solution trees: I prioritize user problems, and pick features afterwards.
- If a task doesn’t move a single key result for the quarter, it doesn’t get into the sprint.
- One North Star metric: value for the user and revenue for the business at the same time.
- Instead of the AAARRR funnel — metrics inside the product: time to first value, depth of use, willingness to pay.
- Continuous discovery: 2 hours of contact with users per week instead of quarterly reports.
- Outcome-based prioritization: first the target change in user behavior, then the list of features.
Opportunity Solution Trees instead of RICE
By Teresa Torres
Why it’s critical: In 2025 this is the standard for teams that actually talk to users rather than just pretending to.
What it’s about: Instead of prioritizing features, you prioritize user problems. You draw a tree: at the top — the business goal, in the middle — user problems (opportunities), at the bottom — ways to solve them (solutions).
How it works:
— Every week you talk to 2–3 users — You update the tree based on what you learned — You prioritize not “which button to add” but “which problem to solve first”
Example: a video calling team is about to prioritize new video filters. Interviews show that the main pain is “I can’t hear my colleagues.” Focus shifts to improving audio.
The difference from RICE: RICE helps you pick the best solution from a ready-made list. Opportunity solution trees help you understand whether your list is the right one.
Prioritization integrated with objectives and key results
What changed: We used to set objectives and key results in January and prioritize features every week. The connection between the two was at the level of “well, it probably has some effect.” It’s more effective when every task in the backlog is tied to a specific key result.
What it looks like: You open the task list — each item says which key result it affects and by how much. If a task doesn’t move any key result for this quarter, it doesn’t get into the sprint. Period.
Example: a note-taking tool team has the key result “increase the number of weekly active teams by 20%.” Two features in the backlog: new templates for personal planning, and improved commenting on shared pages. Under RICE both get similar scores. Under the OKR-based approach you pick commenting — it works toward team usage.
Tools: Dragonboat shows how your key result will change if you build a specific feature. ProductPlan draws a roadmap where you can see which features are tied to which result.
ProductPlan: Visualizing the connections
ProductPlan draws the roadmap like a mind map: at the center your objectives and key results, with branches going out to the features that affect them. You end up with a dependency tree where it’s immediately visible which parts of the roadmap work toward which goals.
If you have a feature that isn’t tied to anything — it’s hanging in mid-air, and it becomes obvious that either it needs to be dropped or the objectives and key results need to be revisited. Especially useful for large teams: when a frontend developer asks why we’re building this button, you show them the roadmap and explain how the button affects the quarterly key result on retention.
The main point: Quarterly cycles instead of annual ones. You break long-term projects into pieces so that you can see progress every quarter.
North Star metrics
The idea: Instead of balancing a dozen metrics, you pick one main one. You make all prioritization decisions through the lens of that metric. A North Star metric is the one main metric that reflects your product’s value to users. If that metric is growing, the product is becoming more useful. If it’s falling, something is going wrong, despite growth in other numbers.
A North Star metric differs from ordinary business metrics in that it simultaneously reflects value for the customer and value for the business. When users get more value out of the product, the company earns more money.
How to pick a North Star
There are three types of products, and different metrics suit each one:
Attention model (media, social networks, entertainment):
— Metric: time spent in the product — Examples: Netflix — hours watched per subscriber, TikTok — daily time in the app, Medium — reading time — Logic: the more time users spend, the more ads you can show or subscriptions you can sell
Transactional model (e-commerce, marketplaces, fintech):
— Metric: number of transactions or their volume — Examples: Airbnb — nights booked, Uber — completed rides, PayPal — payment volume — Logic: every transaction brings in a commission
Productivity model (work tools, enterprise software):
— Metric: completed outcomes or active users — Examples: Asana — completed projects, GitHub — active repositories, Slack — messages sent within a team — Logic: the more productive users are, the more they’re willing to pay for the tool
How a North Star affects prioritization
Instead of multi-factor analysis, you make all decisions through a single lens: how will this affect the main metric?
Example 1: Duolingo and the CURR metric Duolingo was growing by a few percent a year and was looking for a metric to pull on. Instead of overall DAU (daily active users — how many people open the app in a day), the team calculated which metric correlated most strongly with growth, and found CURR — the probability that a person who was active both of the last two weeks comes back this week too. “CURR had a colossal effect on DAU — 5 times stronger than the next most significant metric.” Focusing on CURR meant deliberately giving up other directions, including new-user retention. Over 4 years DAU grew 4.5x (Jorge Mazal, CPO of Duolingo, Lenny’s Newsletter).
Example 2: Amplitude and changing the North Star Amplitude’s first metric was “how many users per week build queries against the data.” “By focusing only on those who build queries, we were limiting the potential of our solution.” The metric was changed to Weekly Learning Users — a user whose insight from the data was used by at least two colleagues that week. In plain terms: success became the moment when one person’s observation was picked up by the team. The priority swung away from features for the lone analyst toward mechanics for spreading insights; the user base grew more than 4x in two years (Justin Bauer, CPO of Amplitude, Amplitude blog).
Relationship with other frameworks
The North Star doesn’t replace RICE or other prioritization methods. It works as a final arbiter and a strategic filter:
As a strategic filter: If a feature doesn’t affect the North Star, it doesn’t get built. It doesn’t matter how beautiful it is or how many people are asking for it.
As a final arbiter: When you have two features with the same RICE score, you pick the one that affects the main metric more.
Integration example: An e-commerce team uses “monthly purchasing users” as its North Star. They apply RICE to score features, but into the impact parameter they plug the forecast effect on the number of purchasing users. Features that increase satisfaction but don’t affect purchases get a low impact score.
Pitfalls of North Star metrics
The North Star, like any other metric, can push you in the wrong direction.
Example: If your metric is daily active users, the team will start building spammy notifications to grow activity. Users come back into the product, but they end up hating it.
Short-term optimization: The North Star can push toward decisions that work now but do damage in the long run.
Example: If your metric is daily active users, the team may start building spammy notifications. Users come back into the app → daily active users grow → everyone’s happy. Six months later users get tired of the spam and delete the app.
The fix: You add a balancing metric. Alongside daily active users you add a retention number or NPS. If the main metric is growing while the balancing one falls, something is wrong with the strategy.
Local optimization: Focus on one metric can break other parts of the product.
Example: YouTube. In 2012 the algorithm was switched from number of clicks to watch time — rewarding videos that hold the viewer (TechCrunch, New America). The side effect: creators started padding videos with repetition and filler — for instance up to the 10-minute threshold that qualified a video for mid-roll ads (Digiday). Later YouTube lowered the ad threshold to remove the incentive to pad.
The fix: You account not only for quantitative but also for qualitative indicators. YouTube added metrics like “likes per minute watched” and “engagement in comments.”
Picking the wrong metric: Sometimes what looks important for the business doesn’t reflect value for users.
Example: A mobile banking team picked “number of app opens per month” as its North Star. They optimize for that metric: adding push notifications, gamification, loyalty programs. The number of app opens grows, but customer satisfaction falls — people go into their bank when they have a problem, not for entertainment. The right metric would have been “successfully completed transactions” — it reflects how well the bank helps solve financial tasks.
How to introduce the North Star approach
Step 1: A quick template: work out which type of product you are (Attention / Transactions / Productivity) and pick the corresponding category of metrics. This set isn’t universal, but you can start your thinking from it.
Step 2: Check the link to the business. The North Star has to correlate with revenue. If users get more value (the metric grows), the company should earn more money.
Step 3: Make the metric actionable. The team has to understand which actions can influence it. “User happiness” is a bad North Star, because it’s unclear what to actually do. “Time from signup to first completed task” is a good one, because it’s clear where to look for problems.
Step 4: Build it into the prioritization process. Every new feature should have a hypothesis: “If we build X, the North Star will change by Y% because Z.”
Step 5: Add balancing metrics to avoid local optimization. The North Star works best in product teams that have freedom of action and carry responsibility for the result. In companies with a rigid vertical structure, where decisions are made by top management, this approach may not take root.
Product-led growth metrics as an alternative to AAARRR
The problem with the funnel: AAARRR makes you think of users as water flowing through a pipe. Passed acquisition → landed in activation → reached revenue. But in software as a service and digital products, a user doesn’t “pass through” the product — they live inside it, get value, become a brand advocate. Funnel thinking misses the most important thing: the moments when the product actually helps solve a problem.
What product-led growth metrics are: Instead of stages of the customer journey, you measure moments of value inside the product. The focus isn’t on how many people did something, but on how deeply they’ve integrated the product into their life or work.
Time to value: Speed to first benefit
The idea: You measure how quickly a new user gets real value out of the product. Not “signed up” or “filled in a profile,” but actually solved their problem.
Examples:
— Slack: time to the first message sent in a team (not time to signup) — Figma: time to creating the first shared design (not time to first login) — Notion: time to creating the first database with real data (not time to completing onboarding)
How this changes prioritization: If your time to value is 3 days and your competitor’s is 30 minutes, no improvements in retention will help. Priority goes to features that help the user reach the “aha moment” faster, not to a beautiful onboarding.
Example: Slack. The team compared customers who stayed with those who left and found a threshold: “any team that has exchanged 2,000 messages in its history has tried Slack for real… after 2,000 messages, 93% of those customers are still using Slack.” From then on, all the growth work was about getting every new team to that point faster (Stewart Butterfield, First Round Review).
Feature adoption: Depth of product use
The idea: What percentage of users use the key features that set your product apart from competitors. Not just “how many users are active,” but “how many users use the thing they’re actually paying for.”
Examples:
— Asana: percentage of teams that use custom fields (not just create tasks) — Zoom: percentage of users who have scheduled recurring meetings (not just made a single call) — GitHub: percentage of developers who use pull requests (not just store code)
How to identify the key features: You take the users with the highest retention and look at which features they use more than others. Those are your “magic features.”
Effect on prioritization: If only 15% of users use your killer feature, the problem isn’t that you need new features. The problem is that 85% of users don’t understand the value of what’s already there. Priority goes to improvements in discovery and onboarding for existing features.
Example: Facebook. Comparing engaged and unengaged users revealed a shared trait: “The biggest thing we figured out was that you had to get any individual to 7 friends in 10 days. That was it.” Depth of use — here, the number of connections — predicts whether a person will stay; the whole growth team worked on that single number (Chamath Palihapitiya, Growth Hackers Conference talk).
Product-qualified leads: Willingness to pay, shown through usage
The idea: Users who have reached a certain level of activity in the product and are ready to buy or upgrade. Unlike marketing-qualified leads (downloaded a whitepaper, attended a webinar), product-qualified leads show willingness to pay through actual behavior in the product.
How to identify the threshold: You analyze the behavior of users who already pay and find the patterns.
For instance: “Users who have created more than 10 projects upgrade 70% of the time.”
Examples of product-qualified lead criteria: — Slack: 2,000 messages in a team’s history — past that threshold 93% of teams stay with the product (First Round Review) — HubSpot: Weekly Active Teams — two or more employees doing meaningful work in the product every week; the company didn’t disclose the conversion-to-paid rate (OpenView)
Effect on prioritization: Instead of improvements to the landing page conversion rate, you focus on getting more users to product-qualified lead status. Priority goes to features that nudge people toward deeper engagement.
Example: RapidMiner. Moving to a product-qualified lead model: “we’re going to point the resources of the entire company at making this model work — from marketing budget allocation to sales processes and the product roadmap.” Growth became part of the product backlog; with the money that used to fund a content marketer they hired a technical writer — for self-service users, documentation matters more than promotional copy (Tom Wentworth, CMO of RapidMiner, blog).
When to use product-led growth metrics instead of AAARRR
How to integrate both approaches: You use AAARRR for the macro view (the overall customer journey), and product-led growth metrics for the micro view (what’s happening inside the product). AAARRR shows how many people made it to signup; product-led growth metrics show what they do after signup and why they stay or leave.
The key difference in thinking: AAARRR thinks “how do we bring more people into the funnel,” product-led growth thinks “how do we make the product so useful that people can’t live without it.” The first requires more marketing, the second more product development.
Continuous discovery habits
The problem with quarterly research: Most product teams run user research in cycles: for two months we build features based on old understandings, then for a month we run research, draw conclusions and plan another quarter ahead. By release time half the assumptions are stale, but it’s too late to change anything — the roadmap is approved, resources are allocated.
What continuous discovery is: Instead of big research projects once a quarter — small weekly touchpoints with users. Not dramatic turns based on all-encompassing studies, but constant micro-corrections of direction based on fresh evidence. Like a car’s navigator: it doesn’t replan the whole route every 100 km, it prompts turns every 100 meters.
The author and the philosophy: Teresa Torres developed this approach in 2021–2023, working with hundreds of product teams. The core idea: customer insights are like milk — they spoil quickly. A three-month-old study is as useful for making decisions today as a three-month-old newspaper is for understanding current events.
The weekly rhythm: What it looks like in practice
The minimum dose: 2 hours of customer contact per week per team. Not 2 hours of interviews — 2 hours of any contact: interviews, watching people use the product, analyzing support tickets, reading reviews.
The structure of the week:
— Monday: you plan the sprint taking into account last week’s insights — Wednesday: interviews with 1–2 users (20–30 minutes each) — Friday: you analyze what you learned and update your assumptions
Who takes part: Not just the UX researcher. Developers, designers, the product manager — everyone takes turns talking to users. Just as in DevOps everyone is responsible for deployment, in continuous discovery everyone is responsible for understanding customers.
Example: Grailed, a clothing marketplace. For 8 months the team built a feed with manual settings — on the assumption that users needed control over the content. Regular interviews showed that nobody was asking for it. “When we talked to users, it turned out that nobody uses those words. Most people say: show me more of what I like and less of what I don’t.” The feed was rebuilt as algorithmic, this time in continuous-interview mode. The results: gross merchandise volume through the feed (GMV) grew 4–5x, lifetime value (LTV — how much a person brings in over their whole time with you) by 20%, and returns to the app by 30% (Rajeev Chopra, head of product at Grailed, Product Talk).
Evidence-based prioritization: From assumptions to facts
The old approach: The product manager thinks: “Users definitely need dark mode, it’s a trend.” Puts a high impact score into RICE with no justification. The feature gets prioritized based on the team’s internal beliefs.
The continuous discovery approach: Every score in any prioritization framework rests on evidence from the last 1–2 weeks. “Impact = 8, because in 4 out of 5 interviews this week people brought up this problem as their main pain point.”
What counts as evidence:
— Direct quotes from users (not paraphrases, but their literal words) — Behavioral data (what people actually do versus what they say) — Support patterns (which questions get asked most often) — Usage analytics (where users get stuck or drop off)
Example: Superhuman. Every week the team asked users: “How would you feel if you could no longer use Superhuman?” The share of people answering “very disappointed” became the main metric: 22% at the start. The roadmap was split in half: half the effort on strengthening what the “very disappointed” love, half on removing barriers for those who were “somewhat disappointed.” Over three quarters the number grew to 58% (First Round Review).
Integration with prioritization frameworks
Continuous discovery doesn’t replace RICE/OKR/ICE — it feeds them current data. Just as good fuel doesn’t replace the engine but lets it run more efficiently.
How it works with RICE:
— Reach: not a gut feeling, but data on how many people mentioned the problem in interviews — Impact: not assumptions, but user quotes about how critical it is — Confidence: based on the amount of evidence from recent weeks — Effort: supplemented by an understanding of which parts of the solution matter most to users
How it works with objectives and key results: Weekly research shows which initiatives actually move key results and which only look important. You can correct tactics every week without changing strategic goals.
Integration example: A team uses RICE for prioritization. On Monday RICE showed that feature A was more important than feature B. On Wednesday interviews revealed a new user problem — feature C. On Friday they added feature C to RICE and recalculated priorities. Feature C turned out to be more important than A and B. They adjusted the plan for the next sprint. Not a revolution, an evolution.
Practical techniques: How not to turn research into bureaucracy
Async interviews: Not every interview has to be in real time. You can send users 3–4 questions on video and ask them to record their answers. Saves time but still gives deep understanding.
Micro-research: 10-minute conversations are better than no conversations. You called a user, asked one question, got an answer — that’s research too.
Customer advisory calls: Once every two weeks, a call with 3–5 regular customers who are willing to give feedback. You discuss new ideas and get quick validation or rejection.
Dogfooding: The team uses its own product in real scenarios.
The product manager orders food through their own delivery app, the designer creates a real project in their own design tool.
Outcomes and success metrics
Outcomes of continuous discovery:
— Fewer failed features (because they’re validated before development) — Higher feature adoption (because they solve real problems) — Shorter time to product-market fit (because you iterate based on evidence) — Better team alignment (everyone sees the same customer insights)
How to measure the success of the approach:
— Feature adoption rate: percentage of users who use new features a month after release — Time to validation: how long it takes to understand whether a feature works or not — Speed of getting customer insights: how many new insights the team gets per week — Confidence in decisions: how confident the team is in product decisions (a subjective survey)
Implementation cases (Teresa Torres’s “Product in Practice” series): most teams — Texthelp, Botify, Hemnet — describe qualitative effects: focus, stakeholder trust, decision speed. The quantitative case is Grailed, above. On rhythm — CarMax: “we now talk to 2–4 customers every week, whether or not we have something to show them” (producttalk.org).
When continuous discovery doesn’t work
It’s not a fit when:
— Enterprise with long sales cycles: customers aren’t available for weekly chats — Highly regulated industries: every change requires legal approval — Infrastructure products: end users have no direct contact with the product — Very early stage: there are no users yet to interview
Alternatives for the hard cases:
— User proxies (the customer success team, sales as a source of insights) — Stakeholder interviews instead of end-user interviews — Behavioral analytics as a substitute for direct contact — Industry research and competitor analysis
The main principle: It’s better to have some contact with customers than no contact with customers. If you can’t talk to users every week, talk to them every two weeks. If you can’t do 30-minute interviews, do 10-minute ones. Perfect is the enemy of good, and good customer insights are better than perfect assumptions.
The cultural shift: Teams stop arguing about what “users want” and start asking: “So what did users say this week?” Discussions based on evidence, not opinions. That changes not just prioritization but the whole way product decisions get made.
Outcome-based prioritization
The problem with output-oriented thinking: Most product teams measure success by how much they got done: “This quarter we launched 12 features, closed 80% of the backlog, great result!” Meanwhile not a single feature improved the product’s key metrics, users didn’t get more active, revenue didn’t grow. But the backlog is clean, the roadmap is done — everyone’s happy. Right up until the moment the boss asks: “And what did we do all that for?”
What the outcome-based approach is: You prioritize not features but changes in user behavior or business numbers. You measure success not by the number of features shipped but by reaching specific outcomes. “This quarter we increased weekly retention from 65% to 72%” — it doesn’t matter whether that took one feature or twelve.
The difference in the questions you ask:
— The output-oriented approach: “Which features do we build this sprint?” — The outcome-based approach: “What change in user behavior do we want to achieve? What will help us get there?”
Example of the switch: Airtable. The outcome, stated: more teams in which several people are actively working by week four, not limited to a single user. Onboarding — a person’s first steps in the product — was rebuilt around that outcome, including different paths for different learning styles. Rebuilding onboarding produced “a 20% increase in activation”; the list of features was assembled afterwards, around the target behavior change (Lauryn Isford, Head of Growth at Airtable, Lenny’s Newsletter).
How to switch to outcomes: Practical steps
Step 1: Tie every feature to a hypothesis
You connect each backlog item to a specific assumption about a change in behavior:
— Bad: “Add dark mode” — Good: “If we add dark mode, users will spend more time in the app in the evening, because their eyes get less tired. We expect a 15% increase in evening session length”
Step 2: Define measurable outcomes
For each hypothesis you pick a metric that will show success or failure:
— Specific: “Increase engagement” → “Increase daily time in the app by 10%” — Measurable: “Improve the user experience” → “Increase NPS from 7.2 to 8.0” — Time-bound: “Raise retention at some point” → “Raise 7-day retention by 5% by the end of the quarter”
Step 3: Measure after launch
After release you measure outcomes, not outputs. If the outcome isn’t reached, the feature counts as a failure, even if it’s technically perfect and users are using it.
Example: An e-commerce team added product recommendations to the home page. Output success: the feature works without bugs, 60% of users click on the recommendations. Outcome failure: the conversion rate didn’t change, because the recommendations showed products people were going to buy anyway. The feature is technically successful but useless to the business.
Outcome-oriented prioritization frameworks
Outcome-oriented RICE: Into the impact parameter you plug not “how many users this will touch” but “how much the target behavior will change.” If a feature doesn’t change behavior — impact = 0, regardless of reach.
Example of RICE with outcomes: — Regular RICE: Reach = 10,000 users, Impact = 3 (medium), Confidence = 80%, Effort = 2. Score = 12. — RICE with outcomes: Reach = 10,000 users, Impact = 0 (won’t change key behavior), Confidence = 80%, Effort = 2. Score = 0.
Outcome-oriented objectives and key results: You state key results in terms of behavior change, not task completion:
— Bad key result: “Ship 5 new features” — Good key result: “Increase feature adoption among new users from 40% to 60%”
ICE with outcomes: You score impact by the effect on outcome metrics, not by a subjective sense of importance.
Types of outcomes and how to prioritize them
Behavioral outcomes (changes in user actions):
— Examples: more time in the product, more frequent use of key features, inviting colleagues — How to prioritize: features that make the desired behavior easier/faster/more pleasant get priority
Business outcomes (changes in business metrics):
— Examples: higher conversion, more revenue per user, lower churn — How to prioritize: a direct link to the P&L — the greater the effect on profit, the higher the priority
Customer satisfaction outcomes (changes in how the product is perceived):
— Examples: higher NPS, fewer support tickets, better app store reviews — How to prioritize: leading indicators for business outcomes — happy users bring in more money later
Example of the hierarchy: A fintech app. Customer satisfaction outcome: reduce the number of support tickets about unclear transactions. Behavioral outcome: users read transaction descriptions more often. Business outcome: fewer chargebacks and disputes. Priority goes to features that make transaction descriptions clearer.
Traps of the outcome-based approach
Trap 1: Optimizing the wrong outcomes
You can optimize a metric that doesn’t correlate with the product’s long-term success.
Example: A news app team optimized reading time. The algorithm started showing clickbait articles, because they hold attention longer. Reading time grew, but user satisfaction fell — people felt they were wasting their time.
The fix: Balancing metrics. They added NPS and return rate alongside reading time. If the main metric grows while the balancing ones fall, the strategy is wrong.
Trap 2: Short-term versus long-term outcomes
Focusing on quarterly outcomes can damage the product’s long-term health.
Example: A social media app wanted to increase the number of daily posts per user. They added aggressive prompts and notifications. Posts per user grew, but six months later users started complaining about spam and retention fell.
The fix: A portfolio of outcomes. 70% of the focus on short-term metrics, 30% on long-term health indicators.
Trap 3: Correlation versus causation
You can prioritize features that correlate with outcomes without causing them.
Example: Analysis showed that users with an uploaded profile photo had 2x higher retention. The team made uploading a photo mandatory during onboarding. Retention didn’t change — the photo was a consequence of engagement, not a cause of it.
The fix: A/B testing of causal hypotheses, not just correlation analysis.
Cultural changes in the team
From a feature factory to an outcome factory: Teams stop celebrating completed tasks and start celebrating outcomes reached. “We increased conversion by 15%” instead of “We closed every task in the sprint.”
From “let’s build it and see” to “let’s check and then build”: Before building a feature, you state a measurable hypothesis. If after release the hypothesis isn’t confirmed, that’s not a team failure but valuable learning.
From quarterly planning to continuous correction: You can measure outcomes weekly, so you can correct tactics without waiting for the end of the quarter. The strategic goals stay, the tactical approaches evolve.
Example of the cultural shift: In the retrospective you discuss not “how many story points we closed” but “how much closer we got to the target outcome.” The questions change: instead of “Why did the task take longer?” you ask “Why wasn’t the outcome reached, and what can we change?”
When to use outcome-based prioritization
It’s a fit when:
— There are clear, measurable metrics for success — You can run A/B tests to validate causation — Business stakeholders understand the difference between activity and outcomes — The team is ready to take responsibility for business results
It’s not a fit when:
— Outcomes are heavily delayed (enterprise with long sales cycles) — Too many external factors affect the metrics — Regulatory requirements dictate the roadmap — The team doesn’t control the factors that affect the outcomes
An alternative for the hard cases: Intermediate outcomes. If you can’t measure the final business outcome, you measure the intermediate behavioral changes that have historically led to success.
Outcome-based prioritization turns a product team from roadmap executors into goal achievers. It demands more analytical thinking and accountability, but it produces far better business results and higher team satisfaction.