6.4% of features get 80% of the clicks, according to Pendo.
That leaves the other 93.6% with the remaining 20%, and AI has just made that 93.6% a more seductive trap. When a first version takes an afternoon, "let's just ship it and see" sounds like the cheap option. For a product manager it is now the most expensive sentence in the job.
Shipping to learn is fine. Shipping with no exit is how features become permanent accidents. Every feature, used or not, still needs someone to support it, test it, document it and keep it in their head. Forever. The build got cheaper. The ownership did not.
So build speed is the wrong thing to chase. Here are twelve swaps that turn "let's ship it and see" into a decision. Each one trades something that feels like progress for something that decides whether the product earns its place. They follow the hourglass: what doesn't matter at the top, what does at the bottom.
Start with why it should exist
The first swap trades build speed for a reason to exist. How fast you can build the first version tells you nothing about whether anyone needs it. Before deciding how to build it, name the user, their problem, and why today's workaround fails. If you can't name the workaround, you don't yet know what you are competing with.
The second trades the business case for blocking questions. A business case with revenue forecasts is a guess written in a spreadsheet. The questions that can stop a product come from sales, legal and finance, and they arrive late when nobody asks early. Ask them what would stop it before you start it, in week one, while changing course is still cheap.
Both swaps move the hard thinking to the front, where it costs a conversation instead of a quarter.
Commit to the problem, then test the idea
The third swap turns a feature roadmap into a problem commitment. A roadmap full of features and dates promises solutions before anyone knows if they work. Put the outcome on the roadmap and leave the solution open. The team stays committed to the problem and free to change how they solve it.
The fourth turns the popular idea into the weakest assumption. The idea everyone loved in the room still has to survive real users. Marty Cagan's rule is that half or more of your ideas won't work, so plan for this one to be in that half. Find the assumption that would sink it, then find the cheapest way to prove it wrong.
The fifth turns a customer request into the actual problem. Building every feature customers asked for gives you a list of solutions they designed for themselves. Ask what happened the last time they needed it. The story behind the request points to the real problem, and the real problem is what you build for.
The sixth turns "I'd pay" into real commitment. Someone saying "I'd pay for this" costs them nothing. Ask for something that does cost them: their time, their data, or a paid pilot. A real commitment is how you test value before you write any code.
Bring in the people who make it real
The seventh swap trades stakeholder sign-off for an adoption plan. Sign-off from every stakeholder means they agreed to it. It does not mean anyone will change how they work because of it. Name who has to change how they work, and ask what it takes. Approval happens in a meeting. Adoption happens in someone's working week, and it needs planning like any other part of the build.
The eighth trades a finished spec for engineering input. A spec handed to engineering asks them to build an answer someone else already chose. Bring the problem instead of the spec, from day one, and ask what just became possible. As AI keeps changing what is cheap to build, the people closest to the code can see options a finished spec would have ruled out before anyone asked.
Measure what changed for users
The ninth swap trades features shipped for a user outcome. How many features you ship measures output. Pick the one behaviour that should change for users, then check it. If the behaviour did not move, the feature did not work, whatever the release notes say.
The tenth trades sprint velocity for a time budget. Your team's velocity tells you how fast work moves. It says nothing about whether the work is worth doing. Decide up front how long the bet gets before it needs to prove something. A time budget turns open-ended building into a question with a deadline.
The eleventh trades a polished prototype for observed use. A polished prototype invites compliments. Give 5 users a real task and explain nothing. Where they hesitate, misclick or give up is the feedback the polish was hiding.
All three swaps point the measurement at the user, where the value either shows up or doesn't.
Swap the launch date for a keep-or-kill date
The twelfth swap closes the loop. A launch date tells you when the feature goes live. It tells you nothing about when anyone will decide whether it should stay. Set a keep-or-kill date instead: the review date, the result that earns its keep, and who can remove it.
Iterating until it works only helps if someone has defined "works" and has the authority to stop. Without that, a weak feature stays because removing it is nobody's job.
So before the next feature ships, write three things down. The result that makes it a go. The date you'll check it. Who can remove it if it misses.
Three lines, and a bet becomes a decision.
The 6.4% were decided before they were built
Pendo's 6.4% didn't get there by being fast to build. They got there because someone made a decision before the first line of code.
Read the twelve swaps again and they all move the same thing earlier: the reason, the blockers, the riskiest assumption, the adoption plan, the measure of success, the exit. They don't ask you to build slower. They make sure the build is pointed at something worth keeping.
The craft of product management is heading the same way. As building gets cheaper, the part of the job that holds its value is deciding what deserves to exist, and having the discipline to remove what did not earn its place.
Which of the twelve does your team skip most? Start there.