Thursday 22 November 2012

Product/Market Fit and Qualitative Value Assessment in Enterprise Software


I'm getting obsessive about product/market fit. That's probably a good thing and there are some great posts out there that help you get started with the concept.

Andreessen famously made the point that when a start-up has a good product/market fit, the product is virtually 'pulled' out of the start-up by the market. Oh yes, that sounds great doesn't it? Struggling to meet demand is every start-up's dream.

I think that works really well in the B2C sector but not so well in the B2B sector, where a new software product needs to get through numerous layers of shitty bureaucracy at all stages; it's hard to generate awareness in a market cluttered by also rans with big PR budgets; IT people are sometimes not the most accommodating of new ideas; procurement departments enjoy playing with deals; big enterprises enjoy playing with little ones (in every sense).

What trumps all these issues is Value - hence, the often meaningless phrase, 'Value Proposition'. If you can point to a reliable, business (not IT) driven, hard ROI expressed in £/$, then you can jump the hurdles. Hence, I'm interested in the link between Product/Market Fit and Value.

Here's my theory. Let's start by saying that...

Customer Value is proportionate to Usable Product Functionality

Ok, so the more your product can do, the more value a customer can get out of it, with the proviso that it has to be useful to be valuable.

But Usable Product Functionality is basically describing a Product that's a good fit for a particular set of requirements, i.e., a good fit for a particular Market. Andreessen doesn't really talk about the problem that drives the Product in his seminal blog-post, but to me the problem is the key component of the Market. After all, you build a Product in response to a Market need. 

In terms of an individual Customer Value proposition the Market is limited by the size of the enterprise network. It might be equal to the number of users within an enterprise - or, as with Sabisu, it could include users outside the enterprise. The Customer Value is dictated by the Value Potential of the problem the product solves; having a genuine high value problem to solve is the key. It might be a high value problem for a few users, or a low value problem for many users. This 'genuine high value problem' is analogous to the 'must have signal'.

So within a single Customer, Value Potential is simply:

Value Potential = Value of Problem * Number of users 

This means that all the other B2C Product/Market fit characteristics that you'd like to see apply to B2B software; virality drives the 'Number of users', new products can still create new Markets or define problems that have not previously been addressed.   

Let's make this pretty obvious statement:

Customer Value is proportionate to Value Potential

But it isn't just that. That 'good fit for a problem', or 'value potential' needs to be accessible. Every proportional equation needs a constant (remember kids that y=kx) so how about:

Customer Value = Efficiency * Value Potential

Where Efficiency is the ease of extracting value from the solution. You could see it as related to effort required to realise value (so, k=1/effort required) which in enterprise-software-world usually means technical services. Or you could say a solution that's easy to use is easier to extract value from (k=ease of use).

Customer Value = Ease of Use * (1/Services Required) * (Value of Problem * Number of users)

[Here's an interesting game; pick an ERP software implementation of your choice and run it through the above. Qualitatively it's not great, eh?]

Customer Value and Vendor Value really align here. Efficiency is very important to both parties as it limits the Vendor's ability to meet customer needs when the right problem has been identified, e.g., an inefficient platform drives lots of efficiency limiting behaviour such as support calls. 

Note that the contribution of the product itself to the analysis is limited to 'Ease of use'. Everything else is irrelevant so long as it's solving a valuable problem. Just as with the Product/Market Fit concept, the product just has to basically work. It has to be viable - a minimum viable product.

Product/Market Fit is traditionally focused on Vendor Value, i.e., do I pivot because the product/market fit isn't right, or persevere because I believe it is? (cf. Lean Startup). 

The Product/Market Fit calculation still works because Market Value is related to the aggregate of all those individual enterprise problems - that aggregate effectively drives the what the vendor can extract from the current market. If the Value Potential isn't there then a pivot is needed.

So, Vendor Value Potential is proportionate to Sum for customers(Value of Problem * Number of users)

Of course, there's no problem having stacks of Vendor Value Potential if you can't exploit it. If it's easy to exploit, it's efficient, so let's bring that back in again to complete our qualitative equation. 

As a Vendor, Services aren't necessarily negative - in fact they're irrelevant so long as they don't affect your likelihood of a sale. Ease of Use is still relevant as it drives down the cost of maintaining a customer.

What is negative is a high cost of customer acquisition, perhaps because the Market is hard to reach, or it's a new class of product with limited awareness that therefore requires lots of education before the tills can ring. 

Also as we're looking at the Market as a group of Customers, we need to account for the 'Probability of Sale'. Now, I'd be the first to admit that this is hard to determine - there are so many factors that affect whether a sale occurs; 
  • Lower price than competitors
  • Better marketing/sales collateral
  • Better case histories/company history
  • Better knowledge of the market

For me the Probability of Sale is just that; a value between 0% and 100% which indicates whether, all other things being equal, your solution would be the one chosen. One thing is for certain; the Product isn't going to affect this - your communications are. :

Vendor Value = Ease of Use * (Probability of Sale/Customer Acquisition Cost) * Sum for all customers(Value of Problem*Number of users)

Of course, the quantitive Vendor Value is impossible to ascertain; you'd need licensing, services and reliable 'Value of Problem' and 'Number of users' terms. However as a qualitative guide...it might have some use.

Questions:
  • What other negative/positive factors need to be taken into consideration, particularly around the product?
  • What else might inflate Customer Acquisition cost?
  • Could the Vendor Value calculation be applied quantitatively to a particular prospect, defining whether it was worth pursuing?