A Solution is Not a Product

Solution, Deliverable, Product, Work Product and other terms are often used interchangeably to describe output from development initiatives.  However, there are some extremely important conceptual differences between the terms Solution and Product and understanding them should inform and guide your thinking about what you are doing as you go about developing and evolving your company’s products and services.

It is viewed as axiomatic that a successful product provides a solution to a real problem for which customers are willing to pay.  If the problem the solution addresses is not of great concern or the features, functions or capabilities that the product provides do not adequately address the problem, then it will not be viable and will not sell. 

Fashion, lifestyle and luxury goods may seem to be exceptions but when viewed through the lens of certain customer needs, they are not.  No one needs a $250,000+ sports car just for transportation; however, if you consider the psychic needs they might address, their positioning as solutions to customer problems makes some sense.  I refer to them as midlife-crisis-mobiles for this very reason.  $500 pre-ripped jeans serve to quell the status anxiety of fashion victims who can afford them.  While they don’t entirely fulfill the base purpose of most clothing—covering the body and protecting one from the elements—they seem to fill a psychic need.

A Product Delivers a Solution

Product Discovery is a process by which product management and development teams focus their ideas about the work they are doing to define and evolve a product both before and after it is released into the market.  Every team may do it differently, but there is a common pattern underlying how most of them who do it well do it.  It involves actively experimenting to acquire information that will guide the process, information that applies to both Commercial Viability and Technical Feasibility.  The goal of any development initiative is a product that is functional, supportable and salable.  If any of these conditions are not met, the product will fail.

The development lifecycle described by any of a number of product strategy consultants includes Problem-Solution Fit and Product-Market Fit.  These speak to the issue of Commercial Viability.  The issue of Technical Feasibility is something for which your development processes will also have to account.

This should inform how you approach defining, implementing and evolving your products.  You must resolve questions and confirm your assumptions and hypotheses relating to problem-solution fit, product-market fit and technical feasibility in order to have something viable to bring to market.  Since there is an and relationship among these three attributes, you will have to solve for all of them.  The order in which you do that will have an impact on the efficiency and velocity of your efforts.

You must define your solution in terms of customer needs, wants and preferences as you understand them.  You shouldn’t assume, ex ante, that you understand them fully and you should design your implementation initiative around the idea that you will acquire answers to questions you started with and confirmation of your assumptions and hypotheses along the way.  Keep in mind that a solution is not a product; it is a description of capabilities customers will require to solve the problem you have targeted.  It is also critical that you confirm that customers perceive a problem in the same way that you have.  If they don’t believe they have a problem, they will not be receptive to any solution that you might offer.

After you have qualified and understood the problem and determined that customers will want and be willing to pay for a solution, you can begin to design the product that will deliver the solution to them.  It is critical that you arrive at a target product in this order, otherwise you may be providing the proverbial hammer in search of a nail, and any success you may achieve will be the result of random luck, nothing more. 

This article in Investopedia contains a quote that describes one of the most famous product failures of all time:

New Coke is often cited as the ultimate example of one of the most notorious product flops and brand missteps of all time. New Coke was launched in the mid-1980s by Coca Cola in an attempt to help the soda company stay ahead of competitors during the so-called “cola wars.” Instead, it just annoyed consumers.

It tried to solve a problem that consumers didn’t have—thirst for a replacement for an iconic product—and it failed miserably and was withdrawn from the market in a remarkably short time, literally only weeks.  Coca-Cola had done a great deal of taste testing that showed that consumers liked it, or they would not have undertaken to release a new version of their anchor product.  Unfortunately, the problem-solution fit didn’t exist.  While the product (at least without the context of it replacing an existing historic brand) was well-received, the lack of problem-solution fit doomed it to fail to achieve product-market fit. 

On the other hand, the Sony Walkman was a product embodying a solution to a problem that consumers didn’t really know they had, a product which they found enormously attractive when they were exposed to it.  Many iterations of the Walkman were released over more than twenty years and hundreds of millions of them were sold.  Clearly the Walkman met all three criteria, which was intrinsic to its success. 

Product Discovery on the Path to Implementation

Given the importance of defining and qualifying the problem, solution and product, in that order, how should you conduct your development initiatives?

• Articulate your understanding of the problem you believe you’re solving, for whom you’re solving it, the critical capabilities you believe the solution must provide and characteristics, functions and features you believe a product requires to be attractive.  This will, of necessity, be preliminary and incomplete, but you will expand your understanding as you progress.  You should plan and account for this.
• Identify and articulate knowledge gaps, assumptions and hypotheses—these should include questions relating to problem-solution and product-market fits.
• Specify how you will obtain the understanding and confirmation that you will need to validate a continuing investment of time, effort and money into the development of the product. 
• Design an initiative plan to address these things as rapidly as possible. Prioritize your ability to identify and resolve ‘deal killers’ at the earliest opportunity.  If you cannot resolve an intractable issue, then you should consider shelving or pulling the plug on the initiative before throwing good money after bad.

Political Realities

Some companies would find this approach in conflict with the way they have always done things, and this is something that should engender introspection.  Such companies are likely to employ traditional project funding and project management techniques, such as those espoused by the PMI.  These practices are anti-agile and antithetical to the performing product discovery.  They require a detailed definition of product (the scope) at the outset of an initiative, which is used to drive a budget and delivery schedule based on it. 

Once accepted and set in motion, initiatives chartered this way take on a life of their own, complete with inertia and resistance to change, no matter how appropriate and justified.  No one wants to admit to having erred in modeling the business justification for the initiative and no one is willing to terminate it, even though it may not ultimately provide any real value.  Making funding such a high-stakes game sets the table for all sorts of pathological behavior and management malpractice.  It is exactly how so many development initiatives proceed on auto-pilot until they are completed and then found to be valueless.

If this sounds like your company, you need to do something about it.  You need to develop Full Enterprise Agility that flows from your strategic planning to product discovery and development to your technical implementation processes.  Merely adopting a commercial Agile development framework, such as Scrum or SAFe, will not provide this for you.  You will need to achieve constructive collaboration among your senior executives, product owners and managers and digital development teams and you need to revise your investment approach to one consistent with iterative experimentation and problem solving.

If this seems daunting, well, it is!  You need to rethink your culture, leadership models and collaborative practices at all levels.  These are a lot harder than just putting your digital development team through an Agile adoption. 

To be successful in this, you must get the help you need to transform now and prepare to transform again and again going forward.  It’s a VUCA world and you will only survive if you consciously prepare yourself to ramp up your ability to respond to change.