For a long time in my life, I raced to a deadline somebody else chose.
In that race, I packed every feature I loved into the product, defended every decision I’d grown attached to, and called it discipline. The reality was… it wasn’t. It was avoidance – avoiding the harder, quieter work of figuring out what feature, what aspect to drop.
Most product developers I’ve worked with – and, honestly, I’ll put myself at the top of that list – fall in love with what they’re building.
In my opinion, that’s a good thing. You need to care, you should believe in the thing matters. But be careful, because somewhere between caring about it and shipping it, you have to make peace with a brutal fact: the product you want to build isn’t always the product your customer needs to buy.
That’s where compromise comes in.
The product I wanted vs the product they needed
Francis Frei has a line I quote all the time: price, quality, and speed — you can only have two.
Pick, because you can’t have all three. And every product team I’ve ever sat with eventually hits a version of that wall.
You can build the feature-rich version, you can build the cheap version, or you can build the fast version. But not all three, trust me. And the moment you accept that, you stop arguing with reality and start designing within it.
The problem is, most teams don’t accept it. They keep adding, and they keep promising. They keep saying “we’ll fix it in phase two” — which, in my experience, is the most expensive sentence in product development. Reworking the product later costs you more time, more money, and more credibility than getting the essence right the first time.
Whose compromise is it, anyway?
Here’s where it gets interesting. When I ask teams what they’re dropping, they almost always answer from the supply side. They’ll tell me “We had to cut this feature because of cost. We had to delay because of engineering capacity. We had to simplify because of channel constraints”.
It’s all true, but it’s totally the wrong starting point.
The compromises that matter are the ones your customer is willing to make. What are they willing to give up? What’s essential to the job they’re trying to get done, and what’s just nice-to-have? Until you understand that, every internal decision you make is guessing, and guessing dressed up as strategy is still guessing.
A kick-ass half beats a half-ass whole
This is one I’ve said for years, and people get hung up on it, so let me explain.
In big corporate, I was taught to ship eight features that were okay rather than four that were extraordinary. The logic was that more equals more, unsurprisingly, the reality is the opposite. Customers will forgive you for the four features you don’t have, if the four you do have solve their struggle.
They will not forgive you for eight features that almost work.
When you understand demand deeply – when you understand the Job your customer is hiring your product to do – the question stops being “what should we cut?” and becomes “what’s the essence?” Cutting feels like loss. Identifying the essence feels like focus.
What the milkshake story actually taught me
People love the milkshake story because it sounds simple. Trust me, it really wasn’t.
One of the hardest constraints we ran into wasn’t customer demand at all, it was labor. The restaurant had a fixed line on productivity, and they weren’t going to add headcount. That single constraint shaped every recommendation we could make.
And honestly, we didn’t even see it until the end.
What I didn’t appreciate at the time, and what I tell teams now, is that those constraints — the ones written in permanent ink before anyone starts developing — quietly kill more good ideas than any market force does. A pricing ceiling, a labor target, a margin floor. Each one looks rational in isolation. And when they are stacked together, they make innovation impossible.
So when you’re starting out, get those constraints on the table early. Not to argue them away. To know which ones are real and which ones are just inherited.
Start with the essence, add only what earns its place
Clay Christensen used to say you have to seek profit first, because if you can’t profitably do the job, you can’t reduce costs afterwards – you don’t know the true value.
Taguchi taught me the same thing from the engineering side: figure out the absolute minimum you can do the job for, then only add cost where it adds value. Don’t build the maximum and strip back, instead build the minimum and earn every addition.
That reframes the whole compromise conversation. You’re not giving things up. You’re choosing what to add. And those additions are justified by what your customer actually values, not what you, as the developer, are emotionally attached to.
Time isn’t your enemy — but it isn’t your boss either
The last thing I’ll say is about time. Most of my career I treated deadlines as immovable and features as the thing I’d drop.
Now I flip it.
Time is just another lever. If the essence isn’t ready, the launch isn’t ready. A time wall is useful as a forcing function, but it can’t be the only thing in permanent ink. Otherwise you’ll ship a half-ass whole, and you’ll spend the next two years explaining why.
The product teams I’ve worked with who get this right share one habit: they surface potential compromises early, long before they have to make them. They don’t make the decision yet – they just see it coming. That single move, seeing the compromise before it forces itself on you, is the difference between rational design and panic at launch.