About to ship another feature? Ask these 5 first.

Roadmaps are optimistic documents. They assume that more surface area equals more value, that a competitor’s screenshot is a requirement, and that a single customer’s email is a democratic mandate. Then the sprint starts, the feature ships, usage stays flat, and everyone agrees the release notes were lovely.

I have helped kill more features on paper than I have designed in Figma-and that is intentional. Building is the expensive step. Asking better questions is the cheap one. This checklist is for stopping roadmap theatre before it ships.

It complements the hidden cost of building features nobody asked for and the product strategy framework I use before designing a single screen. If the feature exists to impress a launch audience rather than relieve a pain, read most product launches don't fail because of marketing before you estimate story points.

Why features multiply

Features are visible progress. Saying no is invisible leadership. Sales wants a checkbox. Design wants a portfolio piece. Engineering wants a clean abstraction. The founder wants the anxiety to stop. None of those are customer outcomes. They are organisational coping mechanisms with a Jira ticket.

• Competitor parity feels like strategy and often is mimicry.
• “Quick wins” accumulate into a product nobody can explain.
• Internal users of the roadmap outnumber external users of the feature.
• Unused features still cost support, QA, cognitive load, and credibility.

The five questions

1. What painful behaviour does this change-and how do we know?

Not “users might like it.” Not “it would be cool with AI.” Name the current behaviour: export to Sheets, email a VA, abandon onboarding at step four. Name the evidence: session recordings, support tags, interview notes, willingness to pay for a workaround. If evidence is a vibe, the feature is a guess with a deploy pipeline.

2. Who gets the value-and are they the ones who renew?

Champions request features that make them look good. Economic buyers renew products that reduce cost or risk. End users adopt tools that shrink their Tuesday. If those three are not aligned, you may ship delight for someone who does not hold the budget. Be explicit.

3. What do we not build if we build this?

Opportunity cost is the adult question. A feature is not plus-one. It is minus something else: the first-win path, the performance work, the onboarding rewrite, the sales cycle shortening. If you cannot name the sacrifice, you are not prioritising-you are collecting.

4. How does a new user reach a first win with this in the way?

Complexity is a tax on activation. Each control, each empty state, each settings pane is another place to stall. If the feature does not accelerate time-to-relief for the core job, it is decoration in the hallway of a house people never enter.

5. What evidence would make us rip it out?

Kill criteria before build. Adoption threshold, support burden, effect on retention, effect on the sales narrative. Without a kill switch, every feature becomes permanent folklore. Teams that cannot delete cannot strategise.

Scorecard: keep, park, or kill

A roadmap without kill criteria is a museum of decisions nobody is brave enough to reverse.

Framework: the feature trial, not the feature marriage

When a feature clears the five questions, still ship it as a trial: limited surface, clear success metric, review date. Marriage can wait. This is especially true when early customers are teaching you-see the first customer isn't your market. They're your teacher..

1. Define the smallest version that could change the painful behaviour.
2. Instrument one primary metric and two guardrails (e.g. activation, support volume).
3. Set a review date before the sprint starts.
4. Publish the kill criteria in the same channel as the launch note.
5. If it fails, remove it-do not hide it in a settings graveyard.

A fictional contrast: two “export” requests

Team A hears “we need CSV export” from a champion. They build a general exporter with filters, scheduling, and templates. Three months later, two accounts use it monthly. Support maintains edge cases. The core dashboard still confuses new users.

Team B runs the five questions. Evidence shows the pain is “I paste three numbers into a board update.” They ship a one-click “copy board summary” and park full export. Adoption is high among the renewing persona. The champion is slightly disappointed and still renews. Same request category. Different product judgement.

Exercise: the feature autopsy

When “just build it” is correct

Sometimes speed beats ceremony: a legal requirement, a clear blocker to activation, a bet with a tiny blast radius and a fixed review date. The five questions still help-they just resolve quickly. What they prevent is the vague middle: medium effort, unclear owner, eternal maintenance.

For problem-first sequencing before any of this, read the best products solve a problem before they sell a solution. External anchors I still send founders: SVPG on product discovery, First Round Review on focus, and Nielsen Norman Group on why more UI often means less usable.

How design and engineering should use the same five

If product writes a green-lit brief and design invents three extra modes “while we’re here,” you have not asked the questions-you have hosted them. The five questions belong in critique. Designers ask whether the interaction shortens first-win. Engineers ask whether the abstraction creates permanent surface area for a temporary bet. QA asks what failure would look like against the kill criteria.

• Design critique: remove anything that does not serve the stated behaviour change.
• Engineering estimate: include maintenance and support load, not only build hours.
• Release note: restate the painful behaviour you intended to change-so success is checkable.
• Retro: compare outcome to kill criteria without protecting egos or tickets.

Teams that share the checklist stop arguing about taste as if taste were strategy. Taste still matters. It just stops being the only vocabulary available when someone wants another toggle.

The quiet cost of saying yes

Unused features do not sit politely in the corner. They appear in demos you feel obliged to explain. They appear in security questionnaires. They appear in cognitive load for every new hire learning the product. They appear when you try to reposition and the UI still advertises last year’s bets.

That is why the opportunity-cost question is not philosophical. It is compound interest on distraction. If your launch underperformed and the instinct is to ship “one more differentiator,” pause. Differentiator theatre is still theatre. Diagnose readiness first-then decide whether a feature is the lever at all.

How this shows up in my work at nau

I use these questions when scoping websites and product UX alike. A settings page can be as vain as a SaaS module. We cut until the first win is obvious, then design. If your team needs a sharper filter on what deserves build time at all, start with how I decide whether a product is worth building.

Ask before you estimate

Before you build another feature, ask what behaviour changes, who benefits, what you sacrifice, how first-win is affected, and what would make you delete it. If those answers are weak, the roadmap is performing. Let it. Just do not ship the performance to production.