Great technology leaders don’t just build software—they build businesses. But how do we know if we’re creating a product that truly delivers value? Deciding whether a feature or product is valuable is difficult. We’ve all heard the saying that ideas are a dime a dozen, and unfortunately, we often become married to our first ideas. Most people don’t get married to their high school sweetheart, and we probably shouldn’t build the first version of our ideas either.

A Simple Process to Decide Whether to Build Something

1. Define the Business Impact: Do we have a theory as to how this will improve the business? Will it drive revenue? Reduce costs? Any assumptions here should be made explicit so that we can test them later.

2. Test the Theory: How can we validate whether our hypothesis is true? Often, this will NOT require writing code:

   • Talk to existing or prospective customers to see if they would pay for it.
   • Write blog posts or other content to gauge interest.
   • Build a mock-up version cheaply that people can use.
   • Run a process manually before automating it.
   • Many other ideas are available in the book Testing Business Ideas by David Bland and Alex Osterwalder.

3. Review the Experiment Results: If the theory holds, we have more support to invest further. We may discover that the feature as originally described is perfect and will bring all the value we hoped for. More likely, we’ll discover that we need to change something or not build it at all. This isn’t failure—it’s a part of the discovery process.

Following this process ensures that we’re not just writing code but delivering meaningful outcomes. A real-world case study illustrates the power of this approach.

Case Study

How We Delivered $25M in Sales by Questioning the Initial Plan

In the months and years post-COVID, a U.S. auto manufacturer was struggling with supply chain issues, as many companies were. They had a theory that they could improve the alignment of supply and demand through a large, complex software solution. The estimated development time was one year, and they asked our group to build it.

Applying the Framework

Instead of jumping straight into development, we applied our decision-making process:

1. Assess Business Impact: The organization believed that by improving supply and demand alignment, they could reduce losses and increase efficiency.
2. Test the Theory: Rather than building the entire system, we determined how we could reduce scope and validate the core idea. We designed a minimal viable version of the solution that could be operational within three months.
3. Review and Iterate: Once deployed, we quickly learned two key things:
   • The idea did, in fact, improve alignment between supply and demand.
   • The originally envisioned full-scale system was unnecessary—only a fraction of the functionality was needed to achieve the desired outcome.

The Results

By simplifying the solution, we deployed an initial version four months earlier than expected and achieved $25 million in sales through that system in the month the original deployment was planned (with a ramp-up period leading to that milestone).

Key Takeaways

• Smaller, faster experiments reduce risk and accelerate value.
• Not all features are worth building; some can be simplified or eliminated.
• Organizations that test first can achieve business impact much sooner.

By questioning initial assumptions and focusing on learning first, we not only built a better solution but did so in a way that maximized business impact.

If you’re looking to improve your product strategy and delivery efficiency, let’s talk!