The most dangerous product decisions are the ones nobody remembers making.
Every product team runs ten of them. They are unnamed, unreviewed, and still deciding things every week. This page walks through each one and how to bring it into the open before it decides again.
Picture the meeting that comes round every quarter. Cut scope or push the date. Engineering has no more room. Sales already promised the customer. The product manager is holding both, and nobody has a decision, so every round starts from zero.
Because nothing gets decided, the argument gets read as personality. One person looks reckless, the other looks slow. In fact they are protecting against different risks, and neither has said which one. Nobody is wrong. One side is guarding against a risk the other has not named.
The real question is which risk this decision can afford to get wrong. So the accepted cost has to be named out loud. An unstated trade has no expiry date. It keeps deciding long after the reason behind it has changed.
Here are the ten tensions, each as a pair of pulls and the question that settles it.
Demand vs bet
The default is to treat what people say they want as proof of demand. A request feels like evidence, so it goes on the roadmap as a sure thing.
The better move is to ask what people do today. If they have built a workaround, with a spreadsheet or a manual step, that is demand. If there is no workaround, you are making a bet. Bets are fine, as long as everyone knows that is what they are.
A workaround is the customer voting with their time.
Explore vs commit
The default is one more round of research. It feels careful, and nobody gets blamed for being careful.
The better move is to name the evidence that would change the decision. If you can name it, go and get it. If you cannot name it, more research will not help, so commit.
Research without a question to answer is just a place to wait.
Focus vs hedge
The default is to keep several bets alive "just in case" and call it hedging.
The better move is to give every live bet a different question and a kill date. If two bets are testing the same question with the same evidence, that is not a hedge. It is split focus, and each bet gets half a team.
A real hedge answers a different question. Anything else is the same bet paid for twice.
Adoption vs revenue
The default is to see a weak number and reach for the first fix on hand.
The better move is to separate retention from monetisation before you pick a fix. If people do not come back, fix the value. If people come back but do not pay, fix the offer. They are two different problems with two different fixes.
Pick the fix after you know which number is broken.
More voices vs one owner
This is the tension behind the quarterly meeting that never ends. The default is to add one more stakeholder or one more review, in the hope that agreement will turn up.
The better move is to ask, before adding another voice, what that voice can still change. If the answer is nothing, name the owner and close the call.
Another opinion only helps if it can still move the decision.
Polish vs find out
The default is one setting for the whole team: either everything ships polished or everything ships fast.
The better move is to name who pays when the product is wrong. If users cannot absorb a mistake, polish. If you can reverse it, ship and find out.
Same team, same week. A payments migration is irreversible, so you polish every edge case. An onboarding prompt is reversible, so you ship it and find out. Opposite settings, both right. The difference is who pays when it goes wrong, and whether it can be undone.
Fit one vs fit many
The default is to build what one important customer asked for and call it a feature.
The better move is to name the next three customers who need it for the same reason. If you cannot name three, it is custom work, not a segment.
One loud customer is a deal. Three with the same reason is a market.
The user vs the rules
The default is to treat every rule as fixed and design around all of them.
The better move is to classify the rule first. Is it law, a safety requirement, or a convention? Design within the first two. The third is a habit, and habits can be challenged.
Knowing which kind of rule you are facing tells you whether you can push on it.
Ship the fix vs fix the cause
The default is to patch the failure and move on, then patch it again next month.
The better move is to do both, in order. Contain the first failure so the customer stops feeling it. If it comes back, or creates recurring work for the team, remove the cause.
A fix you keep shipping has become a cost you keep paying.
Default vs exception
You join a new team and the settings are already running. Nobody explains them because nobody remembers choosing them. They were set for a different stage, a different risk, sometimes a different company entirely. With no reason attached, nothing ever flags them as outdated, and someone else's judgement becomes your team's baseline.
The better move is to finish one sentence for each setting: we set it here because... If the answer is habit or precedent, reopen the decision now.
A default has momentum. A decision has a trigger.
Set it, price it, reopen it
All ten tensions work the same way. Some you set for each decision, others you set once at product level and review every quarter. Either way, three moves turn a hidden default into a decision.
Set it: say where the dial sits for this call. Price it: say which risk you are accepting. Reopen it: say what evidence would move it.
None of these pairs has a right answer that holds forever. Demand can turn out to be a bet, and yesterday's exception can become today's default. What causes trouble is a setting nobody chose on purpose and nobody knows how to change.
Pick one setting your team is running right now and try to finish the sentence: we set it here because... Where you get stuck is where to start.
Download the one-page version and keep it where you run your next planning session.