The Product Management Triangle

(Also available in Japanese and Russian)

Introduction

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 the 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 must always 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 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 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

1. the users of the product are paying directly for it; or
2. 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.

(March 13th, 2020 update: you can download an updated version of the above diagram as a Keynote template for your own editing purposes).

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.

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

1. the users of the product are paying directly for it;
2. 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 a 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 spending 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:

1. 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.
2. Product management must synthesize the different inputs affecting 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. The remainder of this essay sets out to explain how a company’s scenario translates into a specific set of product management duties that fall into the above two categories.

Example Product Management Scenarios

When I introduced the “product network,” I explained that developers are the only required role in generating software products. Someone needs to ship code. Then, in my discussion of “white space,” I explained that a company must fill a variety of additional roles to thrive delineated by white space regions A, B, and C in the product network. When a  startup gains access to funding, it begins filling in these non-developer roles. If the business achieves growth, the organization scales through adding more and more specialized positions. However, there is significant variance in how companies flesh out the non-developer staff. Some companies may immediately add a product manager. Others may start by adding  design or sales expertise before the first product manager is hired. The order in which a company adds non-developer roles is a function of the domain and skill set of the current team.

Consumer startups are often inclined to hire a dedicated designer (white space A) early on because making a strong visual impression is critical in capturing the attention of web visitors with limited attention spans. In contrast, enterprise startups are more likely to fill business development roles (white space B) out the gate. In this case, product validation is more dependent on proving the service can be sold to organizations based on the core functionality. Exceptional visual design, while always important, may be less critical early in the game.

It should also be noted that, especially for early-stage startups, developers play non-developer roles on top of their programming contributions. It is common to  see a developer act as the designer, project manager, or CEO . The non-programming capabilities of the development team has significant implications for which white space regions a company should focus on filling with non-developers. While some companies would ideally employ a dedicated designer, the need to do so may be less pressing if the development team is reasonably strong in that area.

Each of the following examples are distinguished by the non-developer roles that form links in the product network. While there are many variables that dictate the specifics of product management duties, the structure of the team working around the product has the largest implications on what a product manager does day-to-day.

Example #1: Developers + Designer + Product Manager

Let’s start by considering the scenario of a company that has hired a designer as its first non-developer role. In the visual language I’m establishing, this role is represented as the yellow band labeled “design” through white space region A in figure 8. This is a common pattern since often the first link in the product network that companies want to reinforce is the one that connects users and developers. Before focusing on monetization, many companies want to nail their value proposition for users. As mentioned, especially for consumer startups, a product will get overlooked in the market place if it doesn’t come across strikingly and clearly for new users that only give products seconds of attention before moving on.

So then, let’s say, the company hires a product manager as its second non-developer role. What should a product manager do in this scenario? To reiterate, the two high-level categories of product management duties are

1. Recognize and fill the important white space between the elements of the product network.
2. Synthesize the different inputs  that criss-cross in the three synthesis regions of the product management triangle.

For this example and the others, I will go through what this tangibly means in regards to white space regions A, B, and C and synthesis regions AB, BC, and AC.

Region	Product Management Responsibility
Recognize and fill the important white space between the elements of the product network.
A	The fact that the company has a dedicated designer, in one sense, takes pressure off the product manager in this area. However, a design resource is not a sufficient condition for maintaining a healthy relationship between developers, the product, and users. For a design process to be successful, it must be supported by other roles such as user research or web analytics. The product manager must identify and fill which of these roles they need to fill themselves or get filled. And the skill set of the dedicated designer may not cover the full stack of design needs. For example, the product manager may need to be the information architect providing parameters for a talented visual designer to work within.There is also white space that needs to be filled in region A outside the scope of a traditional design process. For example, the product manager may see the need to perform the duties of search engine optimization (SEO), tech support, or community management.
B	If the company’s model requires showing revenue growth out the gate, region B will be an intense focus area for the product manager in this scenario. Since there are no other employees dedicated to the region, it is completely up to the product manager to map and fill this white space. The presence of critical, unfilled white space in region B is what drives some companies to seek product managers with MBAs. The product manager will be responsible for gauging the revenue potential of the market and develop the business model. But many early stage startups are not focused on monetization — they are focused on proving massive user demand. However, that doesn’t mean the product manager can ignore region B. Whether or not a company is focused on revenue, current or potential investors need to understand the company’s trajectory. Toward that end, the product manager needs to provide the link between users, the product, and the business. This requires translating user engagement wins into metrics that signal business value. In the terminology of lean startup methodology, this means illustrating in quantifiable terms the state of the product’s engine and growth potential. Or if a product hypothesis has failed, the product manager must own the rationale behind pivoting to a new product concept.
C	Region C is a meaty area of product management responsibility in this scenario, and in many others. The product manager must play the critical role of focusing the development team on the projects that most efficiently move the business forward. The product manager must get their hands dirty as the project manager. They must coordinate and specify every engineering task. While the product manager is in the tactical weeds of every small change to the product, he or she also must perform the abstract function of articulating the product’s business trajectory into a clear vision that can inspire and focus the engineering team. And the product manager must also own the middle layer: the product roadmap. Both investors and developers need to see the longer view of which projects are coming down the pipeline, even if the roadmap is subject to change.
Synthesize the different inputs affecting each element in the product network.
AB	The presence of a dedicated designer amplifies the significance of synthesis region AB. With a designer, the company will have a strong voice advocating for user needs. This is, of course, is a positive thing, but sometimes it requires a counter balance. There are many potential product enhancements that may be initiated by a designer that don’t significantly bring the business forward. For example, a designer may want to improve the search user interface, but a product manager may deem that deficiencies in search, while less than ideal, are not constraining growth of the business. In synthesis region AB, the product manager must keep the designer focused on improving the product along dimensions that have the most business impact. And sometimes design energy must be spent on things that hurt the user experience. For example, users won’t like the addition of ads or a paywall, but they are sometimes necessary for the business. Even if you were to ignore potential tension between the design and business goals, a product manager may also need to spend effort synthesizing perspectives on improving the user experience (i.e., multiple inputs from region A). A product manager, on top of everything else, may be wearing the SEO hat. Sometimes, for example, a designer may advocate for a user interface that removes SEO-optimized text from a page. Resolving the tension requires weighing the importance of acquiring new search visitors against the simplicity of the user experience for existing users. The business’s relative focus on growth versus engagement will drive the outcome. Hopefully the type of communications that take place here are not adversarial. Part of the responsibilities of this region are educating the designer on the big picture of the company. A flexible and pragmatic designer will work alongside the product manager in resolving business tensions.
BC	T he product management task of synthesis requires largely diplomacy and communication savvy. The is required to unify team members who have different angles on the product. But in this scenario, the act of synthesis is internal to the product manager. There are no dedicated roles that span region B or C so there aren’t different personalities to get on the same page. Regardless, there can still be tension that the product manager must resolve independently. If a business is struggling or running out of money, deciding which business ideas to resource becomes increasingly hard. Deciding where to place the next bet may keep the product manager up at night. Failing to terminate failed business ideas can drive a company off the cliff. It is critical for the product manager to maintain a clear narrative for the business and only resource projects that fit that narrative.
AC	With a dedicated design role in the mix, a product manager’s responsibility for region AC consists of (A) focusing design energy on the projects that lead to shipping the most impactful code, and (B) balancing design-driven feature development with other engineering priorities. Optimizing the value of design energy involves managing the inputs and outputs of the design process. The product manager must identify which upcoming projects on the roadmap require design attention. For designated projects, the product manager must create clear design parameters and feedback based on their knowledge of the user, business goals, and the current state of the product (which has implications towards the effort level of implementation).  Yet, it is essential to not over constrain the design process. The designer may conceive of product ideas that go beyond the imagination of the product manager. Designers need freedom to deliver game changing work. As the designer delivers mock ups of the product interface, there will inevitably be a design runway beyond what the development team is actively working on. It is not ideal to create a water fall project where the development team is heads down for weeks to implement a design. It is a healthier process for the product manager to identify the most crucial elements of the design for the development team to implement incrementally. The product manager’s goal is to enable as much interspersed learning as possible. This allows design flaws to be discovered quickly and for low value features depicted in designs to not be developed. The product manager must also dictate how aggressively to focus the engineering team’s effort on developing design-driven features. During phases of product discovery, it may make sense to quickly prototype a variety of design directions to validate or invalidate product hypotheses, accruing significant technical debt in the process. However, as a product matures, the product must focus less of the development team’s energy on implementing new designs concepts and more on other initiatives such as performance, security, cross-browser quality, refactoring, and documentation.

 

Example #2: Developers + Designer + Business Development + Product Manager 

Example #2 is differentiated from example #1 by the addition of a dedicated business development role. In this example, some of the internal conflicts a product manager might have felt balancing user and business needs are now external tensions in synthesis region AB. We now have two strong voices: a designer advocating for user needs and a head of biz dev advocating for extracting monetary value from users. As discussed, sometimes these two perspectives easily align and sometimes they don’t. Managing the relationship between the designer and the head of biz dev will be a heavy focus of the product manager – synthesis region AB will be a hot spot in the product network.

The tension in synthesis region AB is largely a product of the strength of the opposite  side of the triangle. Consequently, white space region C will also be hot spot as well. The right business vision will create synergy between user and business value. The product manager will have to filter business ideas from the head of biz dev (in region BC) to maintain a business narrative that aligns the user base and business around a shared goal. This is why marketplaces, for example, have such tremendous upside. As the number of participants grow, user value and revenue increase. Such network effects are the fabric of the internet. The product manager should be relentlessly hunting for the magic formula, the one that keeps the designer and the head of biz dev holding hands, not fighting.

Example #3: Developers + Designer + Business Development + Business Vision + Product Manager

Example #3 includes a third non-developer role, a person who owns the business vision. This role is commonly played by the CEO. A visionary CEO will be the primary person conveying the company’s mission and strategy to the development team. Yet, this doesn’t relieve the product manager of duties in region C. In some sense, it complicates them. The product manager must translate the CEO’s vision into a product roadmap that moves towards the defined north star. When components of the vision become invalidated from a user or business standpoint, the product manager must manage the CEO’s expectations and influence the vision to change accordingly. This sort of white space filling can be described as “managing up.”

Now that we have three non-developer players forming links in the product network (design, biz dev, business vision), we see the overall composition of the product management duties start to shift more towards synthesis and less towards filling white space. A successful product manager in this scenario is characterized by skills in diplomacy, managing through influence, and collaborative problem solving.

Example #4: Fleshed out Product Organization

Example #4 represents a fleshed out product organization. We’ve now moved out of the territory of early stage startups and into the territory of larger startups or mature corporations. The company, in the scenario, employs staff to fill in several bands of white space in regions A, B, C. Imagine an organization of designers, user researchers, tech support, community management, SEO specialists, sales, strategic partnerships, advertising, project management, finance, and executive leadership. In this milieu, product management responsibilities are weighted heavily towards synthesis as opposed to filling white space. A primary challenge of product management is dealing with large amounts of diverse input on the product direction. Each person in the product organization pushes the product in a different direction.  It’s the product managers job to understand the full range of perspectives and weave a coherent narrative for each fundamental element in the product network: the developers, the users, and the business.

The potential for conflict is high in this scenario. With any one region, there is potential for conflict (e.g., in region A, design clashing with SEO). But when forces from neighboring regions clash, toxic political battles ensue. For a product to thrive in these conditions, the product manager must stay ahead of these conflicts, settling them before they start. This requires the product manager to be sensitive to emerging issues and proactively communicate a framework for the direction of the product that synthesizes all view points, gracefully filtering out inputs that do not cohere with the established narrative.

The act of intentionally neglecting the view point of some team members is one of the most interpersonally difficult aspects of product management. But if one has a largely secure team, expressing clear rationale goes a long way. Respect for the product manager disintegrates when his or her decisions are viewed as unprincipled. When clear principles are established, even people whose ideas are filtered out will feel confident that the product is in good hands.

Applications of the Product Management Triangle

I have analyzed the above set of examples to illustrate how the visual vocabulary of the product management triangle can be a valuable tool in describing product management patterns. While the overarching responsibilities of product management are fixed (filling white space and synthesis), the specific duties of product management are a result of how company personnel is configured to cultivate the product.

Adoption of the product management triangle visual vocabulary can make discourse about product management more precise. We can use it to explain, in concrete detail, why many folks performing divergent duties day-to-day all deservedly share the title “product manager.” It also can be used to clarify why good product managers thrive in some contexts but not others. On the one hand, successful startup product managers are cognitively oriented to thrive in environments where they are called upon to fill vast white space. On the other hand, excellent corporate product managers may be less equipped to fill gaps in the product network, but they excel at synthesizing the inputs of a complex political structure. Each product manager should be able to represent their role in an organization through drawing the product management triangle and the bands that connect the product network elements. Through this exercise, a PM can determine where they should be spending their attention — white space regions A, B, C or synthesis regions AB, BC, or AC.

Product manager job requisitions could be made more precise if they were to include a triangle diagram illustrating how the hiring company is configured. This way,  product managers with MBAs could clearly see when a company has substantial white space to fill between users, the product, and the business. And user experience oriented product managers could select opportunities where there is a chasm between users and developers.

The product management triangle can also be used by a product manager to efficiently describe his or her own role, and better understand their personal strengths and weaknesses. By drawing their company configuration in the product triangle and filling out a table like the one I created for example #1 above, a product manager may realize that a certain region is blowing up. E.g., maybe design is clashing with sales (region AB), and this is where a product manager should focus more on synthesis. Or, maybe a product manager could use the product triangle to identify where they’re weak. Maybe they need to brush up on their agile project management principles to restore health to region C.

To conclude, I hope that this essay serves as a launch pad for more concrete discussions about product management. In the future, I intend to write a “how to” piece for each region in the product maangement triangle.

Learn about Double-Loop, a Slack-integrated tool for continually improving your product development process.