TL;DR
- The core problem: According to a Pendo study, roughly 80% of software features are rarely or never used — meaning most of what product teams build produces near-zero value for users.
- Vibe coding accelerates the problem: AI coding tools lower the cost of shipping but not the cost of shipping the wrong thing. They make feature factories worse, not better.
- The JTBD alternative: Focus the roadmap on the jobs users are most underserved on — problems rated highly important with low current satisfaction. One high-impact feature beats ten marginal ones.
- Four decision frameworks: RICE Score, Opportunity Cost, Type 1 vs Type 2 Decisions, and the One Thing Test give structure to what gets built and what gets dropped.
- The measurement system: Growth sprints close the loop — running four-week cycles that tie each build directly to a behavioural outcome metric.
1. The New Feature Factory: Why Vibe Coding Is Making Things Worse
There is a version of the feature factory story that predates AI tools entirely. The team ships a roadmap full of low-impact features, velocity metrics look healthy, and nobody asks whether any of it is moving the product forward. This story is decades old.
What is new in 2026 is the scale at which it can happen.
Tools like Replit, Cursor, and Claude Code have reduced the marginal cost of writing code close to zero for many tasks. A feature that once required a sprint now takes a day. A prototype that once required a developer now takes a product manager with a good prompt. By some estimates, AI-generated code represented roughly 41% of all code written in 2025, and top engineering teams were reporting AI assistant usage rates of 85-90% daily.
That sounds like pure acceleration. In practice, it accelerates both good product decisions and bad ones with equal indifference.
The economics of vibe coding shift the constraint. When engineering capacity was the bottleneck, teams were forced to prioritise ruthlessly — not always well, but at least with some friction. Remove that friction and what remains is the quality of the product strategy underneath. Teams that lack clear prioritisation frameworks respond to lower build costs by shipping more, not by shipping better. The result: a larger product surface, lower per-feature engagement, and a maintenance burden that grows faster than the team.
The New Stack reported that vibe coding could cause "catastrophic explosions" in 2026 if deployed without disciplined product thinking. Veracode's analysis of AI-generated code found that nearly half introduces known security flaws. But the deeper risk for most SaaS products is not security — it is irrelevance. Features built without a clear user Job behind them do not just fail to add value. They dilute the product, complicate onboarding, and fragment the support load.
According to a Pendo study on feature adoption, approximately 80% of software features are rarely or never used. Pendo estimated that publicly-traded cloud software companies collectively invested up to $29.5 billion developing features that generated minimal user value.
That figure is a product strategy failure, not an engineering one. The engineers shipped what was asked of them. The problem was upstream — in the systems (or absence of systems) used to decide what to ask for. Vibe coding does not change this dynamic. It amplifies it.
2. What a Feature Factory Looks Like
Feature factories are rarely identified from the inside. The team is busy, shipping frequently, and the roadmap is full. These are exactly the conditions that make the pattern hard to see. The signals to watch for are behavioural and metric-level, not cosmetic.
The Warning Signs
- Signal Feature adoption rates below 20% at 30 days. If a feature is in your product but fewer than one in five active users have touched it within a month of launch, the usage case was either unclear or unnecessary. Most teams do not track this.
- Signal Roadmap driven by sales requests and competitor parity. When the question "what should we build next?" is answered by the most recent enterprise prospect's wish list or by what a competitor launched last quarter, there is no product strategy. There is just reaction.
- Signal NPS and retention are flat despite high velocity. If you are shipping every two weeks and your retention curve is unchanged quarter-on-quarter, the things being shipped are not solving the problems that drive churn. This is the most definitive indicator.
- Signal The product requires a 45-minute onboarding call to explain. Feature sprawl increases cognitive load. When a new user cannot understand what your product does without a human guide, you have added more surface than value. Complexity is a tax that compounds.
- Signal Engineers routinely ask "why are we building this?" Good engineers have good product instincts. When they are asking this question regularly and not getting satisfying answers, the decision-making process upstream has broken down.
- Signal No defined activation milestone or success metric per feature. A feature without a defined success metric is a feature that cannot be evaluated. If you cannot answer "how will we know if this worked?" before you build it, you are building blind.
The underlying cause of all six symptoms is the same: the team has optimised for output (features shipped) rather than outcome (user progress made). This is a strategy problem with a measurement consequence. You cannot course-correct what you do not measure, and most feature factories do not measure adoption at the feature level at all.
"Sure, all features solve some kind of job by default. But if you are not clear on which Jobs are most important to your users, you will ship ten five-percent features before a single ninety-five percent feature. Go for impact, not volume."
— Jake McMahon, ProductQuant
The distinction between a five-percent feature and a ninety-five percent feature is not about technical complexity. It is about how central the underlying Job is to the user's reason for being in the product at all. A feature that addresses a peripheral convenience delivers five percent impact. A feature that directly removes the primary friction from the user's core Job delivers ninety-five percent. Only one of those compounds into retention.
3. The JTBD Alternative: Jobs Over Features
Jobs-to-be-Done (JTBD) is a framework for understanding why users engage with a product — not what they do in the UI, but what progress they are trying to make in their life or work when they reach for it. The framework was developed by Clayton Christensen at Harvard Business School and operationalised as a prioritisation system by Tony Ulwick through his Outcome-Driven Innovation methodology.
The core claim is simple: users do not buy products. They hire products to get a job done. When a product does the job well, users keep it. When it does the job poorly, or when a competitor does it better, they switch. The product features are the mechanism — the Job is the reason.
What a "Job" Actually Is
A Job is not a task or a user story. It is the progress a person is trying to make in a given circumstance — functional, emotional, and social. A project manager using a SaaS tool is not "trying to create a Gantt chart." The Job is: "Help me demonstrate to my stakeholders that the project is under control so that I am trusted to run the next one." The chart is a feature. The trust is the Job.
This distinction matters for prioritisation because it changes the unit of analysis. When you optimise for the Job rather than the feature, you start asking different questions before anything goes on the roadmap:
- Which Jobs are users trying to complete in our product?
- For each Job, how important is it to them? (Importance score)
- For each Job, how satisfied are they with how well the product currently addresses it? (Satisfaction score)
- Where is the gap between importance and satisfaction the largest?
That gap is the opportunity. Ulwick's research, drawn from hundreds of client engagements at his firm Strategyn, found an 86% success rate when product decisions were anchored to JTBD-derived opportunity gaps versus the industry average for new product features of roughly 17% success.
The Opportunity Map
The practical output of a JTBD discovery process is an opportunity map: a ranked list of Jobs ordered by their opportunity score (importance minus satisfaction, adjusted for importance weighting). This map becomes the input to your roadmap — not a feature wishlist, not a competitor teardown, not a stakeholder priority list. A direct ranking of where users are most underserved by the current product.
| Job Statement | Importance (1-10) | Satisfaction (1-10) | Opportunity Score | Priority |
|---|---|---|---|---|
| Understand which accounts are at risk of churning before they cancel | 9.2 | 4.1 | 14.3 | Critical |
| Share a portfolio view with a client without exporting to spreadsheet | 7.8 | 3.5 | 12.1 | High |
| Set up a new workspace without involving an admin | 6.4 | 5.9 | 6.9 | Medium |
| Export data in a custom date format | 4.1 | 6.2 | 2.0 | Low (overserved) |
The table illustrates how JTBD scoring prevents over-investment in low-importance, high-satisfaction areas. Export formatting is frequently requested by individual users, but the importance score is low — suggesting that while users notice the limitation, it does not significantly affect whether they stay or leave. The churn risk visibility job, on the other hand, is highly important and highly underserved: a direct opportunity for retention impact.
For a deeper walkthrough of how to run a JTBD Kano workshop to validate these scores with real users, see our guide to JTBD Kano Workshop methodology. For how to wire JTBD outputs into your analytics stack, see connecting the JTBD roadmap to your retention loop.
How to Build a JTBD Dashboard in PostHog
Instrument your product to track job completion rates, not just feature clicks. Our dashboard template covers the four key JTBD metrics.
4. Four Prioritisation Frameworks That Actually Work
JTBD tells you what problems to solve. These four frameworks tell you which ones to solve first, and which ones to drop entirely. They are not mutually exclusive — in practice, most teams layer them, using RICE for scoring, Opportunity Cost for trade-off clarity, Type 1 vs Type 2 for decision-speed calibration, and the One Thing Test as a final filter before anything enters a sprint.
RICE Score
Developed at Intercom by product manager Sean McBride, RICE was created specifically to counteract the tendency for "pet projects" to displace high-impact work in backlog prioritisation. The formula:
RICE forces quantification before commitment. A feature with high excitement but low reach and high effort will score poorly — correctly. A feature with modest excitement but high reach and low effort will score well — also correctly. The confidence multiplier is the most important part: it prevents teams from gaming the system with optimistic impact estimates by penalising low-evidence assumptions.
The RICE framework has become one of the most widely used prioritisation tools in product management. It works because it makes trade-offs explicit and auditable. When a stakeholder asks why Feature X was deprioritised, you can show the score, not just describe a feeling.
Opportunity Cost
Every feature you build is a decision not to build something else with the same engineering capacity. Opportunity cost makes this trade-off explicit. The question is not "is this feature worth building?" The question is "is this feature worth building more than the next best thing we could build instead?"
This reframe is especially important in the vibe coding era. When build costs are low, the opportunity cost of any single feature appears small. But the compounding opportunity cost of a roadmap full of low-RICE items is enormous — not just in engineering time, but in the maintenance load, the onboarding complexity, and the strategic coherence of the product surface users encounter.
A practical implementation: before any feature enters a sprint, the team must identify one item they are explicitly choosing not to build in its place. This forces the choice to be visible and keeps the backlog honest. It also surfaces cases where the item being displaced was actually higher-priority than the item replacing it — a pattern that reveals stakeholder pressure overriding product judgment.
Type 1 vs Type 2 Decisions
Jeff Bezos popularised this distinction in his 2015 Amazon shareholder letter. Type 1 decisions are "one-way doors" — once made, they are expensive or impossible to reverse. Type 2 decisions are "two-way doors" — reversible, low-stakes, correctable. Bezos argued that most decisions are Type 2 and should be made quickly at the team level, while Type 1 decisions warrant slow, deliberate, senior-level scrutiny.
Applied to product strategy, the lens resolves a common failure mode: teams that over-deliberate on reversible decisions (creating drag) while under-deliberating on architectural or positioning decisions (creating compounding damage). Examples:
| Decision | Type | Right process |
|---|---|---|
| Switching from per-seat to usage-based pricing | Type 1 | CEO-level decision, full analysis, staged rollout |
| Changing the colour of the primary CTA button | Type 2 | A/B test, PM approves, ships in a day |
| Rebuilding the onboarding flow from scratch | Type 1 | Requires activation data, user research, staged release |
| Adding an empty-state illustration to a dashboard | Type 2 | Designer ships it, done |
The practical value of this framework is speed calibration. Teams that treat every decision as a committee matter become slow and demoralised. Teams that treat every decision as low-stakes ship architectural errors they spend years unwinding. The Type 1/Type 2 split gives teams explicit permission to move fast on the reversible and slow on the irreversible.
The One Thing Test
Borrowed from Gary Keller's productivity framework, the One Thing Test asks: "What is the single most important thing I could build this quarter, such that by doing it, everything else becomes easier or unnecessary?" It is a forcing function against roadmap sprawl.
In practice, teams run the One Thing Test quarterly as a reset on the roadmap. The question forces a choice between competing priorities that RICE scoring alone may leave unresolved when two items score similarly. It also reframes the team's relationship to the roadmap: the goal is not to ship the most things. The goal is to make the most progress on the most important problem.
The One Thing Test integrates directly with JTBD prioritisation. Once you have your opportunity map — the ranked list of Jobs by importance and underservice — the One Thing Test simply asks: of the top three items on this map, which one, if solved, most directly accelerates your core retention or acquisition metric? That is your quarter. Ship the supporting features in service of it, not alongside it as co-equal priorities.
These four frameworks do not eliminate subjectivity from product decisions entirely. What they do is make the basis for decisions explicit and auditable, create a shared language for trade-offs, and surface stakeholder influence before it distorts the roadmap rather than after. Used together, they are the structural antidote to the feature factory pattern.
For a deeper look at how product teams eliminate low-value build work using analytics as the foundation, see our analysis of why competitor feature matrices mislead product teams and why growth metrics alone do not produce decisions.
5. Growth Sprints as the Antidote
Frameworks are only as useful as the operating system that turns them into regular practice. The most common failure mode after a team adopts JTBD and RICE is that the frameworks get used once — at an offsite or a planning session — and then quietly abandoned when day-to-day shipping pressure reasserts itself.
Growth sprints are the mechanism that prevents this. A growth sprint is a structured four-week cycle that connects a prioritised opportunity (identified through JTBD scoring) to a specific build (evaluated through RICE and the One Thing Test) to a defined behavioural outcome metric (measured in your analytics platform). The cycle has four phases:
Phase 1: Opportunity Selection (Days 1-3)
The team reviews the current JTBD opportunity map and selects the single highest-scoring item to address in the sprint. This is not a debate about the whole roadmap. It is a decision about the next four weeks, bounded by the opportunity data. The output is a one-paragraph problem statement: which Job, for which user segment, with which evidence of underservice.
Phase 2: Hypothesis and Metric Definition (Days 3-5)
Before any design or engineering work begins, the team defines the hypothesis and the success metric. The format is: "We believe that [build X] will improve [metric Y] for [user segment Z] because [evidence W]. We will know we are right if [metric Y] moves by [threshold] within [time period]." The metric must be a behavioural signal in the product — an event in PostHog, a funnel conversion rate, a retention cohort — not a vanity metric like page views or downloads.
Phase 3: Build and Ship (Days 5-22)
Engineering builds the scoped item. The scope is deliberately narrow — addressing one Job, for one segment, in a way that produces one measurable signal. If the build scope expands during this phase, the additional items are captured in the backlog for the next sprint, not folded into the current one. Sprint integrity is non-negotiable because it is what makes measurement possible.
Phase 4: Measure and Learn (Days 22-28)
At the end of the sprint, the team reviews the behavioural data against the hypothesis. Did the metric move? If yes, by how much? Is the movement attributable to the build or to a confounding factor? The learning from this review feeds directly back into the opportunity map — updating satisfaction scores for the Job addressed and surfacing the next highest-priority item for the following sprint.
The growth sprint cycle. One Job, one hypothesis, one metric, one build. The brevity is intentional — it is short enough to maintain focus and long enough to generate real behavioural data from real users.
The sprint system solves the accountability gap that frameworks alone cannot address. When a feature ships and no metric is defined in advance, there is no way to evaluate whether it was the right decision. Post-hoc rationalisation fills the gap. Growth sprints make retrospective rationalisation structurally impossible by requiring the metric before the build.
This is also where the Growth Operating System connects strategy to execution. The JTBD opportunity map is the strategy layer. Growth sprints are the execution layer. The analytics stack — PostHog, your CRM data, your activation funnel — is the measurement layer. All three must be in place for the system to work.
6. The Measurement System That Closes the Loop
A product team running growth sprints without a coherent measurement system is running experiments without instruments. The measurement system is not an afterthought — it is the infrastructure that makes every other part of this approach credible.
What to Instrument
For JTBD-aligned product development, your analytics instrumentation needs to capture three layers of signal:
Layer 1: Job Completion Events. For each prioritised Job on your opportunity map, there should be at least one event that signals the Job was completed. Not "clicked the button" — "completed the core action that represents the Job being done." For a project management tool, "Job: demonstrate project control to stakeholders" maps to an event like client_report_shared or status_update_published, not dashboard_viewed. The distinction matters because it keeps your event taxonomy tied to outcomes, not clicks.
Layer 2: Feature Adoption Rates. For every new feature shipped, instrument a usage funnel: users who saw the feature / users who tried it / users who returned to it within 14 days / users for whom it became a regular pattern. Tracking adoption at this level reveals quickly whether a feature is achieving engagement or just adding surface. The benchmark from Pendo's research suggests that core features in successful B2B SaaS products see 70% or higher adoption among monthly active users. New features rarely hit this immediately — but the trajectory within the first 60 days is predictive.
Layer 3: Retention by Job Profile. Segment your retention cohorts not just by acquisition channel or plan tier, but by which Jobs users are completing in the product. Users who have completed three or more high-importance Jobs within the first 30 days should retain at significantly higher rates than those who have touched only peripheral features. If this pattern does not hold in your data, the Job importance scores from your research need revisiting.
The Weekly Review Cadence
The measurement system only produces value if someone is looking at it regularly and drawing conclusions. The cadence that works for most growth-oriented SaaS teams is a weekly 45-minute product review with three agenda items:
- Sprint metric check: How is the current sprint's target metric moving? Any early signals from the build shipped this cycle?
- Adoption scan: Which features shipped in the last 60 days are above or below adoption threshold? Any that need a nudge (in-app prompt, onboarding flow update)?
- Opportunity map update: Has any new qualitative signal (support tickets, sales call notes, NPS verbatims) shifted the importance or satisfaction scores on the top five Jobs?
This cadence is deliberately lightweight. The goal is not a deep quarterly review — it is maintaining a live connection between what users are doing in the product and what the team is building next. Feature factories tend to review impact annually, if at all. Growth-oriented teams review it weekly.
For a detailed walkthrough of building this measurement layer in PostHog — including the specific events, properties, and dashboard structure we recommend — see our JTBD event taxonomy design guide and the SaaS growth audit checklist.
Ready to run your first JTBD-aligned sprint?
We map your top five Jobs, score them for opportunity, and build the 90-day sprint roadmap with defined metrics for each cycle.
7. FAQ
What is a feature factory in SaaS?
A feature factory is a product team that measures success by shipping volume rather than user outcomes. The team continuously adds features to the product, but lacks a clear framework for deciding which problems are worth solving. Velocity is high, but retention and activation metrics remain flat or decline because the features shipped do not correspond to jobs users actually need done. The term was popularised by John Cutler, a product management consultant who identified the pattern across dozens of B2B software companies.
What is JTBD prioritisation?
JTBD (Jobs-to-be-Done) prioritisation is the practice of ranking product investments by the importance and underservice of the jobs users are trying to complete, rather than by feature requests or stakeholder preferences. A job is underserved when users rate it as highly important but give low satisfaction scores to how the current product addresses it. Targeting the most underserved jobs produces the highest-impact features. Tony Ulwick's research at Strategyn found an 86% success rate for products developed using this approach.
How does vibe coding accelerate the feature factory problem?
Vibe coding tools like Cursor, Replit, and Claude Code reduce the marginal cost of writing code close to zero. When shipping a feature takes a day instead of a sprint, the bottleneck shifts from engineering capacity to product judgment. Teams that lack clear prioritisation frameworks respond by shipping more, not less. The result is a larger, harder-to-maintain product surface with lower per-feature usage rates and greater technical debt. The New Stack described this dynamic as the risk of "catastrophic explosions" in 2026 if vibe coding is deployed without disciplined product thinking underneath it.
What is the RICE score framework?
RICE stands for Reach, Impact, Confidence, and Effort. It was developed at Intercom by product manager Sean McBride to bring objectivity to product prioritisation decisions. Each initiative is scored: Reach (users affected per quarter) multiplied by Impact (scored 0.25 to 3) multiplied by Confidence (percentage certainty in estimates) divided by Effort (person-months required). Higher RICE scores indicate higher priority. The confidence multiplier prevents optimistic estimates from inflating scores for unproven ideas. Since its creation at Intercom, RICE has become one of the most widely adopted prioritisation frameworks in product management.
What are Type 1 vs Type 2 product decisions?
Type 1 decisions are irreversible — architectural choices, pricing model changes, core UX paradigms. Once made, they are difficult or impossible to walk back without significant disruption. Type 2 decisions are reversible — copy changes, feature flags, onboarding flows. Jeff Bezos popularised this distinction at Amazon to argue that most decisions should be made quickly at the team level because they are Type 2. In product strategy, applying this lens prevents over-deliberation on low-stakes decisions while ensuring Type 1 decisions receive the rigour they deserve. The most common failure mode is treating Type 1 decisions with Type 2 speed — leading to architectural decisions that compound debt for years.
Sources
- Pendo: The 2019 Feature Adoption Report
- Intercom: RICE — Simple Prioritisation for Product Managers (Sean McBride)
- The New Stack: Vibe Coding Could Cause Catastrophic Explosions in 2026
- Mountain Goat Software: Are 64% of Features Really Rarely or Never Used?
- Product School: Jobs to Be Done Framework
- Veracode: GenAI Code Security Report 2025
Prioritize with JTBD
We map your JTBD framework and wire it to your roadmap.
See Activation Deep-Dive Sprint →
About the Author
Jake McMahon is a product strategy and growth consultant with 8+ years in B2B SaaS. He holds a Master's in Behavioural Psychology and Big Data. He works with Series A–C companies on JTBD research, growth operating systems, and product-led GTM strategy.