Innowaring Concepts
The Operating Model Dimensions for Innowaring
This post is part of a series outlining my principles-first approach for AI-Native product innovation.
The first post describes the origin of the Innowaring idea after I published my book, Becoming a Software Company.
This post further describes the Innowaring Concepts, the operating model dimensions for AI-Native product innovation.
When I was at Deloitte, I used to think that large firms with legacy IT models struggled with product innovation. Since I have moved out, I have realized that even small firms and startups struggle with it.
Product innovation requires an operating model evolution that most firms don’t pay much attention to. They wrongly assume that it is about developing process competency, which can be brought up to par by hiring product managers and implementing product methodology.
Product innovation is much more than that. It requires new behaviors and actions, not just within your teams but across the organization. It requires new ways to think, work, and build software products and systems—a new operating model.
An operating model must align team structures, processes, and cultures around a strategy for delivering customer-centered value through empowered, cross-functional teams. There is no specific recipe for this model.
Organizations operate differently from each other and hence have different strengths and weaknesses for product innovation. That is why lift-and-shift methodology-oriented approaches don’t work. You need to have an approach for every dimension of their operating models aligned with your organization's unique context.
Based on my research, study, and practice, I have abstracted four core concepts as key dimensions for an operating model: Teaming, Strategy, Flow, and Culture. Collectively, I refer to them as ”Innowaring Concepts.”
Teaming
As Jim and Michele McCarthy say in Software for your Head, “…the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product’s development.” You can’t ship anything that isn’t modeled in your team.
An enduring insight of all major efforts to improve human group work, from World War II to Agile, is that structuring a group into small, autonomous teams is critical. That is true for software development as well. Therefore, the most fundamental unit for engineering high-value tech products and systems isn’t a resource or person hours or days; it is an empowered team.
Team isn’t a concept that only applies to the core team or teams building the actual product or system. It extends to every other aspect and level of an organization, including the enabling teams like marketing, or non-technical business teams. You have to see your organization as a Team-of-Teams.
Most folks without exposure to high-performing product organizations assume that customers are the source of innovative ideas. That isn’t true. The actual source is the team-of-teams, which is allowed to build the best solutions for high-impact customer problems.
A great teaming dynamic requires that the overall team structures and communications among teams are just right. As a result, the most critical management task for the Innowaring Model isn’t optimizing resources and timelines. It is optimizing information flow to enable cross-functional collaboration.
Strategy
A well-crafted strategy is a tool to create focused action among your teams. It provides a decision framework to align your teams and their work with the most impactful business or customer problems you can solve. It helps answer the most tricky question in building good software: What should you build?
The central challenge in product innovation in B2B startups or enterprise environments is often a lack of focus. With so many potential problems (and related outcomes) across various stakeholders, it’s easy to lose sight of the problems to solve with the most impact. A clear strategy is reflected if there is a stated focus on 2–3 problems your innovation will solve, with an understanding of who has that problem (your customer or user), and the business impact you want to achieve.
With the possibilities that AI creates for building solutions, a strategy is more critical, not less. How will you execute your solution vision? What specific customer, technology, or industry insight is driving your choices? What are the perceived barriers? How will you test your solutions and mitigate the perceived threats?
All the product strategy decisions and choices must be shared transparently with your teams. The more information your teams can assimilate, the more they will build with product thinking. Without transparency, they default to existing as feature teams or teams delivering specific project builds.
Flow
Once you have prioritized the right problems to solve and believe you have the correct team structure, those teams must discover and deliver the solution that creates the intended strategic outcomes. This cycle is called the product development flow.
In The Principles of Product Development Flow, Donald Reinertsen explains the key requirement for the development flow: ”Product development creates economic value by producing the recipes for products, information, not by creating physical products.” It is critical to understand that if we build a software product system similar to what everyone else is building, copying a recipe, we create no new information or business value.
You must discover and deliver your solution with an experimental mindset for innovative software products and systems. You have to start with the simplest solution and iterate further in small batches. You have to mitigate your solution risk and test your strategy's intended value hypothesis in as cost-efficient ways as possible.
The product development flow that delivers new and differentiated business and customer value requires the right mindset for solution discovery and development infrastructure to deliver small and frequent releases. Each release cycle should mitigate risk or improve understanding of what solutions customers need. The principles of flow that you find ways to make each cycle as short as possible.
From my experience, the missing development flow is often why many organizations with the right teams and plenty of ideas fail to develop innovative software products and systems.
Culture
An organization's culture of innovation is the final ingredient for product and systems innovation. Even the best teams struggle to achieve the desired strategic outcomes without the right cultural structure. And, optimizing the product development flow is almost impossible.
It’s okay to say the teams must be empowered to build the best solution for a hard problem. But how can you provide creative freedom without causing confusion and chaos? What do you allow to happen in trust? What do you control with a management process? Culture emerges from drawing a careful balance between trust and management control.
Process discipline and control are essential. However, the amount of process should be right-sized to achieve the optimal development flow. This isn’t a one-and-done exercise; it needs continuous improvement based on your team-of-team's strengths and weaknesses.
The legacy IT mindset prefers executing specific plans that guarantee predictable outcomes. A culture of product innovation requires an experimental mindset and learning to deal with uncertain outcomes. Such a culture values learning through execution over making project plans sacred.
The right innovation culture takes time to develop and is easy to destroy. Building and preserving it requires a continuous and careful calibration of organizational values by everyone from top to bottom.
Each Innowaring concept isn’t meant to be the same. Its relative importance depends on the unique context of the organization’s strengths and weaknesses, the opportunities it is pursuing, and the risks it perceives. These concepts outline the key dimensions for operating models that unlock product and system innovation. While an organization may need to focus on one concept more than the other, if you disregard any of them, you will start faltering on your innovation objectives.
This post is part of a series outlining my principles-first approach to AI-Native Product Innovation. Links to the previous posts (Part 1)
The next few posts describe the principles for each dimension of the Innowaring Model.