Product is not the solution
Over the past decade, software providers have made significant strides in shifting from a "project" to a "product" operating model. This evolution has brought greater focus on product strategy and product discovery, ensuring that solutions are continuously refined based on user needs rather than being delivered as one-off implementations. However, despite these advancements, one fundamental misunderstanding persists: the product itself is not the solution.
A product is an essential part of the solution, but the actual value is only realized when it is properly configured, integrated, and adopted by the recipient. Just as a car manufacturer cannot control how a driver navigates the roads, a software provider cannot control how a customer implements and utilizes their product within their unique business context. This distinction highlights the difference between concern, influence, and control in product adoption.
Beyond control: the role of co-creation
Providers control product design, features, and documentation. They can influence adoption through onboarding, training, and best practices. But they do not control the recipient’s business processes, decision-making, or the actual outcomes achieved with the product. The gap between product and solution must be addressed through co-creation, where both providers and recipients actively work to ensure successful implementation and value realization. In some cases, there is direct collaboration during the design, development or delivery of the product or service. In other cases, such as with COTS and SaaS for the mass market, providers and recipients don't actually work together - nevertheless, value is co-created by their asychronous efforts.
The overlooked role of the product/service recipient
Too often, organizations focus solely on what the provider delivers, neglecting their own role in turning the product into a working solution. On the provider side, there are well-established disciplines: product strategy, product discovery, and product development. On the recipient side, there are complementary areas of focus: solution strategy, use case discovery, implementation management, and management of the product’s actual use. Without structured efforts on the recipient’s side, even the best-designed product may fail to deliver its intended value.
领英推荐
The role of business analysis on both sides
Business analysts (BAs) play a crucial role in bridging the gap between product and solution. On the provider side, BAs help define features that align with market needs, analyze industry trends, and translate customer challenges into product requirements. On the recipient side, BAs assess internal business challenges, define success criteria, and ensure that the product is effectively integrated into existing workflows. By acknowledging and strengthening these roles, organizations can increase the likelihood of product adoption and success.
A call to co-create
For software product providers: Recognize that your product’s success is dependent on how well it is adopted and used. Shift from merely delivering features to enabling customers to create real solutions.
For product/service recipients: Acknowledge your role in solution creation. Organize accordingly, ensuring that internal solution ownership, business analysis and other roles and are in place to maximize value.
A great product does not guarantee a great solution is. It takes co-creation to make that happen.
Enterprise architecture and design. Available from 7th of April.
1 个月Great post Mark Smalley. It's important to note that controlling what should not be configurable/changeable about a product is a huge part of making it successful too. Cars are a great example, as much of modern car maintenance should be left to professionals. But you don't usually buy cars from manufacturers, you buy them from dealerships (even if they appear indistinguishable from the brand) who will tweak and fettle them before handing them over. In some cases you'll find that dealers pre-order their stock with certain options. Knowing that customer who buy without those options are usually less satisfied with their vehicles. In the SaaS world, the Open-Closed Principle bubbles up from code level to guide us. It's usually best to build a wrapping layer around any product being integrated into a wider estate. As well as giving some operational advantages, such a layer provides a place to make tweaks, without interfering with the product. I've seen players in the SaaS space open their Product up to total dilution, by making everything configurable. They do it to cover any functionality that their competitors may have. But why put twenty buttons on something when only two get used?
Fractional CTO & Chief Product Officer - Helping SaaS Leaders keep high-value accounts and turn Technology into Service | Service Overhaul - ￡8,499 | Cut Churn Workshop ￡1.5k
1 个月Good point Mark It never fails to annoy me when SaaS providers talk about the software as ‘product’
I completely agree! A solution is composed of multiple components, and the product is just one of them. While this seems obvious, many companies still believe that a single product will solve all their problems. They focus solely on technology, neglecting other critical aspects such as processes, people, strategy, and change management. A true solution requires a holistic approach, not just a product rollout.
Trainer and "player-coach", helping to build teams that learn faster than other
1 个月So much of it is in the agile manifesto ??
Consultant | Advisor | Keynote for Strategy | GRC | P3O
1 个月Insightful