The Product Management Triangle
A Graphical Model for Discussing Product Management Topics
Product management is a role that most software companies recognize to be critical. Yet, it is surprisingly hard to define “product management” in precise terms. The people who call themselves “product managers” do very different things from organization to organization. They work on different types of products, with different types of teams, within different company structures. The variance in product management positions is so stark that it may seem, from the outside, misleading to refer to the jobs with the same title. In trying to pluck out the common threads that unify all product management jobs, one can end up with language that is too abstract to offer much explanatory value. For example, some accurate, but vague descriptions of product management duties include “fill white space” or “act as the glue” between cross-functional teams.
The ambiguity of the product management role is near to its essence. Within one company, the duties of a product manager can change drastically and quickly. Product managers operate in a fundamentally shifting landscape. Technologies change, team dynamics change, society changes, and new business opportunities unexpectedly emerge. It is the special skill set of a product manager to recognize what these changes mean for their product and for their own role. In that sense, product managers have to rewrite their own job descriptions on a regular basis.
But what is this distinct craft of determining and implementing what a product needs to thrive as the world changes around it? Product managers, among other things, specialize in building bridges between the very general (e.g, a vision for changing the world), and the very specific (e.g., functional requirements for a single button). Ironically, the discipline of product management itself is missing this bridge. We lack a clear framework for connecting the high order duties of product management with the day-to-day realities of execution. I’ve invented graphical model of the product management triangle to be this bridge and provide a foundation for deeper exploration into product management topics.
The Product Network
To set the stage, I need first to describe the milieu in which a product manager operates. The below diagram of The Product Network (figure 1) depicts what I believe to be the fundamental elements of a software product’s context. Many aspects of a product and the people who build or use it are variable, but the below elements always must be present.
At the heart of the product network is the product itself. The Product, in a software company, literally consists of code deployed to an environment where people can access it. All products are connected to three things: developers, users, and a business.
Developers (or engineers) are the people who can write and deploy code. Companies usually have people working on the product that aren’t programming, but the people updating the code are the only folks on the team who are strictly necessary. Developers can perform all company duties (while not always effectively).
Users (or, less broadly, “customers”) are the people who either use the product or might use the product. All products have the goal of being used, on some level, by people.
The Business is the entity that funds and hopes to benefit (e.g. profit) from the product. Whether the organization is for-profit or non-profit, there is a bank with a finite amount of funds.
It is possible for a product to exist in a network with only this exact set of elements. A company can be founded with developers, some form of financial persistence, and a dream of building a user base. But this leaves white space. “White space” connotes missing links in the product network; roles that, if filled, lead to a better functioning product network, and, consequently a more successful product. Specifically, there are three regions of white space indicated by A, B, and C in Figure 2 above.
White Space A
Region A is the white space that exists between developers, the product, and users. Developers and users have different mental models of a product. Developers, on the one hand, can use the product they build, but their mental model is imbued with knowledge of how the product is implemented. Therefore, when considering potential enhancements, hard working, talented engineers have a natural bias towards solutions that are relatively low effort and don’t add ugly complexities to the code base. Users, on the other hand, only know a product through how they interact with it on their screen. They may be able to formulate educated guesses for how it works under the hood, but they don’t know and usually don’t care. Users want to use products because they’re gratifying or solve their problems, regardless of how expensive it was to build or the code’s aesthetics.
While there are engineers who can effectively see a product through the eyes of its users and fill this region of white space, growing businesses require dedicated brains to bridge the divide between users and developers. The role of a designer is the clearest example. Designers are responsible for understanding the mental models of users and devising user interfaces accordingly for developers to implement. But many other dedicated roles fill this this white space: web analytics, marketing, editorial, usability research, information architecture, technical support, community management, and quality assurance, to name a few. Some of these roles are focused on building a development team’s understanding of users, others are focused on communicating more effectively about the product to existing users and attracting potential new ones.
White Space B
Region B is the white space that exists between users, the product, and the business. It’s where the the value that people find using the product is (hopefully) converted to profit (or other benefit) for the business. The complexity in the region is largely dictated by whether
- the users of the product are paying directly for it; or
- user attention is attracted to sell to advertisers.
Examples of #1 are eCommerce or subscription based products. In this case, the duties of white space region B are to effectively use company funds to attract potential customers (e.g., through traditional advertising, search engine marketing, or sales), extract as much revenue as possible from each user, and guide expansion of the product into the most lucrative markets.
Examples of #2 are social networks and media companies. This case is complex because you have to divide the “Users” node in the product network into two branches: (A) the ostensible users of the product (e.g., the person posting on Facebook or reading the New York Times, and (B) the advertisers who pay to reach those users. In this case, the role of players in white space region B is to maximize value to advertisers by influencing the product design to extract information about user preferences, demographics, behaviors, and interests. They also must must market the product to potential advertisers and design pricing models to optimize profits.
There is, perhaps, a third case of venture-backed startups that are trying to grow a user base first and monetize later. In this scenario, there is still a need for people to fill white space B. The duties involve keeping the investors happy and growing vanity metrics (unique users, page views) that signal to the world that the product can be monetized in the future.
White Space C
Region C is the white space that exists between the business, the product, and the developers. This is where the company decides where funds and development effort is focused. At a high level, this entails the formulation and communication of a business vision that can serve as a guiding light for projects (sometimes owned by the CEO). At a low level, this entails the prioritization of specific engineering features, chores, or bug fixes (sometimes owned by a project manager). It also involves answering hard questions around “buy versus build” when it comes to filling technology needs. Region C is where the company translates ideas to execution.
As a reference, I’ve included Figure 3 below to provide
examples of the roles that fill each region of white space. It is by no means a comprehensive list — it is intended to quickly convey the flavor of what each region is all about.
We’ve discussed how regions A, B, and C signify white space between the fundamental elements in the product network. As a company matures, these regions become filled with bands connecting the elements together. A designer may be hired to form a band connecting users and developers or a head of business development may be hired to connect users and the business.
Figure 4. Product management’s areas of responsibility.
As more roles are added, elements in the product network are pulled in different directions. Regions AB, BC, and AC in Figure 4 are the places where the different, sometimes contradictory inputs come together at each product network element. I call each of these spaces “synthesis regions.”
Synthesis Region AB
Synthesis region AB is the place where inputs from white space A must come together with inputs from white space B to form a coherent story for users. The people focused on creating a valuable product for users must understand the needs of the business. And the people tasked with monetizing the product must understand the user experience parameters of the product. I explained above how the complexity of white space region B is dictated by whether
- the users of the product are paying directly for it;
- user attention is attracted to sell to advertisers.
Which of these cases applies has huge implications for the amount of tension in synthesis region AB. The tension in case #1 is relatively low because the same things that make users like the product more will often generate more revenue for the company. By meaningfully improving the product, more people will learn about it and pay for it. In case #2, however, there is an inherent conflict between creating a single product that is valuable to users and advertisers. Ads can degrade the user experience and association with corporate advertisers can erode trust. Conversely, adding efficiencies to the user experience can sometimes reduce ad impressions, hurting the bottom line. It is critical for someone to synthesize the business and user needs to weigh trade-offs and devise product solutions meeting holistic company needs.
The need for synthesis is not limited to handling criss-crossing inputs coming from adjacent white space regions. Sometime multiple inputs from one region require alignment. Even if you were to ignore the business demands of a product from white space region B, there could be conflicting inputs just within white space region A. For example, two people, each responsible for representing user needs, may disagree on how to create an optimal user experience. There is need for an individual to be ultimately responsible for the user experience and reconcile conflicting perspectives between team members.
Synthesis Region BC
Synthesis region BC is the place where bands from white space B must come together with bands from white space C to form a coherent business strategy. This is the region where business ideas are filtered and set into motion through resourcing, prioritization, and incorporation in the business vision. The people filling white space B generate hypotheses for how the product can evolve to grow the business. There is need for someone to own the narrative of the company’s mission, objectives, and capabilities. As new business ideas bubble up, synthesis region BC is about identifying which concepts fit the company’s narrative and which ones don’t. A strong filter will allow the company to focus on development areas that have the best shot at success based on the marketplace and the company’s core competencies.
Synthesis region BC is a primary place where a company’s knowledge is codified. It is essential that, as product hypotheses succeed and fail, the learning is incorporated into the company narrative. While many startups fail through reasons outside their control, a startup, through strong management in region BC, can improve its ability to pick winning product ideas over time.
Synthesis Region AC
Synthesis region AC is the place where bands from white space A must come together with bands from white space C to form a clear, feasible plan for developers. Inputs from white space A explain how a product would ideally behave to benefit end users. Inputs from white space C dictate what is possible to achieve given available resources and competing business priorities. When the two forces come together in region AC, tradeoffs are often required. The ideal solution is often too expensive or time consuming to reasonably build. Synthesis region AC is not about crushing the dreams of idealistic designers — it’s about devising solutions that meet user needs within business parameters.
Synthesis region AC is where the notion of the Minimum Viable Product (MVP) was born. Developing the MVP is about expending the smallest amount of effort possible to enable users to engage with the product in a manner that will validate or invalidate the business hypothesis at hand. A company’s ability to effectively deliver MVPs equates their ability to rapidly iterate, learn, and ultimately discover successful products. Deciding what features should be “in” or “out” of an MVP is is an art. It requires a feel for what really matters to users and how the product is positioned to evolve.
A Product Manager’s Areas of Responsibility
Now that we’ve explored the product network and its various regions, we have the necessary context to describe how product management fits into the puzzle. It is first worthwhile to note what product management does not entail. While some product managers also can wear the hat of a developer, the role of a product manager does not entail touching the product itself; i.e., updating the code — this is the developers’ job. That the person most responsible for a product (the product manager) is not responsible for directly touching the product is a characteristic feature of product management.
So what does a product manager do? We’ve now set the stage for this cryptic answer to have concrete meaning:
A product manager is responsible for the healthy functioning of all the regions in the product network.
This responsibility can be divided into two overarching categories that map directly to the white space and synthesis regions we’ve discussed:
- Product management must recognize and fill the important white space between the elements of the product network; i.e., manage regions A, B, C. If an essential link is missing, the product manager must act as that link or find a way to fill it. Towards this end, a product manager must be able to at least adequately fill all roles surrounding a product, from web analytics, to account management, to project management.
- Product management must synthesize the different inputs effecting each element in the product network; i.e., manage regions AB, BC, and AC. A product manager must own the company’s narrative for each element. Developers need a clear story for what to do. Users need a clear story for how to use the product. The business needs a clear story for the product’s contribution to the world. Through an act of synthesis, the product manager is the author and evangelist of these stories.
These two functions are the yin and yang of product management. Filling white space is additive in nature. By adding missing links to the product network, the product manager adds necessary complexity to the system. Synthesis, conversely, is subtractive. The product manager must understand the complex web of product network inputs and reduce a product to the core elements that meet user, business, and engineering requirements.
I believe the above description of product management’s responsibility is always true, regardless of the company or product scenario. If you’re not performing those two functions, you’re not a “product manager.” However, the description is very general. Within those two categories of responsibility, there is a diverse range of activities performed by product management, depending on the situation. As I stated in the introduction, I’m striving to create a bridge between the general and concrete duties of product management. On my blog,Product Logic, I’ve continued beyond this point to analyze how a company’s scenario translates into a specific set of product management duties that fall into the above two categories.
Go here to continue reading: The Product Management Triangle — the section titled “Example Product Management Scenarios” is where this picks up.
