As a product manager, we read a lot about the need for a solution by the customer. So when we build a product, why does it not just work. The general reason that comes back is that the customer needs a solution. Wait, didn’t we just build that?
Not quite. There is a subtle difference between providing a product vs providing a solution. It’s almost there, but not quite there.
What’s the difference?
Let’s illustrate with an example.
Imagine you have this magic technology that reads people’s minds. The use case is to help sales people read their prospects’ minds and determine if they will buy. That way sales people only focus on prospect that are likely to buy. Lets call it MindPredict. Sounds like a great product. But in order to actually make it work and be effective, you will need to fit it into the workflow of the sales people.
During your discovery you will likely learn that sales people are extremely busy. They probably use some kind of CRM where they (hopefully) spend most of their time. Can MindPredict be integrated with their CRM ? or even better, with Outlook? Otherwise they will have to login to another application to get the prediction, and then figure out from the CRM where to focus. That’s a deterrent for adoption. It would be great if the CRM could just sort their opportunities and just tell who to call next. In fact, MindPredict is invisible to them. They just take action on the result of MindPredict. In this example, the product gives prediction, but the solution that is needed is who to focus on and what actions to take. A subtle difference.
Let’s use another real life example. Years ago I needed a solution to manage my personal finances. My existing solution was a diary where I would meticulously write down each expense and make sure I have enough at the end of the month. At that time two products came in the market – Quicken and MS Money. I chose MS Money only because I had access to a store discount in Seattle. Instead of a diary, I would note down the expenses in the application, which in turn would give me nice reports. The problem after a while was the time it took me to enter the data was just too much. I had to keep all the receipts and find time to enter them. Slowly I fell back and had a huge backlog. And then I just stopped. It started impacting how I managed my cash. I had no idea if I would have money left at the end of the month. The product worked great, but it was not a solution. It did not quite fit my workflow. It was too much work. It was easier to go back to the diary. At least it would fit into my pocket so I can record anytime.
(aah, now we know where Steve Jobs got his inspiration for a smartphone that would fit the pocket)
Then a new product came called Mint.com. It simply removed that burden of manual data entry. All I had to do was link my credit card and bank account. Voila!. All entries are automatically entered. Dashboards and reports are updated. In fact, I would get a weekly email report. I did not even have to log in to mint.com. Totally seamless. Worked within my workflow. That’s a great solution.
So you see a pattern here? A solution works when there is no additional burden or effort on the part of a user. How much of a burden is your product putting on the individual workflow? Just having a technology is not enough. For your product or technology to be adopted, it needs to be seamless to use. Almost invisible.
Here’s a tip. When you do your initial discovery and validation, think in terms of what will solve the customers problems rather than how will your product work. It’s a mindset shift of how you approach your product.
If you watch Shark Tank, notice the companies that don’t get funded. Of course there are numerous reasons for not being funded (not a big enough problem, not the right founder, too complex), but a primary reason is that it is not a good solution even if the idea is clever or the technology is great and they have the right patents. Watch a few episodes and you will get the gist of it.
(PS: Not getting funded on Shark Tank does not mean the company will not work out. Ring (the doorbell) was rejected by Shark Tank and later acquired by Amazon. Go figure)
The product is effective if it helps solve a problem effectively and efficiently. Although subtle, it makes a huge difference in how you position your product. Your product exists to solve a problem. Customers are more interested in the solution rather than your product. Even if you don’t have a product, but somehow you are able to solve the customer’s problem, that’s a solution too.
While mature companies may have this figured out (maybe not all), it’s important for startups to speak the language of the solution rather than the product.
Something like – You have a problem X, we have a solution Y that gives you the benefit of Z.
This is especially true for a complicated B2B product. For instance, let’s say you have a solution that does really solve a problem but it requires a lot of training and change management and possibly some business disruption. Enterprises will think twice before jumping in. Solution places a burden on them.
If you do your customer discovery and validation right, you will know what the solution needs to be. Build your product but sell the solution.
