Concepts

Product vs. Solution – Results from a Microsoft Teams Chat

That’s why it is fun to work in a startup. Sometimes the simplest conversations on the company instant messanger derail into weird but ephinany-inducing conversations. This is a tribute of one of those situations I ran into recently. But before we dive in, let’s look at the problem.

What is a product sale and what is a solution sale?

And when are you selling a product? And when are you selling a solution?

There are sure millions of people that have an opinion. Maybe there even is a book with a definite answer. But in the end, it is all relative and what we make of it.

Some deep drive background into thinking about complexity of product

Before this conversation, I think, we used both terms loosely. I mean, we had one draft document that was a bit overenginered and looked like this:

Product Deep.JPG

I admit this isn’t complete. But I think it’s viable. But it was also considered too complex. It talks about simple and extensible products that switch to customizable products that are customized to use cases and become solutions. Then ranging from simple turnkey solutions to heavy process-affecting fat solutions and solutions that span multiple departments and hierarchy levels as below:

Deep Prod 2.JPG

But then, this all can sound “frightening” too people and hence the reaction was this is a bit academic.

So the discussion today was easier.

A simple framework from a chat

If you are selling without a use case in mind and without a specific value promise that needs a proof of concept, you are selling a product. Otherwise you are selling a solution.

Chat Solutions

As outlined in this chat, we simply defined a product as something that speaks for itself when being sold. THe buyer knows what he wants to use it for. And that is enough for him to buy it. The seller doesn’t care and does not need to know. The seller of butter is not in need to know why the buyer of the butter is buying. He just needs to know the buyer is buying.

The chat itself was a bit longer. One person was in a long boring meeting, another one trying to solve a peripharal problem. So the chat just happened. The key principle the entire talk was based on was clarity of words. If there are two words : product and solution, they must have different meanings.

To sell a bike, you certainly have to have the features of a bike. Pedals, wheels, chain, break, seat, steering wheel. Etc. But you don’t know what the buyer is doing it. Maybe he does triathlons. Maybe he speeds up his time to work. Maybe he savesteh environment. Maybe he tries to stay healthy. In any case, the buyer knows the concept of a bike and recognized when a bike is a bike.

But more important to the definition in the context of the company was actually why the definition matters for the company. And the discussion is about what the other graphics talk about. How much hand holding in the sale, the delivery, the adoption is required. How much customer success for how long is needed, how many processes, people and hierarchy levels are attached to the system. How much proof of concept for everyone involved needs to be done? We are talking solution sales. Customer acquisition cost, retention cost, maintenance cost, pricing of complex enterprise “product” sales that cost a lot of money and that require the buyer ot have a clear benefit, which needs to be provided by conceptually sound model they can buy into. And that conceptual model which is a concept needs to be proven.

This is customer acquisition cost in your face. Handholding costs resources and if you scale costs admin for utilization if you want to have market rates and market margin. It means use cases have to be understood, concepts created and proven, etc.

If we are selling a product. We don’t care about the solution. The customers buy the product because it is easy and obvious and powerful. This is a UX challenge to put the value of the product clearly out there. And because they believe they are able to activate this value without complex concepts and without the need of external help of a solutions provider. Again a UX challenge or a product managemnet challenge. to keep the product simple enough to not require a solution.

The deeper we go into solutions, the bigger the tickets, the harder the sale, the more human capital intense the approach, the higher the lock-in risk for the buyer.

Solutions SaaS sucks. Consumerized buyers and hyper growth SaaS product companies want to sell SaaS products. Turnkey solutions. And that requires focus, superior product management, very talented AI and a strong customer discrovery process from sales down to product design and enginerring.

With our new definition of Solutions and Products, we not only can discuss the topic again on a different playfield, but we can clearly model scenarios and talk strategy when looking at steering CAC and focusing on optimizing churn and use activation/MAU statistics when selling a product vs keeping busy with managing complex sales from a marketing, pre-sales, sales and delivery perpsective running a solutions success factory.

And all those things just came out of a 30 minute chat. Good stuff ! Only in startups. Maybe it isn’t a simple framework when looking at the entirety of the problem. But again. Products sell without use cases. Solutions need proof of concepts.

Leave a Reply