Technical Feasibility is NEVER the Biggest Risk

A team has been working on a new idea. A product or service that will no doubt be of great value to customers and will shift the revenue trajectory of the business! They’ve developed some customer personas, mapped out the value propositions that might exist, maybe even worked out a complete business model canvas. The idea has matured into a collection of theories about getting customers to see so much value, they are willing to part with hard-earned dollars for the product. Which theory to test first? The team says technology is the riskiest assumption and wants to prototype right away. This should raise a red flag:

Technical feasibility is NEVER the biggest risk

I repeatedly see product teams gravitate to testing the technology first. It is a red-flag, an anti-pattern in good product development practice, and you should set is as a trigger in your mind: when technical feasibility is proposed as the biggest risk to test in early stages, pause and step-back. Technical feasibility-first is essentially saying ‘we don’t know what the market wants but we’re going to start building right away.’ I’ll clarify why this is bad, explore why teams still propose it, then offer a mantra you can use to redirect efforts towards the true riskiest assumptions about your new product.

There are three reasons why you shouldn’t start with technical feasibility.

One: technology is not the most risky assumption

Walk back through all the theories about this product and its business model and review your assumptions. In my experience — the team typicaly acknowledges other assumptions outside of technology, but either holds them as equivalent to the tech working, or they have failed to elaborate on a dynamic that is far more catastrophic to the product’s chances of success.

Two: technical feasibility is not the cheapest thing to test

Developers are some of the most expensive resources applied to product creation and they are often booked on important projects and enhancements for existing product. Why start with the step that has a high labor and opportunity cost? “But it’s just a two-day architecture spike for a few developers”. It’s never two days, but that’s besides the point. Especially early in product development, there are market tests that require less time than prototyping.

Three: technology is in the solution space, and at early stages you are trying to refine your understanding of the problem space.

Why solve a problem that you haven’t confirmed is a problem customers will pay for? In the early stages of product development, efforts should be focused on exercises that build an understanding of the problem. Otherwise, you are building on shifting sand. “But what if it doesn’t work?” is just a chance to re-direct the team: “Yes, what if the market doesn’t work the way you think?” Finally — let us not forget that good developers are some of the smartest and most industrious people on the team — they thrive on hard problems and excel at finding ways to make things work, or reporting on the technical trade-offs for doing so. Leverage that competency when you know more about what is needed by your customers.

So why do teams do this?

One: they don’t have a pathway ‘out of the building’

Work on product-market fit happens ‘outside of the building’. It is not developed on a whiteboard in some glass tower. But sometimes teams don’t have a pathway out. This is most often about the experience of the team. Perhaps they are limited in their industry or customer contacts. Maybe they don’t have experience with tools like interviews, surveys, lead-generation and marketing tests. Diagnosing the capacity of the team will identify solutions. Introduce them to current customers, get them to industry events, integrate them in business development activities… throw them in the deep end.

Sometimes the pathway is blocked — another group or function owns the market interaction. Perhaps marketing thinks of this as market research, or business development insists on all customer and market contact. Incorporate this group in your efforts. While you may be surprised how far a little collaboration can get you, that collaboration also lets you build the ‘plausible deniability’ you are going to need if the strategy becomes one of ‘forgiveness, not permission’. Above all, do whatever it takes to get real market interaction.

Two: musing on the solution is more fun

The solution-side of the problem is typically a very creative activity. Especially if the prototyping involves wire-framing and user experience. It’s also easier for the team, because it can be done in a vacuum. Before you know it, they are daydreaming about “what would land us on the cover of Fast Company? and what would our cover story tagline be?” Begin at the end right? Wrong. You don’t know enough about the problem at this stage to waste any time thinking about the end.

This can be a symptom that the product development team is tilted towards build staff, and they are just going to what they know and excel at. You can adjust the team composition, or you can train that build staff in product development methods.

Three: their financial backers value feasibility

While less common as a reason for technology-first, it can be the case that the financial backers of the product value a prototype in the early stages as a precondition for further funding. This is suggestive of the same types of issues and misunderstandings, just at a different level. Resolution is a longer game of training those backers on what to value — real market validation and feedback.

My grandfather was fond of saying “The only absolute in life is there are no absolutes!” Despite that sage advice — I encourage teams to ALWAYS reject technical feasibility as the biggest risk to test at early stages. This makes decisions clear and avoids the impression that their project is the one exception. Ultimately this is not about whether an exception exists, it is about which muscle you must develop in product development — the market validation muscle. Do you need better build and prototyping skills? No, you need better market validation skills. That is the muscle you are developing when you turn down technical feasibility early. Fitness there pays long-term dividends.