Jan 9, 2019
How to Make Things High-Quality
If there is one debate that is the endlessly circling “Star Wars versus Star Trek” of product development, it is what I refer to as “The Tradeoff Between Quality and Time” (TTBQT). Here’s how it typically goes:
Alice: The way we’ve built X is pretty janky/slow/hacky. I have a better solution.
Bob: But we’re on track to finish in 2 weeks. Is it worth pushing back our launch to fix the jank/performance/hackiness of X?
Alice: But we care about quality.
Bob: But we care about shipping.
Alice and Bob then face each other with grim expressions, hands grasping gleaming lightsabers as they prepare to duel it out… oh wait, wrong story.
What happens is that maybe one side convinces the other, maybe the decision gets escalated, but eventually the team accepts either delaying the ship date or okaying a worse-quality output, neither of which feels worthy of celebration.
You might think, But this is how it is. TTBQT is a necessary evil in building anything.
But is it?
Don’t get me wrong, it’s healthy to bring up this tradeoff from time to time to ensure we’re not polishing to diminishing returns or letting the timeline run product development. But I’d like to propose a third option.
When you get into a TTBQT state, the real question to ask is: “If we knew X would take this long to get to high-quality, would we have opted to do it in the first place?”
This is a powerful question because it forces the team to examine what actually went wrong, which is typically:
- How ruthlessly the team has prioritized.
- How accurate the team’s estimates are around its ability to execute.
- How good the team is at actually executing.
The second reason I like this question is because it helps to clarify what the TTBQT decision should be. If the answer is “No, X isn’t worth the time it’d take for us to make it high-quality” then cut Feature X altogether. Just stop working on it.
But wait, that’s terrible,” you say. “X is 90% there. We’d be wasting all that work if we don’t ship it.”
Indeed. It hurts to waste time and effort. We get attached to the things we work on. But that’s the Sunk Cost Fallacy talking. If you don’t think a feature is worth the time it takes to make it great, then it is not rational to ship a crappier version simply because you have sunk time into it.
If the answer is, “Yes, we still would have invested in this feature knowing how long it would take to make it great,” then that indicates X is really important and it’s worth the effort to make it not janky/performant/well-constructed.
Over time, asking yourself this question when you get to a TTBQT situation forces you to become more ruthlessly focused up front. You get better at prioritizing the most important things to work on, your estimates become more accurate, and you execute better.
It’s a mistake to conflate success with shipping a large quantity of features.
Instead:
- Make a list of what your team is working on.
- Ruthlessly prioritize each thing in ranked order based on importance.
- Cut hard. You can’t do nearly as much as you think you can. (For example, I thought writing this note would take me 1 day. It’s now Day 5.)
- Execute well. Set weekly milestones. Operate with a sense of urgency. If #1 starts to slide off track, look at cutting #5, #4, #3, etc… until #1, #2, etc. is set up to succeed.
- Ship high-quality work (and succeed or fail with confident learnings). Your users deserve it.
- Do fewer things better, but make them the most important things.
