A Map of White Space for Product Managers
Where to locate critical gaps around your product
Update: Filling white space is just one branch of product manager activities. See my post, How “filling white space” fits into the overall picture of product management.
In reading Facebook (now Instagram) product director Peter Deng’s answer to the Quora question, How Can I Learn to Be a Good Product Manager?, I was struck by this idea:
I once heard an analogy that product management is like filling in the white space between the different roles. I think it’s a really important attitude to have. You are the owner. Either do it or delegate it. If you don’t, no one else will. Product managers are in the service industry; your role is to serve the teams, and no task is too menial or trivial.
The notion of “filling white space” stuck in my head and became one of the primary ways I describe my job as a product manager to those unfamiliar with the role. But what does filling white space really mean? While the term resonates with experienced product managers, is it actionable to those new to the craft? Imagine someone being told this at their first product management job: “Ok, figure out the important stuff nobody else is doing and do it. Fill the white space!” Where does a product manager look for this critical white space that needs filling? This article strives to answer this question by providing a map.
Let’s start by getting clear on what “white space,” in general, refers to. Wikipedia offers this definition:
White space is a process management concept described by Geary A. Rummler and Alan P. Brache in 1991 as the area between the boxes in an organizational chart—where, very often, no one is in charge. It is where important handoffs between functions happen and it is where an organization has the greatest potential for improvement as things often “fall between the cracks” or “disappear into black holes”, resulting in misunderstandings and delays. Managing white space entails improving an organization’s process performance.
This definition is pretty straightforward and aligns with Peter Deng’s explanation above. But what does white space precisely mean in the realm of software/internet product development? Let’s look at the people and entities that are necessary for shipping software. The below graphic is a diagram of what I call “The Product Network” (figure 1), 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 which is why they are the only company role included as fundamental element in the product network. 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 the minimum set of elements in The Product Network. 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” can be conceived of as 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 below.
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.
So now what?
If you want to understand the white space around your product, you can make your own map and act on it. Here’s how to do it:
- Start by printing out the diagram of an empty product network (figure 1).
- For each non-developer team member who contributes in some fashion to the product, draw a line for them in the appropriate white space region (A, B,or C).
- Ask yourself, what crucial links in the network are missing for your product?
- Then, of course, it’s your job to fill the white space, or enlist someone to do what needs to be done.
Here are some examples of white space maps. If you make one for your product, I would love to see it!
Note: I’m expanding and refining the ideas found here on my web site, Product Logic.
