A commercial software product is not a thing; it’s an evolving relationship between a code base, people, and the business that funds its production. An abstract representation of a product looks something like the figure below — a triangle-shaped graph I call “The Product Triangle.”
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 by 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, 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. Understanding these three types is key to shaping an ecosystem that won’t shed needless baggage on your product.
The Code, The Users, and The Business are the vertices of The Product Triangle. Vertex builders are individuals who excel in developing the node they are attached but know almost nothing about the two other nodes. They are represented as the the colored dots in the figure above.
Vertex #1: The Code
The green dot above represents builders who focused exclusively on The Code vertex. Picture a geeky engineer who embraces deep technical challenges but shows very little interest in the business or user dynamics. Other engineers are the primary audience for their work. 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.
Vertex #2: The Users
The purple dot represents 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 bigger picture of the product.
Vertex #3: The Business
The red dot above represents a vertex builder who focuses 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 health of the business, but without significant knowledge of the code base or user base. Their role is purely operational.
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 (corresponding to the areas delineated in A Map of White Space for Product Managers).
Edge A: The Code <–> The Users
The blue line above represents builders along this edge. They are responsible for forming a strong connection between the implementation model of the software and the mental model of its users. 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: The Essentials of Interaction Design).
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).
Edge B: The Users <–> The Business
The magenta line above represents builders along this edge. Sales or business development are archetypal examples. 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.
Edge C: The Business <–> The Code
The orange line above represents builders along this edge. They dictate or coordinate where 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.
Building Types Are Not Mutually Exclusive
At this point it is worth noting that the types of building are not mutually exclusive. Edge builders are very frequently vertex builders. For example, great developers (who build at the code vertex) can also be talented designers or project managers (edge building). As we’ll see shortly, full-triangle builders can also be edge builders and vertex builders.
Represented as the yellow triangle above, full-triangle builders are able to acquire and concurrently hold in their heads knowledge of the product’s inner workings, user base, and business. Their primary value is understanding how all three vertices relate as a holistic system. This requires synthesizing conflicting inputs from edge builders and vertex builders into clear narratives at each vertex (see Tension in the Product Network). 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 my answer to the Quora question, 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 pattern is for them 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,” I think, because they share the full-triangle nature of the CEO role. Product managers are accountable for the healthy functioning of The Product Triangle (see The Responsibility of Product Management). This requires synthesizing the inputs of edge builders (e.g., design) into clear narratives that are actionable for vertex builders (e.g., engineers).
Product management also requires recognizing and filling white space in the ecosystem around the product; that is, identifying and performing critical functions that are otherwise missing, or enlisting others to do so. To do so, product managers must be capable of performing (or learning to perform) any form of edge building that the product requires. E.g. product managers may need to fill a gap in establishing a business vision, web analytics, or conducting sales demos.
Enlisting the Optimal Combination of Builders
As the above diagram illustrates, when you have all three types of builders operating in the same milieu, the formation becomes complex. The need to reconcile the multitude of perspectives on the product requires elaborate communication.
Here’s a passage from my article, MVPs are built by MVTs (minimum viable teams):
An organization’s growing communication complexity poses a mounting threat to the simplicity of the product’s user experience and code base. Conway’s Law states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” The level of complexity in the product ecosystem is mirrored in the product. Some products scream to the world that they were designed by a committee of individuals who each had to put their own stamp on the product. This is not a recipe for shipping the Minimum Viable Product (MVP).
The framework presented in this post for understanding the three types of builders facilitates interesting strategies for minimizing complexity around the product and, consequently, in the product. Before you have validated the company’s MVP, you should strive to keep the smallest number of people as possible working around the product. An effective way to do this is to hire individuals who can play multiple building roles. In the pre-validation phase of the product, you should try to avoid employing pure vertex or edge builders. Instead, you want to hire edge builders who are also vertex builders (design-savvy engineers), full-triangle builders who are also vertex builders, (e.g., CTOs) or full-triangle builders who are also edge builders (product managers). This will reduce the complexity of communication around the product which leads to a simpler, cheaper-to-build product. This is a strategy for limiting the number of cooks in the kitchen.
When you start trying to scale a validated product to mass audience and usage, you may need to hire pure vertex or edge builders, specialists who can perform clearly defined, yet intellectually deep duties. You’ll need to hire dedicated vertex building roles (e.g., dev ops, back-end engineering, office management, usability research, CFO) or edge building roles (e.g., customer service, testing, sales, project management). But, to preserve the elegancy of your product, hold off on hiring these roles until there is critical demand for them. Think about converting your vertex builders into edge builders or your edge builders into vertex builders before hiring specialists.