Introduction

This post is a short excerpt from a conversation I recently had about our relationship with product, regarding polishing and shipping, perfection and experimentation.

Perfection is the enemy of the good

I am a big firm believer of perfection is the enemy of the good. In my career so far, the two main roles I have had are either running a data team or running a product team. In both those roles you need to ship continuously and sometimes also quite accurately (e.g., if you are running a data team). I saw among people just getting into product or data roles, a maniacal focus on shipping something that is bug-free, which simply doesn't work.

People get conditioned through parenting, schooling and society to be correct. If you are not correct, then you are wrong. And the fear of being wrong is paralyzing.

In product you always have to ship. You have to ship something, anything, but you have to ship.

Thinking too hard to reach perfection is a sure shot way to get in the way of shipping. The net result of not being able to ship means:

• Delayed market entry,
• Losing out to competition,
• Not learning quickly enough from user feedback, and the list goes on.

What questions do we ask ourselves at Paradime?

One might as well ship something that has bugs. Then figure out what those bugs are from user feedback and solve it fairly quickly. We would rather not think too hard about what could happen and then get paralyzed. And that's been our ethos all along. We ask ourselves everyday, how can we get rid of things from the roadmap? How can we break a feature down to as small as possible to start shipping? How can we get it done so we can kick off the feedback loop?

But what are we really thinking?

Shipping constantly and continuously can feel like running around from feature to feature like headless chickens. But there is order in the chaos.

We think really hard about what architectural patterns we can build assuming:

• 100% certainty that there are going to be bugs
• How to optimize our architecture, team, and roadmap for solving bugs super quickly?

The goal is to build a system architecture that allows us to rapidly iterate. Bugs and customer feature requests are inevitable. So we need to build an architecture and a system that allows us to respond to that in the fastest possible way.

We think continuously about how to execute at warp speed. We should be able to ship constantly across design, and engineering knowing fully there will be bumps and flat tires along the way.

Lego blocks vs Jenga tower

‍We want to make sure that a bug or a feature request or something else should not slow down product development. We have to build an application that is not clunky, and that building one additional feature or fixing something on top doesn't burn the whole house down.

So we spend a lot of time as a team thinking regarding Lego blocks and not regarding a Jenga tower. On a Lego block, if we pull something out, and we put something in, everything sort of cohesively fits with each other. On the other hand, in Jenga blocks, when you move a single piece, the whole house can just fall apart. A classic example is removing/updating just one piece of infrastructure or something else that looks the same as everything else, a major outage happens. And the whole house comes crashing down. Another extreme is dealing with minor fires everyday that destroy the concentration and morale of the engineering team.

We ship, polish, experiment, and throw away all at the same time.

So we like to think a lot in terms of Lego blocks and how we can

• assimilate as we go along,
• ship things out as we go along, and
• chip away as I go along

No big bang, just intense daily raw execution.

The concept of progressive assimilation and replacement is our idea of product building.

‍

Sign up for a FREE 14-day trial or schedule some time with our team to learn more about Paradime 💪