Around 80% of features are rarely or never used, so the highest-leverage product work happens before the build — deciding what not to do and defining success in advance.
Most of what gets built is never used
Pendo's Feature Adoption Report, built from anonymised usage across 615 subscriptions, found that around 80% of features in the average product are rarely or never used — with roughly 12% of features generating 80% of daily usage volume. The study is from 2019 and the exact figures will have moved, but nothing since has suggested the shape is wrong, and anyone who has looked at their own product analytics recognises it.
That is the central problem of the discipline. Not that teams ship slowly — most ship steadily. It is that a large share of what they ship produces nothing, and the decision to build it was made before anyone could have known.
So the highest-leverage product work happens before the build: deciding what not to do, learning what the problem actually is, and defining in advance what would count as success. Everything in this pack is arranged around that.
A design note about these prompts specifically. Several of them produce scores — prioritisation, impact estimates, success criteria. Scoring frameworks are dangerous precisely because they convert guesses into numbers, and a number carries authority its inputs do not deserve. Every scoring prompt here is written to expose which inputs are estimates, so the output is a structured argument rather than an answer.
Learn before you decide
Write a User Interview Guide That Doesn't Lead the Witness is first because bad research is worse than none — it produces confident conviction built on answers you elicited. The guide is behavioural rather than hypothetical: what did you do last time this happened, not would you use a feature that does this. People are reliable about their past and unreliable about their future.
Turn User Interviews Into Insights and Opportunities does the synthesis, separating what people said from what you concluded — a distinction that disappears fast once findings are summarised. The customer support pack has the complementary Turn Customer Feedback Into Themes for Your Team, which works from tickets rather than interviews.
Write down what you are and are not doing
Write a Product Strategy One-Pager forces a strategy short enough that people can hold it in their heads, including the part most strategy documents omit — what you are explicitly not pursuing.
Write a Product Decision Memo With a Recommendation produces the durable artifact for a consequential choice: the options, the reasoning, the recommendation, and what would have to be true for it to be wrong. Written at the time, it lets you evaluate the decision later on what was knowable then rather than on how it turned out.
Prioritize Your Roadmap With a Scoring Model is where the estimates-exposed rule matters most. Reach and impact are usually guesses; effort is usually a guess with a bias. Making that visible turns the model into a conversation about the assumptions rather than a ranking nobody can argue with.
Triage a Messy Product Backlog addresses the accumulation that makes prioritisation impossible. A backlog of six hundred items is not a plan, it is a graveyard with search.
Specify well enough to build
Write a PRD for a Feature is scoped to what engineers actually need — the problem, the constraints, the edge cases, the decisions already made — rather than the exhaustive document that goes stale before the first commit.
Write User Stories With Acceptance Criteria puts the emphasis on the acceptance criteria, which are the part that determines whether done
means the same thing to everyone.
Break an Epic Into Shippable Increments insists each increment be independently valuable, which is what makes it possible to stop early and still have delivered something.
Cut Scope to Hit a Date is the prompt for the situation every team eventually reaches, and it distinguishes the three cuts that look alike and are not: removing scope, deferring scope, and quietly degrading quality.
Define success before you ship, not after
Define Success Metrics and Guardrails for a Feature is the direct answer to the 80% problem. Committing in advance to what would demonstrate the feature worked — and to a guardrail metric that must not degrade — is what makes it possible to conclude afterwards that it did not. Without it, every shipped feature is retroactively a success, and the unused 80% accumulates unchallenged.
Design an Experiment or A/B Test covers the controlled version; CRO has the discipline of reading results honestly, and data analysis covers observational comparisons where randomisation is not available.
Write a Feature Launch Plan covers the coordination — enablement, documentation, support readiness, and communications — that determines whether anyone discovers the thing you built.
Run a Launch Retrospective closes the loop against the success criteria you set, and is most valuable when the honest answer is that the feature did not move anything. That is the finding that improves the next decision, and it is the one teams are most likely to bury.
Where this stops
These prompts structure thinking and produce drafts; they do not know your users. Nothing here will invent usage data, market sizes, or research findings, and a scoring model's output is only as good as the estimates you fed it — which is exactly why the prompts make those estimates visible rather than absorbing them. Any feature touching personal data, accessibility obligations, or a regulated domain needs review by the people who own that risk before it ships.
Sources
- Pendo, The 2019 Feature Adoption Report — anonymised usage across 615 subscriptions; approximately 80% of features rarely or never used, with about 12% of features generating 80% of daily usage volume. Figures are from 2019 and should be treated as the shape of the problem rather than current benchmarks.