The difficult product decisions begin when three credible arguments point in different directions. The customer has a real need. Engineering sees a constraint. The business sees an opportunity. A roadmap can record the outcome. It cannot make the tradeoff disappear.
The trouble is that customer need, technical reality and business value do not always deserve equal weight. Sometimes one of them is the constraint that makes every other argument secondary.
Start with the hardest thing to reverse
A missed quarter can be recovered. A customer can sometimes be won back. A platform decision that turns every future release into a migration project is harder to unwind. The same is true in the other direction. A beautifully extensible architecture for a product nobody values is not strategic patience. It is expensive optimism.
When the three forces disagree, I start by asking which mistake becomes most expensive if we discover it late. That changes the discussion from “whose priority wins?” to “which uncertainty deserves attention first?”
Which decision is hardest to reverse? Irreversibility deserves more scrutiny than visibility.
Which assumption has the weakest evidence? The loudest stakeholder is not necessarily where the uncertainty sits.
Which mistake compounds? Some decisions cost once. Others create years of support, complexity or market confusion.
A customer problem can still lose
This is uncomfortable because product people are trained to put the customer at the centre. I do too. But “customer centric” cannot mean that every real customer pain deserves to become product direction.
A problem can be painful and still belong outside the product if solving it destroys the economics, creates permanent complexity for everyone else, or takes the company away from the market it is actually equipped to serve.
Customer truth tells you the problem is real. Product judgment tells you whether your product should own it.
Technical reality can also be the deciding constraint
I am comfortable asking engineers why a structural change is necessary. Not because I want to redesign their solution, but because technical decisions sometimes quietly redefine the product.
If the proposed solution creates a new data model, a permanent configuration path, a new operational dependency or a migration obligation, that is no longer an implementation detail. It changes what the company can promise later.
That is when technical reality becomes the binding constraint, even if the customer request is attractive and the revenue case looks good.
And sometimes the business should win
There is a version of product thinking that treats commercial pressure as contamination. I do not buy it. A product that cannot support a viable business eventually stops serving customers too.
If a feature creates real customer value but only for a segment the company cannot serve profitably, the economics matter. If entering a new market requires years of education with no learning advantage from being early, timing matters. If a “strategic” initiative repeatedly consumes the team while the core product loses customers, focus matters.
The decision I want to make
I do not want a compromise that gives every stakeholder a little of what they asked for. I want to understand the constraint that dominates this decision, make the trade off explicit, and define what evidence would make us reconsider.
Sometimes the customer wins. Sometimes the economics do. Sometimes the technology says “not this way, not yet.” The important part is knowing why.