One of the most common problems I've seen in product teams - and one that is rarely talked about in product management circles - is a chronic lack of clarity over what they're actually optimising for.
There's an old project management concept called the Iron Triangle. You might have heard it referred to as the Triple Constraint, or more colloquially as "good, fast or cheap”. The idea is pretty simple; on any given piece of work, you can optimise for a maximum of two out of the three - speed, quality and cost - but always at the expense of the third.
If you want it fast and good, it won't be cheap. If you want it cheap and good, it won't be fast. If you want it fast and cheap, it won't be good.
It's one of those concepts that sounds blindingly obvious when you hear it, yet is almost universally ignored in practice. And in product teams, where everyone is perpetually under pressure to do more with less, getting this wrong can silently sabotage months of work.
Why it matters in product
In project management, the Iron Triangle is well understood - it's one of the first things you learn. But in product management, it rarely gets a mention. The conversation tends to revolve around prioritisation frameworks, discovery techniques and roadmap theatre, whilst the more fundamental question of what are we actually optimising for in this piece of work gets completely overlooked. This matters because not everything you build warrants the same approach.
When you're delivering something genuinely innovative - a novel feature that nobody has ever seen before, where there's significant uncertainty around product-market fit - speed is almost certainly your top priority. Get an MVP in front of real users as quickly as possible, learn from their behaviour and adjust course. It doesn't matter if it's a bit rough around the edges; you're testing a theory, not fine-tuning a masterpiece. Spending six months polishing something that nobody actually wants is a spectacular waste of time and money.
On the other hand, when you're building something well-established and ubiquitous - things like PDF exports, searching and filtering tools, email notifications etc - then quality is what matters most. You already know there's a need for this feature - it's table stakes. But because every competitor on the planet has it too, then being the best version of it is the only way to differentiate. Cutting corners here to save time or money is a false economy that'll come back to bite you on the arse.
And then there are the commoditised features - the ones that need to exist, but where nobody is going to choose your product based on how well they're executed. Think password reset workflows or system notification preferences. In Kano parlance, these would be the "must-be" qualities - their absence causes dissatisfaction, but their presence doesn't generate any delight either. Optimise these things for cost. Get them done, get them functional and move on to something that actually moves the needle.
The Agile trap
Most SaaS product teams operate some flavour of Agile, which - in its purest form - prioritises efficiency and rapid delivery. The problem is that, in practice, this creates a gravitational pull toward doing everything quickly and cheaply, regardless of whether speed and cost are the right things to optimise for.
I've seen this dozens of times. Teams churn through sprints at an impressive pace, releasing feature after feature, only for customers to quietly defect to competitors who took a little longer but delivered something that actually felt finished. Google Wave was the textbook example of this at scale - an over-engineered, under-focused product that tried to do everything at once but failed to do any of it well enough to retain users beyond the initial hype.
Conversely - and I've learned this the hard way - when a product team focuses exclusively on quality, everything slows to a crawl. Every detail is agonised over, every edge case accounted for, every pixel hand-crafted to perfection. Meanwhile, the market moves on without you. I've watched genuinely groundbreaking ideas wither on the vine because the team couldn't bring themselves to release something imperfect. They were optimising for quality when they should have been optimising for speed.
The DRY principle (Don't Repeat Yourself) - borrowed from software engineering and deeply embedded in Agile culture - often reinforces this bias. Teams are conditioned to build things properly the first time, to avoid future rework. Which makes sense in terms of code, but is a terrible philosophy to apply wholesale to product development, where the whole point is to learn fast and iterate.
What tends to happen is that quality gets relegated to the backlog. Teams will knowingly push out something substandard, tag any shortcomings up as UX debt to be addressed later, and move on to the next thing. That debt almost never gets paid down. Sprint after sprint, the backlog grows, and the product slowly accumulates a thick crust of half-finished features that individually seem harmless, but collectively erode the user experience to the point where customers start looking elsewhere.
A useful analogy might be running a restaurant. The menu - the innovative signature dishes that define your brand and give people a reason to walk through the door - needs to be exceptional. Spend the time, spend the money and get it right. This is where quality is non-negotiable.
But when a new seasonal dish is being rolled-out and you're not quite sure if customers will warm to it, it doesn't make sense to invest in bespoke crockery and a carefully-chosen wine pairing before you've even tested it. You prototype it as a special, get it in front of diners quickly, and see if it sells. Speed is the priority; refinement can come later - if it earns its place on the menu.
Lastly, the napkins, the salt and pepper shakers, the Wifi password card on the table - all part of the experience, but nobody is writing TripAdvisor reviews about this stuff. They just need to be there and to be functional. Spending a fortune sourcing artisanal, hand-thrown ceramic salt cellars when a standard shaker will do is a waste of money that could be better spent elsewhere. Every element of the restaurant experience warrants a different balance of speed, quality and cost.
Your product is no different.
Making it stick
Many of the issues I see - where product teams push out mountains of work, only for it to fall short of expectations - come down to a failure to define upfront which side of the Iron Triangle they're optimising for. Not at a portfolio level, but at an individual feature or initiative level.
The fix is ridiculously simple. Next time you're kicking off a new piece of work, whether it's an Epic Spec Sheet, a PRD, a design brief - whatever artefact your team uses to define and document the scope - include a clear statement about what the team is optimising for and what they're consciously deprioritising as a result.
Is this a high-risk innovative bet where speed-to-learn matters most? Is this a competitive differentiator where quality is paramount? Is this a commodity feature where cost-efficiency is the goal? Write it down.
Make it explicit, then make sure your product owner is reinforcing that message in sprint planning, stand-ups and retrospectives. It sounds trivially simple, but you'd be amazed how many teams have never had this conversation - and how much sharper their decision-making becomes when they do.
