There is not a formula that product builders can apply to create thriving products. This is, in part, because the particulars of product building are dictated heavily by the product’s changing context. A successful strategy for one product may be utterly inappropriate for another. A builder focused on developing an enterprise service needs to behave very differently than a builder who is trying to ignite a social network. There is no formula for translating a product’s context into a “correct” product strategy. A product’s context is tied up in culture, economics, and properties of the physical world; areas that can be deeply studied, but defy absolute human understanding.

Yet, I believe there is an underlying structure to the craft of product building that holds true across all contexts. Illuminating such a framework does not amount to a “how-to” guide. However, the ability to lean on a clear structure can increase the cognitive bandwidth of builders who are grappling with a daunting amount of complexity. As I will illustrate, the structure of product building can be represented in the form of visual diagrams. These visual diagrams allow builders to externalize the characteristics of complex situations that otherwise need to be constantly kept in active memory. The same way a pen and paper can help you solve a complex math problem that you would be otherwise hopeless solving, this visual vocabulary can help you solve problems in product building. The framework allows builders to focus on one component of a problem at a time while not losing orientation in the broader landscape.

This way of articulating the purpose of the visual diagrams and many ideas throughout this piece have been inspired by the architect Christopher Alexander‘s work, Notes on the Synthesis of Form.

1. The Product Triangle

Let’s first describe the environment in which a product builder lives. A product is not a thing; it’s an evolving relationship between a technology, the people who use it (or might use it), and a business that funds its construction. An abstract representation of a product might look something like the figure above — a triangle-shaped graph I call “The Product Triangle.” The Product Triangle is the playing field on which product builders ultimately win or lose.

2. Product Fit & Misfit

A thriving product is technically feasible to develop, loved by its users, and satisfactorily positioned for business stakeholders. When all of these positive elements are present, we can say that the product “fits” its context. Achieving and maintaining this state of product fit in a constantly changing, unpredictable world is the objective of product building.

Each core element in a product’s context also provides an opportunity for “misfit.” A misfitted technology is too expensive to develop or maintain. A misfitted user base is non-existent or too difficult to attain. A misfitted business is failing to meet the expectations of its stakeholders.

There is no absolute way to define what “fit” or “misfit” means for a product. It is up to the product builder to determine which states apply to his or her particular product.

In product triangle diagrams like the ones below, fit at a vertex is represented with a “+” icon, misfit with a “-” icon.

The Permutations of Product Fit & Misfit

To provide more color into “fit” and “misfit” here are the eight possible combinations expressed in everyday terms.

The Roads From Nothing to Product Fit

Product builders start with nothing, misfit at all three vertices (Level 0). They win when they discover fit at each vertex (Level 3). There is not a formula for advancing from Level 0 to Level 3. But the below map, at least, can show you where you are.

3. The Three Types of Product Builders

Everyone that works for a company that makes a product should be regarded as a “builder.” Whether someone writes code or stocks the kitchen, they are contributing to the product directly or indirectly through putting others in the right head space to do so effectively.

While you can divide builders into different categories according to their specialties (engineering, design, sales, human resources, etc.), I believe there is a more fundamental way to conceive of the different types of builders: vertex builders, edge builders, and full-triangle builders.

Vertex Builders

Vertex builders are individuals who excel in developing one corner of the product triangle but know very little about the other two corners.

A T Builder is an individual who focused exclusively on the technology vertex. Picture an engineer who embraces deep technical challenges but shows very little interest in the business or user dynamics. Given their lack of knowledge of anything besides the code base, they need guidance on the most important business or user problems to to solve.

A U Builder is someone who is very knowledgeable about the people the product serves or wants to serve, but knows very little about the product’s capabilities or the business objectives. They could be industry experts or usability researchers whose knowledge needs to be extracted and applied by those with a fuller picture of the product.

B Builders focus exclusively on The Business vertex. Picture an office manager or someone in finance who knows the complete details of the budget but doesn’t know anything about how the product works or its users. These individuals manage and communicate the business vitals, but without significant knowledge of the code base or user base. Their role is purely operational.

Edge Builders

In the terminology of graphs, an “edge” is a line that connects two vertices. Edge builders are individuals who connect two vertices of The Product Triangle. Since The Product Triangle has three edges, there are three locales of edge building defined by the pair of nodes they connect.

TU Builders strive to form a strong connection between the product’s technology (T) and the mental model of its users (U). The archetypal edge builder is a designer. Designers must translate the users’ perspectives into a design that is implementable in code (see Alan Cooper’s discussion of “represented models” in About Face).

Some of these edge builder roles are focused on building a development team’s understanding of users (e.g., web analytics, testing); others are focused on communicating more effectively about the product to existing users (e.g., technical support, community management) or attracting potential new ones (e.g., SEO, marketing).

Sales and business development are archetypal examples of UB Builders. They are responsible for converting users’ engagement with the product into value for the company. Some of these edge builders are focused on monetizing user activities or attention through (e.g.) integrating ads or developing cost structures. Others use company funds to attract new users through avenues such as paid advertising.

BT Builders dictate or coordinate where the company funds and development efforts are focused. At a high level, this entails the formulation and communication of a business vision that can serve as a guiding light for projects. In this respect, many CEOs and product leaders build along this edge. 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. Edge builders in this locale translate ideas into execution.

Full-Triangle Builders

Full-Triangle Builders are able to acquire and concurrently hold in active memory knowledge of the product’s technology, user base, and business. Their primary value is understanding how all three vertices relate as a holistic system.  Full-triangle builders, in this sense, understand “The Product” more deeply than the other types of builders, even if they can’t write a line of code (see Dan Schmidt’s answer to Should a Product Manager know how to code?). CEOs and product managers are archetypal full-triangle builders.

CEOs can play a number of roles in the product triangle. A common CEO pattern is to build at the business vertex in addition to full-triangle building. I.e., they have deep knowledge into managing and communicating the business state of a product and sufficient knowledge of the other vertices to make decisions about how holistic system should operate.

Product managers are regarded as “mini-CEOs” because they share the full-triangle nature of the CEO role. Product managers are accountable for the healthy functioning of The Product Triangle which often entails going deep inside the details of each vertex or edge.

Each company consists of a combination of vertex builders, edge builders, and full-triangle builders.

4. The Two Functions of a Product Building Organization

Some products builders work together on small teams where everyone is hands on the product. Larger organizations consists of direct contributors and managers. In either case, there are two crucial functions that must be collectively performed: filling white space in the product triangle and synthesizing conflicting inputs at each vertex.

Filling White Space

To achieve product fit, a product organization must recognize and fill critical roles that need to be played around the product. This entails enlisting a combination of vertex builders, edge builders and full-triangle builders to perform the functions dictated by the product context. The below diagram lists examples of roles at each region of the product triangle. A small team may employee a handful of full-triangle builders who write code, design the user interface, and run the company. A larger company may hire a large number of specialists to build out each vertex.

Synthesizing Conflicting Inputs

As a product matures, conflicting inputs at each vertex become increasingly complex.  Diverse competing forces create the need for product building organizations to perform the metacognitive task of synthesizing the inputs into coherent, actionable narratives at each vertex.

The red triangle under the technology vertex below is where inputs from the user must come together with inputs from the business to form a clear, feasible plan for developers. Voices from the user vertex explain how a product would ideally behave to benefit users. Voices from the business vertex dictate what is possible to achieve given available resources and competing business priorities. When the two forces come together at the technology vertex, tradeoffs are required. The ideal solution is often too expensive or time consuming to reasonably build. Resolving tensions in this area  is not about crushing the dreams of idealistic designers — it’s about devising solutions that meet user needs within business parameters.

This area of tension 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 test 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.

The red triangle adjacent to the users vertex is the place where inputs from the technology vertex must come together with inputs from business vertex 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. The complexity of tensions is dictated by whether

  1. the users of the product are paying directly for it;
  2. user attention is attracted to sell to advertisers.

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 separate vertices. Sometime multiple inputs from one vertex requires alignment. Even if you were to ignore the business demands of a product,  there could be conflicting perspectives amongst TU edge builders.  For example, two people, each responsible for connecting user needs to the technology, may disagree on how to create an optimal user experience. There is need for full-triangle builder to be ultimately responsible for the user experience and reconcile conflicting perspectives between team members.

The red triangle adjacent tot he business vertex is the place where inputs from the user must come together with technical considerations 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. UB edge builders generate hypotheses for how the product can evolve to grow the business. There is need for a full-triangle builder (whether it’s the CEO, product manager, or CTO) to own the narrative of the company’s mission, objectives, and capabilities. As new business ideas bubble up, synthesis is required to identify 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.

This tension region 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 company with strong full-triangle builders can improve its ability to pick winning product ideas over time.

What you have just read does not tell you how to build a winning product. However, it will help you describe

  1. your product’s context;
  2. where you are in achieving product fit;
  3. the types of product builders working on the problem; and
  4. the functions your organization must perform.

This is just the foundation. In subsequent pieces, I will build on it to go deeper into the structure of product building.

The visual framework utilized in this post is a work in progress. I’m continually refining the system at Product Logic.