Why Should We Build It? Validate ROI with Continuous Inquiry

Have you found yourself leading a hopeful software team through phases of frantic development, only to see the final product fail to gain traction? How could months of hard work, engineering prowess, and dedicated resources end in failure?

In a well-known study by CB Insights, 42% of failed startups built something that simply didn't solve a problem customers cared about or were willing to pay for.

At TSG, Continuous Inquiry is our commitment to building the right thing, the right way. It's a relentless, organization-wide process of questioning and adaptation. Often, we start with the question, "Why should we build it?" Asking this continuously—not just at kickoff—is the foundation of every valuable product we create.

Real-World Scenario: A Story of Ignored Effort

A growing SaaS company decided to invest heavily in a new internal reporting tool. Management assumed their account managers, who frequently struggled to get crucial data for client renewals, desperately needed a real-time, customizable dashboard displaying every metric they could possibly imagine. They envisioned an enterprise-grade "Account Health Command Center."

The software team proceeded without formally validating the core assumption. Had their product designers engaged the account managers, they would have quickly uncovered that all the managers needed were two specific data points (total active users and their role breakdown) delivered simply and quickly. Stakeholders asked if the dashboard was technically possible, but not if it was strategically necessary.

Six months of dedicated development and a significant budget were poured into the complex infrastructure. When the beautiful, real-time dashboard launched internally, the result was immediate and brutal: Adoption among account managers flatlined below 10%. The entire project was a resounding, high-cost failure. Feedback revealed that all they needed was a simple, automated monthly email summary containing those two key numbers. The complex real-time charting and filtering were too overwhelming for account managers to parse through right before a renewal call. The initial idea was based on a symptom (account managers struggling), but it was not the core job to be done.

Ignoring the question "Why should we build it?" resulted in a spectacular waste of resources on a high-cost solution for a low-cost, misunderstood internal reporting need.

What This Question Uncovers (and Why It Matters)

Asking "Why should we build it?" forces a critical pause to establish true project value before committing resources. It serves as an active inquiry into the opportunity cost of every hour spent.

By challenging the core assumptions, product and strategic teams clearly define the business value (expected return, revenue impact, or cost savings) and the associated risk profile (technical difficulty, market competition, compliance issues). This shift moves the discussion from "can we build it?" to the essential strategic question: "Is this the highest-value thing we can do right now, and will it solve the right problem for the right people?"

Tool Spotlight: The Impact Effort Map

At TSG, we answer this question through strategic analysis, not a single decision point. To focus and prioritize your team's energy, here is one key tool we often use: the Impact Effort Map

The Impact Effort Map helps you prioritize features or projects by balancing the potential impact (value to the client, revenue, or cost savings) against the necessary effort (cost, time, and technical difficulty).

This map guides teams to plot ideas across four quadrants, offering clear strategic directives:

• Quick Wins (High Impact / Low Effort): These are your immediate priorities. They deliver maximum value with minimal resource commitment. This is the goal of Continuous Inquiry.
• Big Bets (High Impact / High Effort): These are strategic initiatives requiring significant investment. They are valuable, but the commitment demands rigorous analysis and a phased delivery to manage risk.
• Fill-Ins (Low Impact / Low Effort): These are small, non-urgent tasks. They should be addressed only when bandwidth allows, as they offer little competitive advantage.
• The Kill Zone (Low Impact / High Effort): This quadrant identifies projects that should be rigorously scrutinized and often abandoned. These items require significant time and resources but deliver minimal value—they are the prime candidates for not building.

Why is a simple tool like this necessary? Teams are frequently biased towards action; they fall in love with their own technical feasibility or the symptom of a problem rather than the core job.

When a team immediately asks, "can we build it?" (an engineering question), instead of "why should we build it?" (a strategy question), it's often because:

• Idea Attachment: The team is too invested in the technical complexity or coolness of the solution, believing their invention must be needed.
• Sunk Cost Fallacy: They mistakenly believe that starting the work (or spending time thinking about the technical solution) justifies continuing the work, even if the value is low.
• Aversion to Conflict: Challenging a mandate or an idea from a senior leader requires political courage, making it easier to simply proceed with the technical build.

By forcing a project onto the Impact Effort Map, you create a shared, objective space that defends against these cognitive biases, ensuring the team's energy is always focused on the highest-value opportunities.

Client Value & ROI

By embedding the continuous question "why should we build it?" into our process, the client receives a measurable return on their investment that goes far beyond simply delivering code. This question directly benefits the business bottom line:

Maximizing Budget: This process, executed in close collaboration with business leadership, ensures spending is focused exclusively on high-impact work. By involving founders and executive stakeholders in the priority mapping (like the Impact Effort Map), we proactively eliminate the risk of funding "pet projects" or unnecessary overprocessing that drains capital without delivering value.

Mitigating Risk: The use of strategic tools and challenge sessions actively prevents costly pivots or complete project failure. This involves a joint strategic and product analysis to challenge core assumptions before development begins, protecting the organization from investing in the "Kill Zone."

Accelerating Time-to-Value: By strictly prioritizing Quick Wins and removing features that offer little value, the software team gets a high-value Minimum Viable Product (MVP) to market faster. This close alignment with sales and marketing goals ensures the delivered product achieves a positive Return on Investment (ROI) sooner, driving earlier revenue generation.

Conclusion

"Why should we build it?" goes beyond an initial check. This question should prevent operational waste. It gives your team permission to pause frantic development. Ask this question every time a new feature is proposed, at the start of every sprint, and whenever the market shifts. Stop building "just in case" and start building just in time.

Next in the series, we'll explore "What does it do?" which addresses the common problem of misalignment between design, engineering, and the end-user's actual needs.