Why developing a technical proof of concept is not the best thing to validate an idea?

Very often companies giving a first pass approval for a new product idea decide to invest time and resources in a technical Proof of Concept.
From a certain point of view it makes perfect sense, as it’s a way to test internal capabilities before deciding to go ahead or not.
A Proof of Concept (POC) will answer two main questions:

• are we able to deliver the idea?
• how much is it going to cost to deliver?

A POC is a helpful assessment of the feasibility and cost structure of a new product idea.

However, the first thing we should ask ourselves when starting a new product journey is “is there a market need for it?”, and not not “can we do it?”
Most of the insights that a POC will deliver are related to the internal organisation, its capabilities, its skills and cost structure. But how about the customers? They are the ones that are going to buy — or not — whatever you are able to build!

Moreover, it’s not even free to do. By delivering a POC, companies invest time and money.

• engineers and materials involved have an actual cost
• opportunity cost: engineers’ time and skills could work on something else, a new feature for an existing product that is already positively contributing to company’s bottom line, for example
• Finally, credibility and team morale should be considered. No one wants to work on pointless stuff.

How to prevent this from happening?
A customer discovery exercise is the first thing to do in order to assess how good a new business or new product idea is.

A business or a new product idea always start from an assumption of a problem affecting users.
Something ideators might have witnessed or experienced themselves.
But what if those assumptions are not valid? What if that problem is something that ideators and their friends only experience, and that’s limited to a very restricted user base?

When working on new product, the best thing to do is to adopt a lean approach: to invest the lowest amount of money and time at the beginning, gather insights from customers making experiments, and then to gradually increase the commitment as much as we receive positive feedback from the market.
At a certain point of this process, engineers will jump in, and possibly help developing a POC, to see how much of the proposition tested and validated with customers we can internally deliver, how much will have to be outsourced, and how much it will cost overall.
But that will be only after we have

• clarified the assumptions about the problems the new product idea is willing to solve
• made an assumption about which customer segments might be affected the most by those problems
• validated those assumptions through qualitative interviews with customers
• defined a value proposition grounded on customer insights and leverages company’s key strengths to achieve a competitive advantage customers care about
• refined the initial proposition taking into account customers’ insights and behaviours
• defined the minimum set of features required for launch

Thanks to this approach, the actual practical involvement of the engineering team will only come at the end, after the underlying problems have been validated and the proposition has been tested, iterated and validated by customer commitment.
This doesn’t mean that they don’t have to be involved during the discovery phase. On the contrary: a tech point of view always brings fresh ideas on the ideation table. Moreover customer closeness is good for everyone, tech team included!
What we really want to achieve with this approach is to reduce unnecessary time and money investment, and keep off the engineers tables any bad idea so that they can spend their precious time and skills on something beneficial for the company.

This article was originally published on studioZao.com.