Common perspectives on productisation
In the ever-evolving landscape of product development and management, the concept of productisation stands out as a multifaceted process pivotal to transforming ideas into market-ready solutions. It simply means turning something that is not a product into a product, which is quite different from producingit.
Productisation is commonly approached through various lenses (such as process, revenue, capability, and mindset), each offering a unique perspective on turning internal processes or solutions into commercially viable products. This encompasses not only the initial phase of the product lifecycle, including discovery and design thinking, but also the monetization of existing solutions and the continuous adaptation to remain relevant in a changing market. Let’s illustrate the four mentioned perspectives.
- Process: Productisation as the initial phase in the product lifecycle, encompassing product discovery and the adoption of design thinking methodologies. This stage is critical for identifying user needs and developing a viable product concept. Design Thinking.
- Revenue: Productisation as a means to monetise existing internal processes or solutions by offering them as products to external customers facing similar challenges. This represents a strategic shift from internal optimisation to external service provision.
- Capability: Productisation as a core competency that organizations must continuously and iteratively engage in to adapt and remain relevant within a rapidly changing market environment. This underscores the importance of innovation and responsiveness to evolving customer needs.
- Mindset: Productisation as a mindset shift towards a “capitalisation imperative”, where organizations and individuals begin to view and evaluate their actions and potential offerings through the lens of product potential. This involves a strategic approach to thinking about services, processes, or intellectual properties as potential products. Product Thinking.
Productisation is about decoupling monolithic designs into modular designs
Fundamentally, productisation is an organisational concept that champions the shift from monolithic to modular designs through decoupling. This means deconstructing, reframing, or refactoring a ‘product’ into stand-alone and composable ‘products’ with high cohesion and low coupling, none of which were products before. Together they not only serve the purpose of the original ‘product’ with improved cost-effectiveness (lower coordination and maintenance costs) but also open up new offerings. This transition is essential for fostering flexibility, scalability, and innovation within an organization, breaking down complex systems into manageable, independent, composable, meshable components. It allows for cleanly separating concerns to different teams, each focusing on productising different things, thereby enhancing innovation and efficiency.
What then is a product?
So, what then is a product? A product is not a solution to a problem; it just enables the users to solve their problem. It can do this because it decouples the use-case from user-specific usages, and offers itself as a design pattern. The purpose of a product is the value-in-use, but if it tries to address the specifics of various usages it becomes a point solution. Or a monolithic mess that tries to be manypoint solutions.
Products are ‘simple’ machines. Consider the six simple machines of antiquity (lever, windlass, pulley, wedge, inclined plane, and screw): they offer mechanical advantage to you, the user. But you still have to do the work. Each of them encapsulates a use-case and offer themselves as (composable) design patterns. Combine an inclined plane and a screw: spiral staircase. A wedge and a screw makes a drill. A product is nothing more, and certainly nothing less, than a boost to a user’s productivity with regards to some utility the user enjoys.
A Double Diamond Approach
We can use the Double Diamond design process model to implement the decoupling activity. The first ‘diamond’ discovers (divergent phase) and then defines (convergent phase) the problem space in the form of some use-case we can productise. The second ‘diamond’ then develops design patterns we can use to delivercomposable ‘products’ or methods.
Productisation transcends traditional product development, embedding itself as a core organisational strategy. Through the lens of the Double Diamond, it not only simplifies the complexity of innovation but also institutionalizes a dynamic framework for continuous improvement and market adaptation.
Double Diamond works in reverse, as well. Many people perceive the model as a process, where you discover-define-develop-deliver in that order. At Dairdux, we tend to see it as a map of different regions where the design ‘process’ can trace an erratic if not random journey. I just realised that you can work the Double Diamond backwards. Doing point solutions is fine, as long as you dedicate some effort to capitalising on them. By iteratively wresting something generalisable from delivered solutions, pointy or not, you develop patterns. As you progress, you can define a narrower set of use-cases, and, finally, discover a universal issue. This can help combat the human tendency to jump from the surface of the problem to conclusions about a ‘solution’ at the first sign of an opportunity.
Organisation from first principles
We can derive two principles from the heart of productisation: the principle of embodied microinnovation and the principle of recursive productisation.
Embodied microinnovation leverages productisation to explore and decompose the problem space into use cases and design patterns, converging on methods that a team can offer as a product. The microinnovation is ‘the doing of new things or the doing of things in new ways’ (as Schumpeter would have it) in the users’ domain. And the users embody this microinnovation by adopting the usage of the product into their sociotechnical ‘systems’. Specifically, into their sociotechnical practices.
Recursive productisation, in turn, applies the same approach within an organisation, creating a topology of teams where each offers itself as a product to other teams or units. This principle becomes recursive when you consider the market-facing productisation teams as the ‘market’ for internal platforms-as-products (any internal XaaS, really). The platform teams, then, is the ‘market’ for infrastructure-as-products. We think you should decompose organisational functions into products (and product teams). For instance, most business units nowadys need embedded data engineers and data scientists. So, someone should dedicate a team that offers to find and field eg. data engineers (talent sourcing as a platform-or-service). Incidentally, the business case for this product is the productivity gains for the business units. Recursive productisation reframes the governance and management layers of the organisation: they exist to boost the productivity of the teams doing business. If the managers are unable to conceive of the work they do as products for these teams, they aren’t much use for the company, now are they? As the inimitable Drucker said, ‘marketing and innovation are the only things that make money; everything else is cost’.
These principles highlight the strategic importance of productisation in driving organisational agility, fostering a culture of innovation, and ensuring market responsiveness.
Productisation in Data Mesh and Team Topologies
The concepts of platform teams in Data Mesh and Team Topologies perfectly embody the principle of recursive productisation by structuring organizations into modular, independent teams that offer themselves as products within a broader ecosystem. Data Mesh also describes teams that federate the governance of a data mesh. Team Topologies have their enabling teams. Same productisation story, different actors. Platform teams, as outlined, provide foundational services and capabilities that enable other teams (like the data product development teams of Data Mesh and the stream-aligned teams of Team Topologies) to focus on their direct, value-adding activities. This structure promotes efficiency, scalability, and innovation. Furthermore, any internal platform can be monetised by productising it for actors outside the company (in the revenue sense of productisation).
Data product development teams and stream-aligned teams, in turn, manifest the principle of embodied microinnovation by operating within this ecosystem to rapidly iterate, adapt, and innovate on their product offerings. These teams are designed to be closely aligned with the needs of the business or customer, enabling them to quickly respond to changes and incorporate feedback, thus driving continuous innovation at the micro level within the organization’s broader strategic framework.
Data products themselves acquire ‘product-hood’ by decoupling the usage of data with its user-specific transformations and business semantics from the data-as-a-product.
Products are team-sized
While we are on the subject of Team Topologies, I figured that the best conclusion to this article is one of the shining diamonds in that book. Concepts like ‘team cognitive load’ and ‘inverse Conway maneuver’ indicate that products are team-sized. Everything worth doing in a company tends to require a team effort. And not just any team, but a cross-functional and multi-disciplinary team. If we see organisations as agent-based models (and we should), productisation teams are the primary agents. To spell it out clearly, this means teams that productisesome boost to some group of users, outside the company or inside.
Purpose. Mastery. Autonomy.
Productisation teams are the way to get things done. So, managers should see it as their jobs to enable (or boost, if you will) them to be movers and shakers. In the simple but powerful words of Pink’s book Drivethis requires
- A cleanly scoped singular purpose (or objective, if we talk OKRs)
- The mastery to serve that purpose (skills, talents, and resources)
- And enough autonomy to work effectively
But what about cost control? The most effective way to achieve overall cost-effectiveness and protect the company’s bottom line is not to minimise the costs to your own operation (leaving your people to do more with less) but to boost the productivity of other operations. I told you it was recursive, didn’t I?
Appendix: why isn’t EVERYONE already busy productising?
It’s a pertinent question; I mean, Stafford Beer published his book Brain of the Firm in 1972. It’s not like the idea of recursive patterns for organising an enterprise is new. What makes us think to that the time is now ripe for a paradigm shift? What has changed during the last 50 years? It’s not about any specific change, but the accelerating rate of change. As Stefan Wendin says in the article embedded below: playing it safe is the riskiest move of all. Now more than ever. Betting that things will stay the same long enough for your products to pay dividends before they are obsoleted is a fool’s gamble. Stop obsessing about your products and start productising! We bet that fear of obsolescence will be a powerful motivator.
Of course, there are other factors to consider. One of which is the inherent interest of managers and executives to retain the illusion of control. Incidentally,Dairdux just happens to be working on an article about this issue and the root problem of management heuristics, named “Innovate Without Trying: An Adoption-Centered Management Heuristic For Adaptive Growth”.