Converge

Martin Eriksson’s Venn diagram¹ is an excellent representation of modern product organisations, and the role of product managers in them. The product managers sit at the centre of the product organisation, balancing and conducting the three key participants in the product organisation—business needs, UX and design, and the tech/development teams.

This post is not about Product Managers. Read Martin’s post for them. This is about the whole product organisation², the interactions between the parts, and using the wonderful Venn diagram to represent it.

Why, what, how

I like that this Venn diagram also neatly captures the three decisions that are made in the modern product development process —

• why are we doing any of this,
• what are we building to satisfy the why, and
• how are we building what we’ve decided to build.

The rationale for making a product, the why, is mostly provided by the business team, the sponsors, often the Hippos. Outside of a few organisations with empowered product teams, this decision usually exists as a one way flow. The business teams decide why the product needs to do what it needs to do, and the product team delivers on it. In the empowered teams, the product team may conduct user research and/or data analysis to verify that the why is valid before proceeding. If they find conflicting evidence, they may use the data to revisit the rationale with business team or leadership.

The second decision, what, is where most product managers spend most of their time. This is where they may map the provided why into specific features and products based on data analysis, user testing, or hypothesis (sometimes masked as experience). The product managers may then work with the UX and visual designers to turn the features into prototypes. These prototypes may then be tested, iterated, and refined, till we come to a final definition of the desired product.

The final decision, how, is then handed over to the engineering team. They will take the provided product definitions and designs, and code them into being. In more evolved product organisations, the engineers may be encouraged to interact with the users, the researchers, and the designers. They may be encouraged to better understand the user needs, and to provide feedback early in the product design cycle. On the other hand, in more engineering-focused organisations, the engineers may be encouraged to focus on the quality of how they create products, not what products are or why they create them or who uses them. In such organisations, the engineers’ interaction with the other participants is often limited to asking for clarifications when the design/definition may be unclear, and in deciding the ordering of tasks to be completed (sprint/product backlog management).

This reality of product organisations brings us to my other favourite aspect of that Venn diagram.

The overlaps

Martin’s diagram draws focus to the central overlap where the product managers work. I also like to think about the remaining three overlaps and how they induce discomfort in the organisation (making PMs even more pivotal).

Let’s start with the engineers. The engineers usually don’t have much direct overlap with defining business needs or decisions. Their interaction with the business and leadership is therefore largely restricted. Many engineers are also not very comfortable about facing the users. This can lead to reduced interaction with the UX research teams, and with need explorations. This further handicaps the engineers from providing deeper feedback into defining the what of the product.

The what team (UX) may interact with the business team to share insights from user research. They may also share the state/direction of designs and prototypes during iterations for feedback from business owners. But as custodians of the product design and direction, and as custodians of what users want, they may not often be very welcoming of inputs from outsiders—hippos suggesting features from their favourite apps or for their particular departmental needs, or engineers suggesting ideas based on latest platform design templates.

Finally, the business team, the sponsors, the Hippos, the owners of the why. They’re usually the highest ranked, in the larger organisational hierarchy, amongst all the participants in the product team. This often makes them aloof, and largely outside the product organisation. It takes a highly self-aware business leader to encourage, engage, and adapt to, feedback from rest of product organisation about the rationale of the operation. To accept challenges to the description of their why.

These base hurdles to direct, frequent cooperation between business, UX and tech are what makes the product managers important. The nature of these overlaps in a particular organisation defines the reality of product managers’ roles—from misclassified project managers to conductors of an orchestra to mini CEOs.

A few product organisation types

Another great quality of this Venn diagram is its adaptability to represent numerous types of product organisation. Here are three (of many).

The Indie

The solo entrepreneur, the indie founders, the do-it-all dudette. They don’t have much choice, they just have to wear all the hats. Sometimes all together, at other times one or few at a time. The circles don’t have a perfect overlap because the solo founder may still seek outside help on one or more areas, some or all the time. But they are solely responsible for owning all the product decisions—why, what, and how.

Incidentally, this Venn diagram may also represent tightly knitted product teams where everyone multitasks. The kind where product engineers get involved in user interviews, where designers and engineers strive to understand what the data reveals, and where the business sponsors listen to feedback when the research doesn’t agree with their directions. These teams appear to be, sadly, even rarer than indie founders.

The two founder startup

This is a typical two founder startup—a tech person and a business person. The business person owns the why and the what (along with who and many other hats), while the tech person focuses on delivering the how.

This Venn diagram also mirrors how many product organisations with strong engineering culture work. The business team, the product managers, and the designers work together on defining the why and the what. This what is then handed over to engineering to deliver how they consider best. The engineering organisation focuses on excellence at converting the product definition into reality, and doesn’t focus too much over the product or users’ experience of it (within PM defines boundaries).

Beyond the startup

The startup will hopefully turn into a scale up, which may one day become a large enterprise. Somewhere along that journey, the product organisation turns into this shape.

Business, UX/UI, engineering, even product management, live within their own independent hierarchies. They work together on products, but they live in, are measured by, and adhere to norms of their own vertical organisation. This draws them apart, makes interfaces rigid, and interactions distant.

This is also when innovation slows down, and often the enterprise calls in management consultants like me. We will usually bring together small teams of people from these verticals, and get them working together, quite like in the Venn diagram up top. If it’s a short term project, we’ll call it a design sprint or an ideation sprint. If it’s more permanent, we’ll call it the skunkworks or the innovation division or the new product development team. In reality, all we do is break small chunks from the organisational silos and get them to operate like the product organisation that from way back when…