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” 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 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.