Software teams spend 1000s of hours and millions of dollars every year building and launching projects that fail. They cost too much, customers don't want them, and the business eventually closes the product and writes it off as a loss.

How can we avoid wasting time, energy, and resources building projects no one wants?

In this post we'll dive into a Simple Scalable system for avoiding project waste every time.

The Build Trap

"The Build Trap" was coined by Melissa Perri in the book Escaping the Build Trap.

The Build Trap is essentially when a team / organization focuses on:

building stuff > impact of stuff

Building stuff is itself not a bad thing - we must change to solve new problems and capture new opportunities - and as software teams, building stuff is typically our primary way of affecting change.

But the idea of just building stuff without regard for impact. This is the trap.

Anecdata: I see this all the time in product teams. A common one is when we prioritize "cleaning the backlog". These backlogs can hold 100s and even 1000s of tasks depending on the size / age of the team. By definition these are things that have not been the highest priority for months or even years - that's why they're sitting in the backlog and haven't been done yet.

There often are a few gems in there worth prioritizing but for the most part it's better to let impact drive prioritization, not ideas out of context.

We'll talk more about this next.

Focus on a Problem

So how do we shift our focus from building things to the impact of those things?

A tried and true way is to focus on solving problems.

A problem is something that's getting in the way of a real person / process from doing what it wants / needs to do.

Thus solving a problem has real, data-backed value to that person / process. This is essentially a pre-validated business opportunity!

We have all the trappings of a lean business thesis:

• Market / Audience: With real people / entities associated
• A Value Proposition: Solve that problem you're facing
• An Offering: Build the thing that solves that problem

Anecdata: This is exactly what YCombinator recommends to startups:

• Build something people want.
• What do people always want?
• To have their problems solved.

Start with a Hypothesis

How do we make sure we're focused on an actual problem in the real world? (aka not a build trap)

We can take a lesson from #science - a field that has spent centuries trying to make sense of the unknown and make accurate predictions on a foundation of assumptions. As a business, if we can do this then we can have a better idea of what our customers want and stop wasting resources building stuff they don't.

Everything starts with a hypothesis. We don't know exactly what our customers want - otherwise we wouldn't be wasting our resources in the first place!

A hypothesis is a quick way to clearly declare what we believe and what we predict will happen if that's true - crucially in a manner that's testable. This serves as an easily-shareable high level description of the project that we can send to stakeholders for feedback. Moreover it provides bounds for the rest of the project, making it clear when we start getting into feature creep - adding additional work with little impact.

Create context for why we're doing this work:

• What problem are we solving?
• How do we know it's a problem? For whom?
• Why does this make sense for our team to build?

Once we have some bounds for the project, we can come up with potential ways to solve the core problem. Context boundaries provide a built-in way to rank solutions based on real-world impact so not only are we ensuring our project has inherent value but we now have a great framework for choosing the best way to solve it within this context.

Test the Hypothesis

Now of course we still can't know for sure whether a project will succeed until we try it. Even though we've pre-validated that our project has some inherent value by solving a problem, it's still possible to fall prey to any number of other issues that lead to failure.

So the next course of action is to test our hypothesis and change course based on the results. The best way I've found to do this is fast, cheap Creation Cycles using Minimum Viable Experiments - the minimum thing you need to build to effectively test your hypothesis.

This won't guarantee you'll ship sucessful projects - most experiments fail. But it will allow you to identify bad directions faster and cheaper, leaving more time and money to try new ones.

Next Steps

You can get the full project hypothesis I use in all my projects for free at Creation Cycle where I'm compiling many of the project documents / templates I use day-to-day as a Technologist, Tinypreneur, and professional software engineer.