Implementing a Product Model in a non-product enterprise
Some quick definitions to help:
In traditional industries, a product is a tangible good or service that meets customer needs, existing independently of the company (e.g., a car or shampoo).
In tech, especially SaaS, a product is a digital experience integral to the company’s identity. The product is the company, encompassing brand, service, and customer interaction.
In the enterprise, products are often internal tools or systems designed to support broader services or value streams. These products enable operations, enhance efficiency, and contribute to the overall service delivery but are not themselves the primary offering to external customers.
A product approach is a strategic method for creating and managing digital products, emphasising iterative development, user feedback, and cross-functional collaboration to ensure the product evolves with market needs.
SaaS (Software as a Service) is a cloud-based delivery model where software applications are hosted online and accessed by users over the internet, typically through a subscription.
Product Models are popular and for good reason
Organisations must become more customer-centric and respond quickly to evolving demands in today's fast-paced market, as the time to capitalise on opportunities is shorter than ever. To meet these challenges, many have adopted agile and lean methodologies. However, there's a growing recognition of the importance of a product-centric approach, which shifts the focus from short-term projects to continuous customer value. Tech giants like Facebook, Amazon, Netflix, and Google have successfully demonstrated this strategy, making it an attractive model for wider adoption.
What’s the Problem Then?
Product-centric companies like Facebook, Instagram, and Canva aren't merely companies that happen to have a product; the product is virtually the whole company. There is no distinction between the company, its brand, and the SaaS product they offer to customers.
However, this model doesn’t translate neatly into the enterprise context. Digital products, particularly those delivered through a SaaS model, are essentially services. Furthermore, the approach needed for success varies greatly between contexts, which are many and varied in an enterprise setting vs the simplicity of a startup.
Enterprises like banks, media companies, or healthcare providers cannot simply adopt the product models that work for tech companies. Their challenges are more complex, requiring tailored strategies that provide additional methods and nuanced application in the spaces above and in-between these ‘products’.
Specific Challenges when shifting to a Product Model in a large enterprise
Nature of Enterprise Products: Most "products" in an enterprise setting are operational tools designed to support internal tasks. These aren't consumer-facing applications but rather tools that enable business processes. This distinction is critical because agile, lean, and product models popularised by tech companies don't fully address the complexity of these environments.
Complexity and Scale: The scale and complexity of enterprise products—and the services that support them—are significantly greater than what is described in the tech models. Ensuring the organisation can create products for themselves involves navigating a web of dependencies, stakeholders, and legacy systems, as well as a range of other ‘products’ all competing internally. Successful design in this context requires new methods to facilitate shared understanding, decision-making, prioritisation, and process alignment.
Misalignment Between Strategy and Execution: Many organisations struggle to connect their strategic goals with the operational realities of their middle layers. This gap often results in neglecting best practices in strategy and underestimating the sophisticated design capabilities needed to manage complex, interdependent systems.
Why it matters
Given that markets are moving faster and faster, the shift to lean/agile product models is an effective response to ensure organisations can remain consistently competitive in the long run.
However, in order to make the shift, or do I dare say ‘transformation’, we first must recognise that most organisations are not product oriented startups and in order to enjoy the benefits of the various frameworks they must include services and ecosystems in the conversation. This will require working outside the scope of a single product, and of a single department such as technology. True cross functionality is far more than having UX design and Engineers working together in a single team.
Imagine how powerful your organisation could be if everyone (and every product) knew how it contributes to the symphony.
Achieving Alignment Across Products and Services
Careful integration of a Product Model ensures every product and service within the organisation is recognised as a well-structured ecosystem. In this environment, cross-functional teams are not just working together; they are systematically linking strategic objectives with operational execution without conflict and contradiction between ‘Products’. This connection is facilitated through careful design of new ways of working practices that are guided by systems thinking as much as they are by Product Models.
These teams don’t just create functional products; they develop solutions that are critical components of the organisation’s value streams. Each product and service is purposefully designed to support high-level customer themes and organisational goals. This approach ensures that all elements—whether SaaS products, platforms, or internal tools—contribute directly to the overarching value streams that drive the organisation’s success.
What’s standing in your way?
Typical challenges include:
Confusion about the definition of the word product, leading to turf-wars, or worse, leaders actively avoid engaging.
Narrow, individualistic metrics, attached to the development of specific products or platforms. This will only further promote and embed the incorrect idea that each product is a stand-alone thing.
Fixation on the Latest Tech-Oriented Models: An unhealthy obsession with the latest trends in technology can blind organisations to the broader context in which they operate, leading to solutions and models that are technically brilliant but practically irrelevant.
Governance Overreach: Excessive governance stifles innovation, particularly when it tries to manage the unknown through rigid controls instead of embracing adaptive and iterative approaches.
The solution is to think more broadly, understand complexity, and use design to take action at all levels.
In order to deliver value in harmony, you’ll need to build the tools and understanding to ensure it’s possible in your organisation.
Create a Service Blueprint to explore and represent the organisation as a system.
Use design in multiple concurrent ways, to make useful interventions at the right level within systems.
Identify where & how best to take action in the system in order to meet the challenge.
Simplified Service Design Blueprint by BigPictureRoxi
1. Utilise Service Blueprints: A service blueprint is a visual representation of the organisation that includes customers, processes, services, and products. They are powerful because they highlight how close to the customer certain elements are, and they also treat all products, services, and other elements as touch-points with the customer. Understanding how individual products relate to broader value streams and customer journeys is key to creating successful enterprise solutions. The Service Blueprint sits in the organisation at the collective space above all products and services, and provides an holistic view as well as a formal way to discuss and make decisions.
Key reasons for introducing a Service Blueprint view at the multiple-product-strategy level:
Provides a clear articulation of the many elements that come together to support our organisational value streams.
This view and resulting conversations evolve your existing product ceremony or quarterly planning to becoming more holistic, value based coordination.
Can be used to capture the current state OR future state.
Provides critical context and background for creating compelling and actionable products.
This empowers us to:
Review and ensure we have capacity and capability in the right places/ teams.
Communicate our overall vision for how we will serve our customers through value streams.
Create clear and meaningful vision statements and goals for each product.
Facilitate decision making and prioritisation across multiple products (and services)
The Four Orders of Design
2. Use Design in multiple concurrent ways. Anything you build, create, or change is an act of design whether you call it that or not. Design is broadly grouped into 4 orders that span from Symbols & Signs (first order) through to Ecosystems. We have become better and better at building digital products in part because we have applied higher order design principles to the work at hand. For example the practice of LeanUX is design, applied to the problem of whether customers even want the thing we plan to build. It has taken the tools and methods used to build interfaces, and applied them at a higher level, empowering us to manage a greater risk, for a much lower investment.
Design was once understood primarily as a way to communicate. Let’s call it ‘Design-to-Convince’. The true power of design is much more and executives expect much more now, they want it to solve problems. Let’s call it “Design-to-Solve”.
But to make the most of the power of design in your organisation, you must harness both, often at the same time.
Using multiple orders of design when introducing a Product model to your non-product organisation:
Design-to-Solve (3rd & 4th order design) - This capability is considered most critical in organsiations whist being least visible. Solving product problems is actually about designing interactions, systems, and environments.
2nd Order design (Physical Objects & Artefacts) is generally referring to things such as a car, or table, and are ignored for this discussion.
Design-to-Convince (1st order design) - The process of introducing and installing a new capability such as 4th order design-to-solve, will require a concerted effort in education and adoption. This simple but effective application of design is critical to this part of the change. Storytelling, educating, reminding, persuading, all hallmarks of great design in communication. This layer of design provides a tangible, visibility to the other orders of design.
In order to succeed with a new product model, it’s critical that we use design to convince, as much as we use to to solve.
The 12 Levers of Change in a System
1. The power to transcend paradigms.
2. The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises.
3. The goals of the system.
4. The power to add, change, evolve, or self-organise system structure.
5. The rules of the system (such as incentives, punishments, constraints).
6. The structure of information flows (who does and does not have access to information).
7. The gain around driving positive feedback loops.
8. The strength of negative feedback loops, relative to the impacts they are trying to correct against.
9. The lengths of delays, relative to the rate of system change.
10. The structure of material stocks and flows (such as transport networks, population age structures).
11. The sizes of buffers and other stabilising stocks, relative to their flows.
12. Constants, parameters, numbers (such as subsidies, taxes, standards).
3. WHERE to intervene in the system itself:
This approach uses the power of Design-to-Solve because we have taken an analytical approach and are making decisions about the system as a structure.
Simultaneously, as we learn more about the system we can begin to identify the higher impact intervention points. According to Donella Meadows, there are 12 leverage points in any system.
The 12 levers are in a hierarchy (shown on the right) offering far greater influence and change the higher you go. By properly understanding the whole system and not just the pieces that superficially appear to relate to our product, we can find the best places to make interventions.
The Stacey Matrix overlaid with The Cynefin Framework by Dave Snowden, indicating the types of action for different contexts.
HOW to intervene in the system:
We have already established that the organisation itself is a complex system of products, services, value streams and more. In order to make real change involving people, process, products, and tech, it’s important that we understand the kind of environment we’re in.
Furthermore it is important to map the system dynamics inside and outside the organisation to ensure we have as much knowledge about how the system actually works, so we can apply an appropriate approach for taking action.
To summarise thinking about taking action in complexity:
If you are in an environment that is well known and predictable to you, then you will interact as follows:
Sense - Analyse- Respond.However, If you are in an environment that is largely unknown, and unpredictable, then you will do the opposite:
Act - Sense - Respond.
I have done little justice to the Stacey Matrix, and the Cynefin Framework, and I recommend you look into both to learn more.
Action Steps for Implementing the a Product Model into a Non-Product Organisation
I have assumed you have a solid understanding of one or more Product Frameworks as a starting point. From there the real work is to understand your organisation well enough to implement it. To get started, consider these action steps:
Utilise Service Blueprints: Begin by mapping out your organisation using service blueprints. This will help you understand how different products and services interact and contribute to value streams.
Identify Leverage Points: Determine the most effective leverage points for intervention within your organisation. Combine the power of Design-to-Solve, along with Design-to-Convince.
Assess Complexity: Use the Stacey Matrix to evaluate the complexity of your challenges. Identify which areas require more adaptive approaches and where you can apply best practices.
Form Cross-Functional Teams: Build teams (most likely cross cutting, informal structures) that bring together diverse perspectives and skills. Empower these teams to experiment, iterate, and adapt as they work toward solutions.
Embrace iteration across the entire Blueprint: Adopt an iterative approach to problem-solving, recognising that solutions will evolve over time. Use feedback loops to refine your collective AND individual visions.
Recap
Transitioning to a product model in non-product enterprises requires more than just adopting agile and lean methodologies. It demands a broader perspective that considers the organisation as a system and recognises the interconnected nature of products, services, and value streams. By leveraging tools like service blueprints, the power of design at different altitudes, and understanding taking action in complexity, organisations can create and implement a product model that works in your unique organisation. Success lies not in isolated efforts but in aligning every part of the organisation to work harmoniously toward a shared vision of customer value.
