The economics, structure, and behavior of platform ecosystems and organizations

A recent article by Dan Woods collects the results of his research over several months interviewing ‘about a dozen people’ who have lived and worked within Amazon’s Web Services organization.

The piece appears to confirm a hypothesis I have held for some time: organizations that are based around user-centric innovation will evolve similar organizational forms and patterns of behavior. This is a direct parallel to convergent evolution:

In evolutionary biology, convergent evolution is the process whereby organisms not closely related (not monophyletic), independently evolve similar traits as a result of having to adapt to similar environments or ecological niches. | ScienceDaily

I am using the term user-centric innovation as developed by Eric von Hippel in Democratizing Innovation and related works. [I intend to review that work in more detail in subsequent writings, here at On The Horizon.]  As von Hippel wrote in a summary of that book,

When researchers say that innovation is being democratized, we mean that users of products and services—both firms and individual consumers—are increasingly able to innovate for themselves. User-centered innovation processes offer great advantages over the manufacturer-centric innovation development systems that have been the mainstay of commerce for hundreds of years. Users that innovate can develop exactly what they want, rather than relying on manufacturers to act as their (often very imperfect) agents. Moreover, individual users do not have to develop everything they need on their own: they can benefit from innovations developed and freely shared by others.

User-centered innovation processes are very different from the traditional, manufacturer-centric model, in which products and services are developed by manufacturers in a closed way, with the manufacturers using patents, copyrights, and other protections to prevent imitators from free riding on their innovation investments. In the manufacturer-centric model, a user’s only role is to have needs, which manufacturers then identify and fill by designing and producing new products. This traditional model does fit some fields and conditions. However, a growing body of empirical work shows that users are the first to develop many and perhaps most new industrial and consumer products. Further, there is good reason to believe that the importance of product and service development by users is increasing over time.

Keep in mind that a ‘user’ can be an operating unit of a business, not just an individual ‘end user’. And some of von Hippel’s users can create the product or service they desire, and then incorporate it into products or services that they in turn share with others.

The insight that von Hippel is offering is that innovation is accelerated by users taking a lead role in designing and creating the products and services they require, rather than trying to capture their needs and pass that along to some other company or organizational unit. When expanded to the logical end point, a company – or ecosystem of companies – based on user-centric innovation will decrease time and effort in the production of goods and services, and the goods and services will be ‘closer’ to the needs of all users involved in the network of innovation.

Returning to Dan Woods’ research into Amazon Web Services organization and practices, the orientation of AWS toward user-centric innovation has led to an organization that appears quite similar to the Haier model of Rendanheyi, as described in Hamel and Zanini on The End of Bureaucracy and Evolution of the Platform Organization: What We Can Learn From Haier.

First, here’s Woods’ characterization of team structure:

  • Each of the groups that owns a service has a set of goals and possibly a P&L that represents success. A roadmap is generally in place to meet those goals.
  • The teams are ostensibly autonomous and can make any important decision needed to meet their goals.
  • The ‘value to the customer’ is part of the mission for each team. This codified using content such as mock press releases to ensure developers keep end user needs in mind.
  • As much as possible, teams are kept small, adhering to the two-pizza rule, meaning about six people.
  • Services can be refactored or new services can be spun out to new teams. Teams that don’t work are shut down and the technology they created is distributed to other teams or discarded.

Like Amazon, each Haier micro-enterprise (ME) creates an annual plan -- including its own profit and loss statement. MEs are highly autonomous: they have the right to make decisions, the right to hire talent, and the right to distribute compensation.  MEs are charged with adding value to their customers. MEs are generally small, growing only as large as needed, and outsourcing many non-essential functions. (Note that MEs are usually less than 10 people, in order to keep their vitality.) It is quite common for new MEs to be spun out of existing MEs, and ineffective MEs are shut down, or in some cases they are taken over by other MEs. Also note that if a micro-enterprise owner is not doing a good job operating the ME, the other team members can propose a new owner.

In Hamel and Zanini on the End of Bureacracy, I wrote about Haier’s open innovation model:

From Rigid Boundaries to Open Innovation — Perhaps the most anti-bureaucratic element of Zhang’s vision is breaking down the barriers to bringing in outsiders — non-employees — to help the company innovate. All new products and services are developed on an open innovation approach, involving potential users of the envisioned product.

Through a 'contact point network' comprising various social channels, Haier collected over 30 million responses on features and needs, and built a global network of 400,000 technical experts and institutional innovators.

Hamel and Zanini spell it out:

"By moving its product development process online, Haier has reduced the time from concept to market by up to 70%. Manufacturing and design nodes, user MEs, potential customers, and business partners work in parallel throughout, starting with the earliest discussions about customer needs. That maximizes creative problem solving and minimizes the risk of clumsy handoffs as the product moves toward launch. While many executives view their businesses as linear value chains, beginning with R&D and ending with sales and support, Haier sees them as value networks in which all parties collaborate at every stage."

Woods continues, illustrating that the AWS development process demonstrates organizational principles that are more general and far-reaching than the context of shared service architectures alone. For example, ‘every team can do what makes sense to get the job done fast’, which translates into an inclination toward high levels of parallelism, since individual teams are not waiting for others to add functionality for them.

Woods goes into significant detail on the ‘away team’ model of cooperative innovation. As he explains it,

Changes to one team’s service may be implemented by another team who needs the enhanced capability by what is called an Away Team. This team works on the Home Team’s code to add what it needs according to established engineering standards and then leaves that code in good order to be maintained by the Home Team who owns the service, with help when needed.

There are variations of the away team idea, such as the situation where the requesting team does not have the technical ability to make the improvement desired, and instead has to ask the ‘home team’ to make the changes. Alternatively, the away team can opt to simply duplicate the desired service. As he notes,

There is no concern about duplication across the platform as long as you have a need that will help you move forward.

Note the consistent emphasis on accelerating innovation, and how it is reflected in organizational autonomy, models of cooperation, and a willingness to accept the tradeoff of speed over reuse of existing services.

I don’t know if Haier has developed the notion of an away team, per se, but the principle ideas seem totally in line with Haier thinking.

Finally, Woods discusses the concept of Amazon ‘bar raisers’,

Amazon staff who act as independent experts who approve key decisions, often who work on other teams, are used not only for hiring, for which they are widely known, but for high impact decisions for design, customer experience, architecture, and A/B testing. It is possible to go against the recommendation of a bar raiser, but such a move is noted and made visible to higher levels of management.

Bar raisers play a role that is something like that of Haier’s platform owners, who might bring together a group of MEs to collectively design and implement a key service -- for example, a common set of functionality for IoT communications across the refrigerator platform.

Conclusions

User-centric innovation can lead to significantly faster development and rollout of new products and services. In the case of Haier, micro-enterprises bring users into the design and development of new products and services in an integral way, and therefore the result is a much greater degree of product fit. In the case of Amazon, internal teams pushing to innovate act as users themselves, and the ecosystem of internal teams has been formed around those dynamics.

Convergent evolution is at work, so we should not be surprised that the shape of organizations that reform themselves to operate on user-centric innovation principles look very similar. It would be surprising if they didn’t.

Take a good look: it is the shape of things to come, as more and more companies move onto a platform ecosystem model of business.


Sign up for On The Horizon's free weekly newsletter to keep informed on new writing, related thinking, events, and other activities.