Product Organization
The product organization is ultimately responsible for delivering smart, connected products. Given the complexity of a typical AIoT product, as well as the different cultures that have to be brought together, building an efficient and effective AIoT product organization is not an easy task. This section of the AIoT framework discusses key challenges and proposes a specific setup that can be easily adapted to fit one's individual needs.
Product Organization
A successful product organization differs significantly from a project organization, as we will see in the following. In order to understand the differences, we will first look at the typical product lifecycle phases, before discussing how a product vs. a project organization typically evolves during this cycle.
Product Lifecycle Perspective
Particularly at the beginning of the new product journey, it is important to take a step back and look at the complete product lifecycle to be prepared for the road ahead. The lifecycle of most successful products can be described as follows:
- Exploration: During this phase, the initial product is developed, market reception is validated, initial customers are acquired, etc. Please note that the popular concept of a Minimum Viable Product (MVP) is more difficult to execute if physical product components are involved.
- Growth: The growth phase aims to expand reach, scale sales and continue to develop the product to stay competitive
- Maturity: In this phase, the focus is on customer retention and to sustain market share
- Decline: Finally, a strategic decision regarding strategic pivoting or phasing out has to be made; often the start for a next generation product
The interesting question now is: what must an organization look like to support a product through these different phases, and how does the organization itself have to evolve?
Traditional Project Organization
In many incumbent enterprises, the development of a new product often starts as a project because from a controlling and administration point of view, setting up a project is more lightweight than establishing a new organizational unit. Since in the early stages it is often not known whether the product idea will be successful, this is quite understandable. If the initial MVP is promising, the project might be transferred to an internal accelerator. If the product shows the potential to scale from a sales point of view, a new line of business may eventually be created.
In principle, there is nothing wrong with this approach. However, in practice it can cause severe problems. To better understand why, let us first quickly summarize the key differences between project and product. The table following provides a high-level comparison.
Toward the AIoT Product Organisation
In practice, there are a number of common problems associated with starting a new product with a project mindset and setup. First, a product should be developed from the beginning with product KPIs as the central measurement of success; customer satisfaction and customer adoption should be key KPIs from the very beginning. Typical project-centric KPIs such as development and go-to-market milestones (as well as cost) should be secondary.
Second, a typical project has a fixed start and end date, while a product needs to take a longer-term perspective. Especially in manufacturing-centric organizations, it is still a common assumption that at the end of the initial development project, the product is "ready" and can be handed over to a maintenance and operations team, eliminating the costs for expert developers. Such a transition will obviously cripple any long-term oriented, continuous advancement of the product.
Even if the product is initiated as a project in the early stages, it is key to remember the following:
- Use product-oriented KPIs from the beginning
- Implement a sustainable team setup with a 4 to 5-year perspective; this will continually evolve the product beyond the MVP
- View the project only as an administrative vehicle for initiating the product organization, but follow a product-oriented approach from the beginning
Organizational Culture
A key issue in most AIoT product organizations is the cultural differences typically found in heterogeneous teams that need to work together. Developers who are used to do frequent, cloud-enabled updates have a very different way of managing projects compared to manufacturing-centric engineers who know that after the SOP (Start-of-Production), any change to a physical asset after it has left the factory usually involves a costly and painful recall procedure. This "Clash of two worlds" within an AIoT product organization should not be underestimated. Actually, make this a "Clash of three worlds": don not forget that the "AI people" usually also have a culture which is very different than the culture of the "cloud/software people".
As shown in the figure following, different types of organizations typically have different types of cultures, even within the same company. Applying a one-size-fits all method to such a cultural mix will be difficult. This topic is discussed much more in-depth in the Agile AIoT section.
Authors and Contributors
|
