When creating a product, there’s no such thing as perfection — only tradeoffs
How the pursuit of perfection can create a monster
It all starts innocently enough. We’re doing some good things.
But we realize there are all these other things weshouldbe doing too, so we try to do all the things. Eventually, we create a monster.
We end up in a trap we can’t get out of.
Every meeting is good, so all have to be attended. Every process is good, so all have to be followed. Every tool is good, so we have to use all of them. All features are good, so none can be removed from our products.
These tendencies mean, in aggregate, that we can end up with very little time to actually build anything. Our products can become more complicated, and there’s no time to simplify things.
The result? Thin slices of productivity get further subdivided by the complexity tax. The fun parts of the product get obscured by the clunky parts.
[Read:How do you build a pet-friendly gadget? We asked experts and animal owners]
I don’t have aperfectanswer for situations like this. It’s easy for someone on the team tosay you should do less, but it’s much harder for a team to agree on what you should stop doing. The “correct” subset, after all, is subjective.
And even if you could agree, it takes time to simplify things. It’s ironic, but it usually takes time tostopdoing something. In software engineering, for example, removing a feature takes time because you have to remove the code, update your docs, and more.
Having said that, there are some things you can try.
Try to be complexity neutral or better
If you’re asking someone to do something, think about how you can make their lives easier and not just harder. That means asking potentially counterintuitive questions.
Is there an existing process you can remove to make room for a new process? Is there some other task you can at least delay to give time to build a new habit? If you’re asking someone to use a new tool, can you givetime for training? If you’re already adding some other new tool, can you just finish that transition first? When you hire someone, can you think about what they might remove and not just what they will add?
These aren’t obvious questions, but they’re necessary. Make sure you’re asking them.
Acknowledge the math
It’s not possible to do everything.The more you try to do everything, the more you’ll take shortcuts. You’ll just check a box, and as a result, you’ll create those weird overlapping circles I showed you above. Or you’ll start doing things that you arguably shouldn’t even do.
Some tasks require waiting on other people to completetheirtasks. This is called wait time. There’s basic math at play here, which this chart shows well.
If you don’t trust the math, there’sa great videothat illustrates this “resource utilization trap.”
If you don’t have idle time, wait times effectively reach infinity. If you feel like nothing is getting done but you’re really busy, it’s probably because everyone is busy waiting on each other. There are two solutions to this:
Both are important. You can never remove all dependencies, so you have to have some idle time to help each other. But you do want to remove as many dependencies as possible, so that people can help themselves.
At Zapier, this reality motivated some key changes: we’re working on making different parts of our product less interdependent. This means each team that owns a service can make autonomous decisions, so they don’t have to wait on other teams.
But when you remove dependencies in this way, youreallyhave to remove them. If you do the work of dividing up parts of your product but teams still consult each other on every decision, then you’ve actually just made the problem worse. You’re paying for more people to do the same job, but slower.
Sometimes you’ll have no choice. There will always be things that require teams to cooperate. In other cases, the cost of inconsistency is too high. This is why you need to reserve idle time for these cases.
Make explicit tradeoffs
If you accept that perfection can’t be reached, and that everything you add has the risk of making things worse, then you can start making tradeoffs.
It’s easy, if you have a problem, to think of the solution in isolation—to work as though you have infinite time and energy for that one solution. But you exist in the physical world, where there are constraints.
The desire for consistency has tradeoffs. Teams can either be free to ship what they want and how they want, or they can be forced to use a shared solution and follow a shared process. Sometimes you have to choose the latter, but you have to be aware of the impact that has. Ignoring that means accepting an ad hoc mixture of chaos and deadlock.
Our product at Zapier is a good example here. Our desire to have a single product that fits every use case and every customer has tradeoffs. The product is a blank canvas, which can make the value proposition hard to grok. We’re continually balancing ease of use and power.
One option for us might be to create specialized products that are easier to understand. The problem, of course, is that this would mean more complexity in our documentation, support tools, onboarding, organization—the list goes on. Those products also might not always integrate well, and customers might get confused.
That tradeoff is fine, as long as we’re explicit about it and everyone understands it. If we want to avoid that confusion, we’d have to invest more in a consistent experience for our users, which is another tradeoff since that’s time we can’t be using to build more products.
I could go on. The desire for planning and visibility and metrics has tradeoffs too. We do these things to make better decisions—that is, to makeperfecttradeoffs. But there are no perfect decisions. Sometimes we just need to acknowledge the math, promise to be complexity neutral, and plan for a potential rollback if things turn out ugly.
Story byJustin Deal
Justin lives in St. Louis with his wife and two kids and dog. He loves to code, especially JavaScript, and occasionally writes some music.Justin lives in St. Louis with his wife and two kids and dog. He loves to code, especially JavaScript, and occasionally writes some music.
Get the TNW newsletter
Get the most important tech news in your inbox each week.
