How Startup founders can avoid the Build Trap?

Last month, my friend calls me up in the evening. He was in a nearby cafe with one of his college batchmates. This batchmate of his has been working on a startup idea building a Local Discovery app. Being from a non-Product Management background, he was looking for some guidance on how to build his product. So he invited me to join them for the conversation. I agreed immediately and by the next 30 minutes, I was having a discussion with them.

What I could understand from the discussion is something I could relate to some of the discussions I have had with other startups in the past. Most of these startup founders were not from a Product Management background and more often than not they get swallowed into the “Build Trap”. Now I am not implying that only non-product managers face this issue. Many times, even seasoned Product Managers face this problem. That’s why I thought its something worth writing about.

What is the Build Trap?

Any product (or service) exists to solve the customer’s problems. And while doing so, it captures value. The value may be in terms of dollars, data or anything that is valuable to the business.


Facebook: Helps its users to stay connected online by sharing status, pictures, stories, etc. In turn, it gets valuable data on the users which it uses for targeted marketing.

Uber: A cab-hauling service where it helps the riders to easily book a cab. At the same time drives more business for the cab drivers. Gets a share of the fare from the drivers.

Now the term “Value” is a confusing term. What might seem valuable to you might not worth a dime to another person. Since measuring value is a difficult task, companies often use a proxy in its place.

Often the proxy is one or combination of the following:

  • Number of features shipped out or added to the product
  • Number of user stories delivered

As you can see, this is a wrong representation of the value delivered to the customers. Hence this often leads to the wrong outcome and not show the real-world scenario.

Startups working on launching their products often end up in this “trap” as they try to build every feature before shipping it out. Even if it might look good on the surface, what we need to understand is that this process is quite resource-intensive and increases the time to market. And after months (or even years) of working on the development, in the end it all becomes a lost cause as users are not using your product.

Melissa Perri talks about how companies often get into the “Build Trap” in Escaping the Build Trap.

How to avoid the “Build Trap”

Maintaining a balance between Discovery and Delivery

What’s your Desired Outcome?

Start with the End Goal in mind. This is something we all have heard and quite relevant in this scenario as well.

Ideally consider a quarter and think of the goal you want to achieve by then. For certain companies, this timeframe might be smaller or greater than a quarter’s time. There is a great book on how companies perform fast experiments to validate their ideas or test the hypothesis — Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days. In case you have not gone through it yet, I would strongly recommend you to get a copy for yourself.

Let’s say the month-end goal for the “Local Discovery App” startup is to get their first 1000 customers.

What’s stopping you from getting to your Desired Outcome?

As startups or Product Managers, we often deal with the unknowns. That’s why the “Discovery” phase is so important. In the discovery phase, we start with the hypothesis. These are the various blockers that might be deterring us from meeting our end goal.

Some plausible blockers deterring us from meeting the End Goal might be:

  • People are not aware of the platform
  • Local stores don’t want to update their information on your app

Once you have formed your hypotheses, the next step is to validate them, aka the Experiment Phase.

Experiment Phase

Often startups and companies miss this phase altogether. What they do is pick up one hypothesis based on their assumptions, treat it as “THE” problem to be solved to meet their goal, finally spend all their resources to solve the problem. As you can understand their success would be heavily dependent on chance. In a few cases, this might work. In a majority of cases however, the chances of failure are high. Since a Product Manager’s primary responsibility is to reduce risk or uncertainty, spending all your resources based on assumption would be a big “No”.

Rather than going ahead with one assumption, test all your hypotheses (at least the top 3 or 5 ones which you consider the most important ones). This will give you a good insight into which are the critical problems that you need to work on and in what order.

Performing fast experiments is slowly becoming a norm in the tech companies or teams today. As mentioned in the book Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days, Google does it extensively.

Finally, it’s time to build the Feature

By now, you would have pinned down on the key feature or set of features required to meet your goals. You would have also created a priority in which the features are needed. So it’s finally time to build your feature. You would notice that now you have fewer features than what you would have had if you did not carry out the experiments.

Today, companies are shipping out their products in a week’s time. Many do it in days’ time. Fast delivery is the need of the hour in today’s world. That’s why it’s quite important to ensure the development team is focussed on the work they need to do and have proper communication channels in place to support their development activities.

If you are new to Agile or want to know more about the best practices while working in an Agile framework, there is a good book by Roman Pichler — Agile Product Management with Scrum. This book gives a good overview of how Product Managers create successful products using Scrum and Agile.

Don't forget to measure your metrics

Product Management is not a one time process. It’s more of an iterative one where the product team goes through continuous Discovery and Delivery phases. That’s why the PM needs to keep a close tap on the metrics. The KPIs or the metrics would indicate how well the feature or product is able to meet the “desired outcome”.

I have shared some good books on Product Management in my previous article. You can find them here.


  1. Escaping the Build Trap — Melissa Perri
  2. Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days
  3. Agile Product Management with Scrum — Roman Pichler
  4. Introduction to Modern Product Discovery — Teresa Torres

If you are a startup and have questions about building your product, you can connect with me on Twitter or Linkedin.



Product Manager | Product Enthusiast | Nature Lover

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



Product Manager | Product Enthusiast | Nature Lover