← Thoughts

Two People, Two Right Answers, One Product

· 2 min read · Tim Cooley

Two people are in the room, DEV standing with arms crossed near a whiteboard covered in two competing diagrams and PRIYA sitting with her laptop open to a half-built feature, both mid-argument and neither backing down. There are no other people anywhere in the room.

My wife likes the thermostat at 68. I like it at 72. There is no temperature that makes both of us happy, only one that makes both of us slightly annoyed, which somehow used to feel like winning.

I ran product decisions the same way for a long time. Priya wants to ship the flexible version because three customers asked for it and she can see the next two years of requests coming. Dev wants the simple version because it ships Tuesday and the flexible one might not ship at all. Both of them are right. Not right in the sense that one of them is secretly wrong and I need to find it — right in the sense that if I sat with either case alone for ten minutes, I'd agree with it.

I used to try to split it. Build half the flexibility, ship a little later than Dev wants, a little narrower than Priya wants. It rarely worked. Nobody got what they needed, we lost a week, and the next month we were having a version of the same argument again because the actual disagreement never got resolved, just diluted.

What I do now is ask a different question. Not who's right, but which choice we can undo. If we ship simple and it turns out we needed flexible, how bad is that fix — a sprint, a quarter, a rewrite? If we ship flexible and it turns out we didn't need it, what did that cost us? I'd been doing a rough version of this for years — pick the smaller bet when you're not sure — before I ran into the actual language for it, reversible versus irreversible decisions. Having the name didn't change what I do. It made it faster to explain in the room, which matters more than it should.

The part I still get wrong: I misjudge reversibility more than I'd like. I've called something "easy to undo" that took us six weeks to unwind, because I was looking at the code and not at the customers who'd already built workflows around it. So I lean toward reversible, but I don't trust my own read on what actually is.

If you've had this argument recently — how do you tell the difference between something that's actually reversible and something that just looks like it is until you try?

perspectiveproductdecision-makingleadership

When Two People Are Both Right, Pick What's Reversible | Tim Cooley