Feasibility Testing Can We Actually Build This?

Can your engineering team actually build the vision you've pitched to the board? Feasibility testing is the process of involving engineers early in the discovery phase to determine if a product is technically buildable within the required time and budget. This step prevents teams from wasting months on a solution that collapses the moment it hits real-world scale.

Most product failures aren't caused by bad marketing or poor sales tactics. They happen because the team builds something that isn't technically viable or valuable to the user. Identifying these technical risks early is the difference between a successful launch and a "near-death" experience for the company.

Why Feasibility Testing Matters

In the book Inspired, Marty Cagan argues that the job of a product manager is to discover a product that is valuable, usable, and feasible. Feasibility testing is the specific verification that a product can be built with the technology, time, and funds currently available. It’s not a final check before launch; it's a constant investigation during the discovery phase.

Cagan points out that nine out of ten product releases are failures because they fail to meet their objectives. This often happens because teams treat engineering as an implementation service rather than a discovery partner. When you wait until the end of the process to check feasibility, the cost of a "no" becomes devastatingly high.

Real feasibility means more than just "is this possible?" It means asking if it's possible for your specific team, with your specific stack, in the time you have before the market window closes. This prevents the "house of cards" scenario where a product works in a demo but fails under the weight of real transactions.

Critical Elements of Technical Investigation

Engineering discovery as a creative partner

Engineers are often the best source of innovation because they know what is just now becoming possible with new technology. During engineering discovery, lead developers should attend prototype testing and participate in early brainstorming. Their presence ensures that the team doesn't pursue a design that is fundamentally incompatible with the existing architecture.

When engineers are part of the discovery team, they help the product manager understand the relative costs of different features. A simple change in how data is stored or retrieved can save months of development time. This collaboration allows for the informed negotiation between what's desired and what's possible.

Feasibility testing for insurmountable obstacles

The main goal of feasibility testing is to identify technical roadblocks before the full engineering team is committed to the project. This involves investigating new technologies, exploring potential architectures, and running small experiments. If an obstacle is insurmountable, the team needs to know this while they are still in the prototype phase.

According to Cagan, teams should dedicate 20% of their engineering capacity to "headroom"—infrastructure work that prevents technical ceilings from being hit. Feasibility testing helps identify where that headroom is most needed for upcoming features. It's the process of looking for the "no" early so you have time to find a better "yes."

Product risk assessment in early design

A product risk assessment focused on technology ensures that the solution isn't just a fantasy. High-tech products are defined by what is becoming possible, which means you're often working on the edge of your team's capabilities. Prototyping allows engineers to evaluate these risks without writing production-level code.

The cost of making a change rises dramatically once implementation begins. By conducting technical assessments during the design stage, you minimize churn and keep the team focused on building the product right the first time. This moves the technical negotiation to the beginning of the cycle where it is most productive.

When Scale Collapses the Business

In 1999, eBay faced a near-death experience because their technical infrastructure couldn't keep up with their massive growth. The "house of cards" was collapsing, and they had to rewrite the entire engine mid-flight. This required a massive, multi-million-line rewrite while still delivering new functionality to keep users from leaving.

Netscape faced a similar challenge during the browser wars. They decided to stop all new feature development for a full rewrite, which allowed Microsoft to take over the market. They lost the "war" because they didn't manage their technical feasibility and incremental improvements effectively.

Both examples show that technical debt and feasibility aren't just engineering problems. They are strategic business risks that can sink even the most successful companies. Ignoring these risks leads to a state where you can no longer maintain or grow the product.

Three Ways to Verify Your Technical Path

1. Get your lead engineer in front of target users early. Invite an architect or senior developer to attend your initial prototype testing sessions. They will see first-hand where the current technology struggles and often invent better solutions on the spot.

2. Use high-fidelity prototypes as your living spec. Instead of a 50-page document, use a clickable prototype to communicate the product's behavior to the developers. This allows engineers to give high-confidence estimates because they can actually see and interact with the intended functionality.

3. Allocate 20% for infrastructure taxes. Tell your engineering team they have 20% of their capacity to spend however they see fit on re-architecting or fixing the code base. This "headroom" ensures you never reach the point where you have to stop all forward progress for a complete rewrite.

Why Pure Technical Analysis Hits a Wall

Technical feasibility is a binary check—can we build it or not?—but it doesn't account for whether anyone wants it. Critics of heavy feasibility phases argue that they can make a team too conservative. If engineers are only asked "can we build this?", they might say no to difficult but necessary innovations to avoid risk.

Some Agile practitioners believe that "sprint zeros" replace the need for deep feasibility testing. However, Cagan argues that waiting for a two-week sprint to test a technical idea is an order of magnitude too slow. Prototyping should happen daily, allowing for dozens of iterations before a single line of production code is scheduled.

Feasibility testing focuses on the technical reality of the build. Three takeaways include treating engineers as discovery partners, identifying obstacles via prototypes, and maintaining 20% headroom for scale. Ask your lead engineer for a 'Small, Medium, or Large' estimate on your next three ideas before you finalize any roadmap.