Lean Execution: How to Stay Focused

When building a company and shipping a product, it’s both critical and extremely hard to stay focused. Much has been written about this subject before. I’m sharing here which three questions I’m trying to ask myself to help to stay lean.

Why do we need this feature?

Most of the time, you or a colleague got a great idea to improve the product or the company. Especially, when you have not found product-market fit yet or the company is growing, you might feel the urge to add things, change things, and generally make sure you are set up for success. However, I find myself often in discussions bout how to implement said change/feature instead of why? Before going into the actual implementation, I try to understand two critical aspects:

When do we need this feature?

Before talking about how to implement a feature, it’s critical to understand where it fits in the roadmap. If you anyway decided that the feature does not add any benefit (see question 1), it’s likely not worthwhile to specify a concrete timeline but rather give it some sort of medium or low priority on the backlog. However, if it’s an important feature, the next step is to understand the dependencies of where it fits in the roadmap.

Some key questions I like to think about:

How should we launch the feature?

After understanding the added value of the feature and its order in the timeline, the next step is to understand how the feature should be launched. Sometimes this process is overlooked but I find it helpful to acknowlegdge that you can and often should simplify features to their core value proposition. In crypto, the first iteration of Uniswap was simple but it worked. MakerDAO launched with a single collateral asset and it worked as well. Identifying the critical feature set is a hard exercise and requires an excellent understanding of user demand and competitor position.

I’m an engineer and researcher at heart and we tend to often strive for a perfect, over-engineered solution that covers every edge case. It’s even worse coming from a security-focused background where your first step is to ask: How do we break this protocol?

In the product world, I found it often acceptable to tolerate limited sub-optimal edge cases in the product, acknowledge them, and fix them later. The point here is that you want to get a product out at the right time. And more often than not, getting the feature out with its essential benefit and have it “good enough” saves significant effort.

This last point I find often overlooked. Additional complexity in the feature costs us often 3x more time investment down the line since it’s not just the design that is more complicated. It’s also the implementation, the documentation, and the testing that are proportionally more involved.

Related Posts

  • 06 Nov 2018 » Analysing Ethereum contract gas costs during development
  • 12 Sep 2018 » Analysing Bitcoin smart contracts from a mechanism design perspective
  • 14 Feb 2017 » Integrating Python and Ethereum