You and your team have decided it’s time to build a new feature. You’re adding wings to your flagship car but you aren’t sure whether they should be swept forwards or back and you can’t decide. So what do you do? You run an experiment!

Do people like one type of wing over the other? Are they more or less likely to buy our car with a certain type of wing, or no wings at all? What if we tweaked the wings ever so slightly? Would that increase conversion by 2% so we can reach our targets?

While I’ve never worked in the car industry, I’ve seen this type of thing happen in software companies a hundred times over, and I’m here to tell you that not everything needs to be an experiment.

Part of being an engineer, designer, or product owner, is that you gain experience over time as you build software and as you use software that other people have built. This experience, instinct, and taste, is a large part of what you were hired for; not just your knowledge. Companies want people who can help them make decisions, and that’s what sets you apart.

So if that’s what sets you apart, why are we so afraid to make a decision? It seems like we defer to experimentation because we don’t want to be wrong. The thing is, a lot of the times those decisions are fairly inconsequential.

Yes, if you’re building a flying car it’s important to put some effort into deciding what type of wing you want before you invest millions in building a prototype. But if you’re experimenting with what colour a button should be, I just don’t think it’s worth the overhead of experimenting with that decision. You should put your mind to the task and come up with which button colour you think is best, and be able to explain why. This way can save your whole team a lot of time and effort and they can focus that experimentation time on the car wings instead.

Use that experience you’ve built up over years of building and using products to form an opinion on what you think is the best way forward and don’t delegate that responsibility to experimentation.