New Product Development in a Startup

Startup = Product; Product = Startup

I have not written a Product Opportunity Mapping post for a few months as I’m heavily involved in a startup that is at the intersection of robotics and construction (RoBIM Technologies Inc.).  I’m working with several talented co-founders who have collectively been working on the research side of this field for decades.  Now, we are at the point of translating their technologies into a commercial offering.

In other words, we’re developing new products. 

I have advised companies for several years on how to identify, evaluate and select new products to pursue and I’m using the same Product Opportunity Mapping frameworks at RoBIM.

As most of my advisory clients are well established companies looking to grow and diversify their revenue through new products, they seem to have infinitely more resources than a typical startup but facing many of same challenges.

For a startup, without a product they won’t exist.  This is what they are all about and a central focus for everything they do.  However, the probability of success (at least statistically) are very low.  The same goes for an established company: it’s a high risk and high reward endeavour.

Both in startups and established businesses, my experience has shown that new product development teams know directionally where they need to go but are inundated with too much data, receive conflicting advice and forced to make too many decisions with imperfect information.  Everyone wants certainty and specificity but there are too many unknowns.

Making Decisions with Imperfect Information

For startups, it’s often investors who want these specifics and for an established company, it’s the c-suite.  It seems like a reasonable ask to understand how a new product will enter the market, make money and grow but most predictions at this stage are going to be wrong. 

This is particularly acute in the startup world as investors want prediction of revenue, margin and earnings forecasts and then will use that to calculate some sort of company valuation – and then make an investment decision based on this.

In my mind, these are “cash flow” investors and this approach is likely how they made money in more traditional investments in the past (and perhaps the reason why they have enough money to consider investing in a startup).

However, this forces a startup team to make forecasts when it is too early to do so and those predictions will very likely be wrong (as an angel investor, I have never seen a business plan prediction come true).

In contrast, investors who have a track record of successfully investing in early-stage technology companies typically take a different approach.  They realize new product development is a series of pivots and their investment decisions are primarily based on a judgement of the team involved and the markets they are targeting. 

The market has to be big enough and the team strong enough but essentially, these types of investors are betting on management’s ability to develop, test and learn from a series of hypotheses which represent pivots towards a successful market launch.

Using a Product Opportunity Summary Framework

This is in fact the reasoning behind the Product Opportunity Summary (POS) framework that I use with my advisory clients.  It is based on four questions that are at the heart of every product opportunity:

1.        What problem are you trying to solve?

2.        Who are your customers and where do they exist?

3.        Who and what is your direct and indirect competition?

4.        Why you and why now?  What is your “secret sauce”?

Answering these questions does not guarantee success but will greatly minimize the chances of failure. 

As well, as a new product is being developed, market intelligence data (customer, market and competitor information) is gathered along the way and this framework can be used as a depository and to evaluate new information in an organized fashion.

It also serves as a filter for the noise, identifies holes in your research from which you can develop product-specific hypotheses that can be tested.

This is where we are at today with RoBIM.  We have adapted the POS to reflect our situation and using it as a filter for the 30+ use cases (problems to solve) we have identified to date.

Our version of the POS helps us sort through the uses cases, identify areas where we are missing information (what we don’t know) and what we need to validate (what assumptions we need to confirm).

After this first pass, we expand what we know into a more traditional business plan which will be used to justify an increasing amount of investment.

It’s a slow process but way better than the random walk I see many startups and well-established companies pursuing.