As product developers, we face constraints every day. But here’s the thing most people miss: trade-offs aren’t just about what we can live with – they’re about understanding what trade-offs our customers are willing to make.
Francis Frei says it best: price, quality, and speed – you can’t have all three, you’ve got to pick two. One is going to have to not be what you want, because it’s just not possible. But the real question isn’t what trade-offs we need to make.
It’s whose trade-offs are we making?
It’s not about your perspective
I can make trade-offs from my perspective about the product, but in the end, it’s about the trade-offs consumers are going to make about the product or service. How do we understand and mimic their trade-offs into how we design the product?
This is where empathetic perspective and trade-offs work hand in hand.
You have to understand from different perspectives what the constraints really are.
For developers and business leaders, two of the big perspectives are supply and demand.
From the demand side, ask yourself: Am I willing to pay more for that feature? Is that feature going to help me build the habit? From the supply side: How much does it cost? How technically possible is it? Is this something we’re going to build upon?
Trade-offs can only be made successfully from an omniscient or big picture perspective. You can’t do it from only one side.
This post is also available as a podcast, check out identifying trade-offs as a product developer.
The cascading effect
Here’s what catches most people off guard – trade-offs stack.
What looks like one trade-off is actually five or six. You’re willing to give up one thing to get another, and they add up across multiple dimensions.
That’s why you need to play things out through time.
Without understanding where things break – where your thresholds are – it’s pretty hard to make good trade-offs.
Making trade-offs in product development is literally the combination of all the other skills we talk about. You can’t make good trade-offs without understanding contracts, causal structures, and empathetic perspective.
When to start thinking about trade-Offs
There are two steps: first, identify the trade-off – the contradiction. We can do this, or we can do that, but it’s going to be hard to do both. Second, frame what’s diametrically opposed and decide which is more important to satisfy.
The key is bubbling these up very early. You don’t have to make the decision right now, but know they’re coming. It’s about learning and seeing things sooner in your development process so you’re ahead of the curve instead of making rash decisions at launch.
Launch is the worst time to make trade-offs. You’re not panicked, but it’s the point where you think “we just got to get this out here.” From a micro level, those decisions might seem rational, but from a big picture perspective, they’re usually wrong.
The three buckets
Before making any trade-off, make sure you understand three buckets:
Supply side: What’s your business model? How do you make money? What channels are open? What are your technical capabilities?
Demand side: What does the customer really want? How do those people buy? How important are they?
Technical capabilities: What can you really do? Sometimes you have to make a trade-off to do something less optimal but within your capabilities, knowing it will satisfy the other buckets but not completely.
A trade-off made by one silo is a trade-off that’s wrong. It will be revisited a thousand times. When you make a trade-off, you want people to understand that’s what it is. When we make this trade-off, we’re going to get these complaints, and we’re okay with it because we chose that.
Time as a tool
For too long, I raced to deadlines that somebody else chose that weren’t rational, forcing me to make trade-offs. I didn’t realize time was something I could also use as a trade-off.
Create a time wall—an expiration date that forces you to step back. Instead of trying to pack everything in, if you can’t do it well, maybe you shouldn’t launch right now. But make sure it’s grounded in realistic expectations with metrics attached. Just because you hit the time wall doesn’t mean you have to launch.
The real metric
Most people have metrics based on what they planned – what they think people want. I use a different reference point. Instead of looking forward, I look back: How much progress did we make? How much progress is this for the customer?
The metric should be about the distance they’ve traveled, not the gap between what you said you’d do and what you did.
Your turn:
Take a trade-off you’ve made in the past and do a postmortem. What information did you have then? What do you know now that you wish you had? Could you have used someone as a sounding board?
If you could do it over, what would you do differently?
Remember: it’s not about getting everything right – it’s about getting the essential things right based on what your customers are trying to do, not what you want to do.