The Brain’s Guide to Product Development

The concepts that govern our thought are not just matters of the intellect. They also govern our everyday functioning, down to the most mundane details. Our concepts structure what we perceive, how we get around in the world, and how relate to other people. Our conceptual system thus plays a central role in defining our everyday realities. If we are right in suggesting that our conceptual system is largely metaphorical, then the way we think, what we experience, and we do every day is very much a matter of metaphor.

– George Lakoff, Mark Johnson from Metaphors we Live By

I discovered Gareth Morgan’s book, Images of Organization, on Venkat Rao’s reading list. In the text, Morgan thoroughly explores many possible metaphors through which to understand the workings of a company. For example, companies can be thought of as machines, organisms, brains, or cultures. As a product developer, I’m always searching for frameworks to provide meaning and direction for my work. In this regard, each metaphor Morgan discusses is a goldmine capable of inspiring product vision, mission statements, and roadmaps.

It is often the circumstances around a company that dictate the applicability of one metaphoric lens over another. For example, when the environment around an organization is static, the machine-like elements of a company pop to the foreground. When interactions with the outside world are predictable, corporations can create formulaic routines for optimizing their internal behavior. For example, from Morgan’s book, the below performance checklist applied to workers at a fast food restaurant demonstrates how even human interactions can be assessed in a binary machine-like manner.

Screen Shot 2015-06-19 at 2.09.26 PM Screen Shot 2015-06-19 at 2.09.01 PM

Within a mechanical operation, each employee is thought of like an interchangeable part. You might need some spare parts floating around, but for the most part, when someone leaves, a new worker can be be plugged in with minimal interruption to the system as a whole. While there can be harmful effects on the humans involved, in the right circumstances companies can achieve business success through emulating machines.

The machine metaphor, however, breaks down when considering digital companies operating in the age of the internet. Unlike the relatively static environments of many industrial-age companies, the environment surrounding many of today’s organizations is fraught with compounding uncertainty that I break down into a few categories:

  • The uncertainty inherent in how people interact with software. When you are designing a piece of software, whether it is a consumer web site, app or an enterprise platform, you don’t know in advance which design directions will fail or succeed. Instead, it takes a core group of people close to users to “discover” a working product. You don’t really know what works until you see real people using it.
  • The uncertainty inherent in how internal changes propagate through networks. When you do create a piece of software that clicks with its users, business success is dependent on the ability for the user base to scale to a sufficient number of paying customers. Successful growth tactics are difficult to predict in advance. When developing marketing avenues or viral mechanics, extensive tinkering is necessary to discover messages that stick and spread. As explored in Malcolm Gladwell’s The Tipping Point, seemingly trivial changes can be the difference between virality and insignificance.
  • The uncertainty inherent in external changes. After discovering a product that resonates and scales, maintaining product-market fit requires constant adaptation. The networked system of the internet is ripe for rapid change. Phenomena can emerge and swiftly capture the attention of a large portion of the network. Competitors can quickly appear, yanking away mind share. A search engine algorithm change can destroy a crucial user acquisition channel.

Organizations aspiring to operate like machines involve centralized management creating fixed recipes to dictate the behavior of front-line employees. Due to the environment of uncertainty inherent in the internet, such an approach has become futile. A centralized management team, removed from the front lines, does not know what will make a sustainably successful web site, app, or marketing approach. Instead, the contributors in the trenches must be valued, not as interchangeable parts, but as indispensable sources of knowledge and ideas.


Consequently, we’re seeing today’s organizations emphasize learning as a critical element of their operations. When looking for a model for how companies should aspire to learn, the richest place to turn is the workings of the human brain itself. The brain, of course, is the original learning system. When comparing how companies learn to how brains operate, we can see why many of today’s product development practices are effective. Yet, we also see that companies have only begun to learn how to learn. Using Gareth Morgan’s chapter, Learning and Self-Organization: Organizations as Brains, as my jumping off point, I’m going to explore how patterns of the brain are becoming prevalent in product development practices. Specifically, I’m going to focus on three phenomena:

  1. Rapid adjustments based on external feedback;
  2. Redundancy; and
  3. Double loop learning.

(1) Rapid adjustments based on external feedback

In Images of Organization, Gareth Morgan draws upon cybernetics to explain that “the brain relies on patterns of increasing refinement and not (as man-made machines do) on chains of cause and effect.” The brain relies on negative feedback loops with the external world to optimize actions. For example, “if we shift a boat off course by taking the rudder too far in one direction, we can get back on course  again only moving in the opposite direction.” Even something as basic as picking up an object, Morgan argues, relies on negative feedback loops. He writes:

… when we pick up an object from a table we typically assume that our hands, guided by our eyes, move directly toward the object. Cybernetics suggests not. This action occurs through a process a process of error elimination, whereby deviations between hand and object are reduced at every stage of the process, so that in the end no error remains. We pick up the object by avoiding not picking it up.

Here’s Morgan’s illustration:

Screen Shot 2015-06-19 at 2.51.53 PM

Many of today’s product development techniques mirror the brain’s pattern of repeated adjustment based on feedback from the external world. In agile software development, projects are broken down into small iterations such that the course can be readily adjusted as new information is uncovered. With lean startup methodology, teams create “hypotheses” for how to effectively reach their objectives and run experiments to cheaply validate or invalidate their hypotheses before excessive time and resources are invested. Modern teams strive to rapidly move through build-measure-learn loops.

(2) Redundancy

Morgan emphasizes the importance of redundancy in self-regulating systems like the brain. He writes:

Any system with an ability to self-organize must have a degree of “redundancy,” a kind of excess capacity that can create room for innovation and development to occur. Without redundancy, systems are fixed and completely static.

In the human brain we find this redundancy in the vast networks of connectivity through which each neuron, or nerve cell, is connected with thousands upon thousands of others. This enormous capacity generates considerable evolutionary potential. It allows vast amounts of information process from which thousands of potential patterns of development can emerge, contributing to the brain’s constantly evolving structure, refinement, and intelligence.

A clear example is pair programming, that is, having two engineers simultaneously work on the same task. On the surface, spending two resources on a task instead of one might seem economically wasteful. It’s unclear whether it makes task completion take shorter or longer. But teams have found that pairs, compared to individuals, produce cleaner, more maintainable code with less defects. Furthermore, pair programming prevents critical knowledge from getting isolated within one person’s mind. When only one team member has deep knowledge of an area of the code base, the team becomes vulnerable when the business requires more changes in that area. The one person with specialized knowledge may be absent or stretched thin between other responsibilities. Pairing is a key ingredient in keeping knowledge flowing through an engineering team. Flexibility, quality, creativity, and efficiency are maximized when all engineers are capable of working in all areas of the code base. Hence, the popularity of the job title “Full Stack Developer” where engineering expertise, instead of being divided according to layers of the software (e.g., front-end versus back-end), are duplicated across many developers. In my article, The Three Types of Product Builders, I take things one step further by arguing for the importance of individuals who are proficient in all of the primary areas of building a company; technology, design, and business strategy. When more of a company’s contributors are able to understand the full picture across all traditional job functions, the company has increased their ability to quickly adapt to changing circumstances.

Pair programming is an example of how product development teams create redundancy in their internal process. Split testing (or A/B testing), in contrast, is an example of how teams learn through creating redundancy in their external outputs. With split testing, teams produce redundant versions of the same page and distribute web traffic such that some portion goes to each version. While the redundant versions of the page serve the same overall purpose, each site instance contains variance along the lines of content or design. This allows the team to discover which page elements perform the best according to company objectives. For examples, product development teams can use A/B testing to determine which home page layout leads to the highest click through rate or which labeling of the buy button (e.g., “buy now” vs “check price”) leads to the highest conversion rate.

Both pair programming and split testing mirror patterns of parallel processing prevalent in the brain. Morgan writes:

A lot of the brain’s activity seems to be completely random and characterized by a massive amount of distributed and parallel information processing. At any one time many parts of the brain may be involved with the same activity or information. This redundancy allows initiatives to be generated from many locations at once, reducing dependence on the activities of any single location. The process generates the multiple, competing “drafts” of intelligence from which an evolving pattern eventually emerges. The redundancy reflected in this system of parallel process is vital in generating a range of potential outcomes, in coping with error, and in contributing to the brain’s flexibility, creativity, and adaptiveness.

Teams that employ redundancy understand the value of learning and strive to avoid the predicament of trapping knowledge in the minds of few. Furthermore, they recognize that their assumptions about how to reach objectives are only hypotheses that need to be examined and tested. Creating redundancy is a key technique in discovering and spreading surprising, counter-intuitive knowledge about what works and what doesn’t.

(3) Double loop learning

It is critical for today’s organizations to learn how to more effectively reach their objectives. However, it is often the case that the objectives themselves are flawed from the outset or due to external change. When an organization’s operating norms become misaligned with its environment, as Morgan explains, “the intelligence of the system breaks down, because the process of negative feedback ends up trying to maintain an inappropriate pattern of behavior. Morgan continues:

… More complex cybernetic systems, such as the human brain or advanced computers, have the capacity … to detect and correct errors in operating norms, thereby influencing the standards that guide their detailed operations.

It is this self-questioning ability that underpins the activities of systems that are able to learn to learn and self-organize. The essential difference between these two types of learning is identified in terms of a distinction between “single-loop” and “double-loop” learning.

Morgan’s illustration:

Screen Shot 2015-06-20 at 1.38.55 PM Screen Shot 2015-06-20 at 1.39.17 PM

We see some of today’s product development teams embracing double-loop learning. In agile software development, teams routinely question their own operating norms in the form of project “retrospectives.” In retrospectives, teams ask themselves the question, “What’s going well or not well in our current process? How should our process change next time?” Retrospectives allow organizations to identify and correct pathologies in their alignment.

Perhaps the most iconic embodiment of double-loop learning is “the pivot.” Lean startup teams iteratively formulate and test hypotheses for how to achieve company objectives. After a hypotheses fails, sophisticated teams don’t blindly move on to the next tactic. Instead, they question whether their overall objective is tenable. When a larger strategic direction is deemed a failure, companies pivot to a new direction. Many of today’s most successful companies pivoted before landing on a winning proposition. Without double-loop learning, they would no longer be in business.


While we’re seeing an increasing number of the brain’s patterns emerge in product development practices, there are still areas where learning capacities are severely limited as if there is a legion in the collective brain of an organization. A primary example is the phenomenon of corporate amnesia. As investments in learning continue to rise, the cost of lost or poorly leveraged knowledge rises. The forms of organizational memory loss mirror the types of amnesia occurring in the brain. According to Wikipedia,

There are two main types of amnesia: retrograde amnesia and anterograde amnesia. Retrograde amnesia is the inability to retrieve information that was acquired before a particular date, usually the date of an accident or operation. In some cases the memory loss can extend back decades, while in others the person may lose only a few months of memory. Anterograde amnesia is the inability to transfer new information from the short-term store into the long-term store. People with this type of amnesia cannot remember things for long periods of time.

Retrograde amnesia occurs in organizations when previous employees do not pass on their knowledge when they depart. In software development, it can take years of experience crafting a product to develop a sufficiently nuanced understanding of what works and what doesn’t. When the people with direct experience of previous launches leave, the new people that take over have to start from almost zero in building their understanding of the product. The problem is only exacerbated with increases to labor market flexibility. In tech we’re seeing trends in people holding a position for less than a couple years before moving to the next opportunity. While this practice may benefit the individuals, organizations can struggle when accumulated knowledge repeatedly walks out he door.

While individuals working on a product over a period time acquire valuable knowledge, the new information they discover is commonly not transferred to long-term memory that is actionable to the whole organization. If you compare an organization to a brain, this form of failed memory transfer is akin to anterograde amnesia. Consequently we see teams failing to apply lessons learned by other teams, we see managers failing to adjust strategy when new information comes in from the front lines, and we see individual contributors fail to change their tactics when company leadership uncovers a change to the overall business landscape.

While companies try to combat amnesia through knowledge management solutions like intranets and wikis, these solutions are too manual to comprehensively keep up and are subject to future misinterpretations. I liken today’s organizations to the amnesiac main character in the film Memento. To solve the murder of his wife, he tries compensate for his amnesia by tattooing clues for his future self all over his body. These “clues” lead him to pursue the wrong suspect.

Healthy brains are organized such that functioning is distributed. Morgan characterizes this phenomenon as the holographic quality of the brain. He writes:

Holography uses lensless cameras to record information in a way that stores the whole in all of the parts. One of the interesting features is that, if the holographic plate recording the information is broken, any single piece can be used to reconstruct the entire image. Everything is enfolded in everything else, just as if we were able to throw a pebble into a pond and see the whole pond and all the waves, ripples, and drops of water generated by the splash in each and every one of the drops of water.

Holography demonstrates that it is possible to create processes where the whole can be encoded in all of the parts so that each and every part represents the whole. Neuroscientist Karl Pribram has suggested that the the brain functions in the accordance with holographic principles: that memory is distributed throughout the brain and therefore can be reconstituted from any of the parts. If he is correct, this may explain why the rats in Karl Lashley’s experiments were able to function reasonably well even when major portions of their brain had been removed.

While functioning may be distributed across the brain, specific regions of the brain are still specialized. Morgan excitedly points out the paradox that “The brain, it seems, is both holographic and specialized!” He continues:

This paradox is clearly illustrated in the results of “split brain” research, which shows how the brain’s right hemisphere plays a dominant role in creative, intuitive, emotional, acoustic, and pattern recognition functions and controls the left side of the body. The left hemisphere is more involved with rational, analytic, reductive, linguistic, visual, and verbal functions while controlling the right side of the body. The is undoubtedly a high degree of specialization on the part of each hemisphere, but both are always involved in any given activity. It is just that one hemisphere seems to be more active or dominant than the other as different functions are brought into play.

Traditional organizations are attracted to the “specialized” side of the holographic/specialized paradox while neglecting the “holographic” side. We see commonly see companies organized into groups according to their preconceived, narrow job responsibility; engineering, marketing, design, sales, etc.. As Venkat Rao explains in his essay The Amazing, Shrinking Org Chart, the classic org chart model is becoming deficient as preconceived structures fail to keep up with a dynamically changing environment. Rao argues that tools like Slack demonstrate a new way for companies to organize around order that emerges naturally out of the actual work being done. By using Slack, a team increases their ability to achieve a balance between holographic and specialized functioning. Slack makes it easier for each of an organization’s employees to dip into the river of what others are working on.


While there are promising tools and new organizational design philosophies like holacracy, most companies have not broken free from machine-like ways of operating. When comparing the operations of product development teams to the workings of the brain, we find areas where organizations are severely limited. However, each limitation we identify provides a clearly delineated opportunity for improvement. The brain serves as a model that the product development community can aspire to recreate if they want to maximize their learning potential.

Personally, I’ve found the brain to be an inspiring north star for product ideas. My project, DoubleLoop, aspires to cure organizational amnesia through recording a history of a company’s past website launches, striving to dramatically shorten the time required for an organization to discover and capitalize on opportunities moving forward. As product developers, we’ve only begun to learn how to learn. I expect we’re going to continue to see a new era of tools, organizing principles, and product development methodologies that will bring our operations closer to that of the brain. If you’re looking for product vision, look inward.

The Rise of Redundancy

In common corporate discourse it is taken as a given that redundancy is bad. It’s bad, people think, for a company to have two people perform the same job function or to have two similar products undifferentiated in the market place. Redundancy, so this line of thought goes, is economic waste that must be eliminated in the form of lay offs or budget cuts. This way of thinking reflects an expectation, bolstered by the industrial age, that organizations should behave like machines. Each employee is thought of like an interchangeable part. Yes, you might need some spare parts floating around. But for the most part, when someone leaves, a new worker can be be plugged in with minimal interruption to the system as a whole. When the environment around an organization is static, the machine-like elements of a company pop to the foreground. When interactions with the outside world are predictable, corporations can create formulaic routines for optimizing their internal behavior.

The machine metaphor, however, breaks down when considering digital companies operating in the age of the internet. Unlike the relatively static environments of many industrial-age companies, the environment surrounding many of today’s organizations is fraught with compounding uncertainty:

  • The uncertainty inherent in how people interact with software. When you are designing a piece of software, whether it is a consumer web site, app or an enterprise platform, you don’t know in advance which design directions will fail or succeed. Instead, it takes a core group of people close to users to “discover” a working product. You don’t really know what works until you see real people using it.
  • The uncertainty inherent in how internal changes propagate through networks. When you do create a piece of software that clicks with its users, business success is dependent on the ability for the user base to scale to a sufficient number of paying customers. Successful growth tactics are difficult to predict in advance. When developing marketing avenues or viral mechanics, extensive tinkering is necessary to discover messages that stick and spread. As explored in Malcolm Gladwell’s The Tipping Point, seemingly trivial changes can be the difference between virality and invisibility.
  • The uncertainty inherent in external changes. After discovering a product that resonates and scales, maintaining product-market fit requires constant adaptation. The networked system of the internet is ripe for rapid change. Phenomena can emerge and swiftly capture the attention of a large portion of the network. Competitors can quickly appear, yanking away mind share. A search engine algorithm change can destroy a crucial user acquisition channel.

Organizations aspiring to operate like machines involve centralized management creating fixed recipes to dictate the behavior of front-line employees. Due to the environment of uncertainty inherent in the internet, such an approach is becoming increasingly flawed. A centralized management team, removed from the front lines, does not know in detail what will make a sustainably successful web site, app, or marketing approach. Instead, the creators on the front-lines must be valued, not as interchangeable parts, but as sources of knowledge and ideas.

Consequently, we’re seeing today’s organizations emphasize learning as a critical element of their processes. When looking for a metaphor for how companies should aspire to learn, the richest place to turn is the human brain itself. In his book Images of Organization [1986], Gareth Morgan explores how the brain can used as a model for how organizations learn and self-organize. While Morgan identifies many patterns of brain function that are applicable to organizations, “redundancy,” in particular caught my attention due to the diversity in how it’s manifested in today’s companies. Morgan writes:

Any system with an ability to self-organize must have a degree of “redundancy,” a kind of excess capacity that can create room for innovation and development to occur. Without redundancy, systems are fixed and completely static.

In the human brain we find this redundancy in the vast networks of connectivity through which each neuron, or nerve cell, is connected with thousands upon thousands of others. This enormous capacity generates considerable evolutionary potential. It all vast amounts of information process from which thousands of potential patterns of development can emerge, contributing to the brain’s constantly evolving structure, refinement, and intelligence.

A clear example is pair programming, that is, having two engineers simultaneously work on the same task. On the surface, spending two resources on a task instead of one might seem economically wasteful. It’s unclear whether it makes task completion take shorter or longer. But teams have found that pairs, compared to individuals, produce cleaner, more maintainable code with less defects. Furthermore, pair programming prevents critical knowledge from getting isolated within one person’s mind. When only one team member has deep knowledge of an area of the code base, the team becomes vulnerable when the business requires more changes in that area. The one person with specialized knowledge may be absent or stretched thin between other responsibilities. Pairing is a key ingredient in keeping knowledge flowing through an engineering team. Flexibility, quality, creativity, and efficiency are maximized when all engnieers are capable of working in all areas of the code base.

Pair programming is an example of how product development teams create redundancy in their internal process. Split testing (or A/B testing), in contrast, is an example of how teams learn through creating redundancy in their external outputs. With split testing, teams produce redundant versions of the same page and distribute web traffic such that some portion goes to each version. While the redundant versions of the page serve the same overall purpose, each site instance contains variance along the lines of content or design. This allows the team to discover which page elements perform the best according to company objectives. For examples, product development teams can use A/B testing to determine which home page layout leads to the highest click through rate or which labeling of the buy button (e.g., “buy now” vs “check price”) leads to the highest conversion rate.

Both pair programming and split testing mirror patterns of parallel processing prevalent in the brain. Morgan writes:

A lot of the brain’s activity seems to be completely random and characterized by a massive amount of distributed and parallel information processing. At any one time many parts of the brain may be involved with the same activity or information. This redundancy allows initiatives to be generated from many locations at once, reducing dependence on the activities of any single location. The process generates the multiple, competing “drafts” of intelligence from which an evolving pattern eventually emerges. The redundancy reflected in this system of parallel process is vital in generating a range of potential outcomes, in coping with error, and in contributing to the brain’s flexibility, creativity, and adaptiveness.

Teams that employ redundancy show a respect for the uncertainty of their external environment. They recognize that their assumptions about how to reach objectives are only hypotheses that need to be examined and tested. Creating redundancy is a key technique in discovering surprising, counter-intuitive knowledge about what works and what doesn’t. These “secrets,” as Peter Thiel argues, are instrumental in achieving explosive business victory.

Two of my latest Quora answers with good traction

For those of you who follow this blog and not my Quora answers, here are two of my latest Quora answers on product management:

I haven’t published much else in a while because I’ve been working on a new branch of writing that explores how the brain can be used as a model for how companies should aspire to learn. The first piece will come soon.

A System for Designing Startup Teams

In an abstract sense, the goal of product building is clear: you must find fit between a technology, customer base, and a business. As Tim Brown, CEO of IDEO puts it (according to the Design Thinking Wikipedia page), you must “[match] people’s needs with what is technologically feasible and viable as a business strategy.” A representation of product builder victory might look something like this:

EdgeFit
Figure 1

It’s possible that, after a brilliant product idea flashes inside a builder’s head, clear execution steps validate the concept, quickly leading to staggering success: the product ships, people love it, and it monetizes with huge profits! As many of us know, this is not how things usually unfold. A product is tied up in the unpredictability of human behavior, economics, technological change, and culture. Even finding fit between two of the three pillars of a product (technology, users, business) is fraught with severe uncertainty. It’s hard to create a technology that people actually want to integrate into their lives. Even if you do, when you try to monetize the product, you may damage the user experience that made it successful in the first place. If you can monetize, you may not be able to recoup the cost of development. Trying to create a viable product can make you feel like a cat chasing it’s own tail. Striving for fit in one product dimension can make you lose fit in another.

Agile software development, Eric Ries’ lean startup methodology, and Marty Cagan’s treatment of product discovery provide principles that help product teams confront the reality that they cannot predict the future of their product. But sometimes the problem is the team itself. Before a product has been validated in the marketplace, it is essential for the people building it to be supremely adaptive to external signal. The number of pivots, big or small, a startup has time to make before running out of money can be matter of life and death (in the narrow startup sense).

Company founders start out hands-on building their product, but soon they must design their team as well.  Hiring a group of talented contributors who embrace iterative development is a necessary, but insufficient condition for maximizing company pivot speed. Some teams are able to collectively process and react to new inputs faster than other equally talented teams. In this article, I explain why this is the case and I offer a few principles for building a startup with maximum pivot speed.


To dig in, let’s look at an example team structure, illustrated below.

n_team
Figure 2

In the diagram,  T = Technology, U = Users, and B = Business. As illustrated through figure 1 above, a startup’s goal is to achieve fit amongst these three product vertices. Each black circle in the diagram represents a class of product builder. Their responsibilities are indicated by the set of product vertices they touch, through direct contributions or others that they manage (formally or informally).

  • TUB. TUB builders engage with all three vertices of the product triangle, the technology, user base, and business. Example TUB roles are CEO, CTO, business development, or product manager. In the team organization depicted in figure 2, they are not hands-on responsible for the technology, user base, or business. They instead operate at meta-level, directing the individual contributors. As we will see later, in other team configurations, TUBs play hands-on roles.
  • T. Ts are responsible for one thing: engineering. They have little interest in the users or business — they embrace solving hard technical problems. However, they need a TUB to filter their inputs and point them towards the right problem to solve. Otherwise they may gravitate to the most fascinating problem, regardless of its user or business value.
  • U. These folks engage with the company’s current or potential users. They are user researchers and industry experts. TUBs must extract their knowledge and feed it to the rest of the company.
  • B. B’s are responsible for managing the health of the company financials and operation, but know little about the product’s technology or user base. They have roles like CFO, office manager, or HR.
  • TU. TUs are the most diverse class of product builders. They are responsible for connecting the technology and user base. The archetypal TU is a designer who devises the technology’s user interface. TUs also include engineers who rapidly prototype products concepts, QA testers who validate that the technology performs for users as expected, data scientists who inform the product direction with analytics, and marketers who engage current and potential users. The list goes on. Like all other classes of product builder, it is important for TUs to be directed by TUBs since a TUB’s knowledge of the business is required to assess trade-offs between user and technical considerations.
  • UB. UBs are responsible for converting user engagement with the product into value for the company (e.g., sales) or using company funds to acquire new users (e.g., through traditional advertising or search engine marketing). UBs can clash with TUs as product changes necessary for monetization can be at odds with the user experience. A TUB’s big picture of the product is required to reconcile the tension through balancing revenue and user demands.
  • BT. BT builders are responsible for efficient, cost-effective execution including disciplines like project management and engineering management. BTs must define clear development iterations and answer “buy versus build” questions. BT building needs insight from TUBs to imbue prioritization with knowledge of the user base.

As I explain in A Visual Vocabulary for Product Building, I call TUBs full-triangle builders because they engage with all three vertices in the product triangle. I call Ts, Us, and Bs vertex builders because they each touch just one vertex. I call TUs, UBs, and BTs edge builders because they connect two vertices (an “edge” in graph theory is a line that connects two nodes).

Now, the stage is set to explain the first principle of designing a startup team:

Principle #1: A team organization that employs full-triangle, edge, and vertex builders is optimal for validated products, but sub-optimal for unvalidated products.

A company that is scaling a validated product (in Peter Thiel’s vernacular, going from 1 to n),  should employ individuals from all three builder classes (full-triangle, edge, and vertex). After early team members nail the formula to dominating a market, they can institutionalize their knowledge through the creation of specialized roles that fit together like puzzle pieces. A startup with a validated product already has a working engine — their new goal is to pour gasoline into it (lean startup speak for “grow”) which requires hiring more people who can fit into the existing system.  For example, after a team discovers  a product that people love, will pay for, and is cost-effective to develop, they can grow through enlisting a sales persons (UB edge builders) and engineers who specialize in scaling infrastructure to handle increased traffic (T vertex builders).

A complex organizational structure is often necessary for dependable growth of a validated product. Such a product doesn’t need a pivot for the company to profit greatly for an extended period, so pivot speed is not an important quality of the team. Such an organization should be resistant to rapid, fundamental change to avoid breaking the working engine crafted by the company’s creators. If one part of the external context around a product changes, with a properly fleshed out organization, it is unlikely to send the whole company into an anxious state of overreaction. E.g., a change to a product’s technical landscape (e.g., a service provider emerges or disappears) could be handled entirely by T builders with only requiring minimal involvement from TUs, BTs, and TUB.

It is worth noting, however, that when a company inevitably starts to decline or faces an emergent threat to its core business, the necessarily complex team configuration will contribute to its demise. If the CEO (or other TUB) wants to fundamentally change the product direction, time-intensive labor will be required to point all team members toward the new north star, and they will likely be the wrong team to execute the new vision. This is why large companies are forced to spin off innovation labs, sub-organisms that can more quickly twist and turn their way to validating a new product concept.

While all companies come and go, those that fail to maximize their team’s pivot speed multiply their odds of never getting off the ground. While lean startup thinking has helped cure an entrepreneur’s temptation to prematurely invest in ideas that are based on unproven assumptions, an analogous cure has not (to my knowledge) been issued in the realm of startup team design.

A company’s founders, confident in their product vision, may apply their available funds to quickly build out the organization of their dream company. However, building a complex team before achieving technology/user/business fit comes with with the price of reducing the team’s pivot speed. Let’s contrast the following two startup team configurations.

simple_complex
Figure 3

As I’ve explained, the mature organization employs full-triangle builders, edge builders, and vertex builders. The young organization, in contrast, employs just one class: full-triangle builders (TUBs). In this configuration, all team members each understand all vertices of the product, the technology, the user base, and the business. On the surface, a team of TUBs might look many other teams. The founders may hold titles like CEO, CTO, designer, and product manager. The CEO may be a bit more business-focused, the CTO tech-focused, and the designer user-focused. However, the differentiator is that each full-triangle builder, unlike a more specialized contributor, is able to go deep inside one product vertex while considering the other two vertices. The full-triangle engineer is able to write code while thinking about user and business drivers. The full-triangle CEO is able to make business decisions reflecting intimate knowledge of the technology and user base. The full-triangle designer is able to choose a design approach that weighs feasibility and monetization potential. The product manager is able to connect all product vertices and fill white space that would normally be handled by specialists.

As stated in the principle above, a complex organization with full-triangle, edge, and vertex builders is sub-optimal for unvalidated products. Unlike a team working on a validated a product, an early stage startup team has not yet discovered holistic fit between the technology, user base, and business. In the pre-fit stage of product building, the company direction must constantly adapt as new features of the product’s landscape appear. The uncovering of new information can come by way of failed launches or discoveries about the external circumstances surrounding the product. In a mature organization, the TUBs are not on the front lines of the product so they are unlikely to be the first to receive external signal. Thus, for the company to pivot in any fashion, the first step must always be for an edge or vertex builder to convince a TUB that something is amiss. This link is a possible failure point because the individual exposed to new information, with their relatively confined knowledge of the product, may not recognize game-changing information or be able to communicate it effectively. When the TUB in charge is convinced that change is necessary, they need to communicate it to the whole company. And since each edge and vertex builder is focused only on their area, the communication required must be extensive. For example, a designer working on edge TU may lack intuition for how a change to the business climate effects their daily job. The TUB must spin the cycles, with each branch of the organization, to make the implications of a direction shift clear. This takes time. The pivotability of a mature organization is limited because of the number of communication steps required to make a decisive move and the high number of failure points along the way.

In a mature organization, each group of product builders speaks their own language (engineering speak, marketing speak, sales speak, finance speak, etc.) such that TUBs (e.g., product managers) are required to translate between languages. In contrast, a team of full-triangle builders, while versed in domain-specific vernaculars, are all able to speak a common language. Each contributor can autonomously digest and interpret the full implications of new discoveries about the product and efficiently communicate amongst each other. This leads to high-bandwidth communication and rapid iterations. As information is uncovered, full-triangle teams immediately understand the implications and act. While a mature organization can be blocked until a TUB can precisely communicate a new direction, a young organization can develop a prototype of v2 the next day. This can be encapsulated with the following principle.

Principle #2: Startups just getting off the ground should strive to exclusively employ full-triangle builders; that is, contributors who understand technology, users, and business.

So how does a healthy startup grow from youth to maturity? I theorize that the trajectory should look something like this.

Evolution3
Figure 4

In Peter Thiel’s terminology in Zero to One, a startup that is building something truly new is going from 0 to 1 (as the book title says). A startup that is scaling a validated concept is going from 1 to N. As you can see in figure 4, I’m using Thiel’s framework to delineate the evolution of a product. However, I’ve added 1/3 and 2/3 between 0 and 1. The idea is that, when a startup succeeds at one of the three edges of a product, they’ve advanced a clear level. For example, a startup that begins by validating demand for their envisioned technology reaches 1/3 — fit at TU. When they prove they can efficiently ship their technology they reach 2/3 — fit at TU and BT. When they prove they can profit from the technology while maintaining fit elsewhere, they’re at 1 — fit at all three vertices, TU, BT, and UB. The company goes from 1 to N when they scale the technology, user base, and business.

At level 0, as I’ve argued, a startup should strive to employ only full-triangle builders who can grasp all dimensions of the product. A strategy question that startups face immediately is which product edge to attack first. Enabled by large funding rounds, a common silicon valley pattern is for companies to focus first on building a user base before worrying about monetization — this is the TU first approach. After a company commits to winning an edge, only then does it makes sense to hire builders focused exclusively on this edge. In the TU first approach, the first edge builder hire is often a dedicated designer. This individual will be obsessed with making users love the product — they shouldn’t concern themselves with business implications. More TU edge builders may be necessary. To find resonance with a user base, the company may also hire a data scientist, front end developer, QA tester, user experience focused product manager, community manager, etc.. When the TUBs leading the product feel they have achieved fit between technology and users (they’ve reached 1/3), they may decide to streamline the development process through hiring an edge builder along BT like a business-conscious engineering manager. This person can help the development operation move efficiently, taking best advantage of company funds and resources. After the company has reached 2/3 by cost-effectively shipping product, on their way to 1, they may need to start hiring UB builders such as business development or sales to translate user engagement into value for the company.

As figure 4 illustrates, the above example describes just one of the six paths from 0 to 1. For example, an enterprise startup may want to prove they can sell a product before writing a line of code.  But regardless of path, the following principle applies.

Principle #3: startups should be explicit about which product edge(s) they are attacking and not hire any edge builders who are not focused on those edges.

For example, before a startup has reached 1/3, they shouldn’t hire a dedicated designer (TU edge builder) and a dedicated sales person (UB edge builder).  While TUBs need to obsess about how all product edges will come together, they will only complicate their situation by hiring specialists at each edge before solving one edge first. It will be challenging enough for the company to succeed at either TU or UB in isolation. A startup shouldn’t make themselves figure out how TU and UB come together cohesively before they know what at least one of the edges looks like alone.

When the company wins one edge and moves onto the next, a tricky part of the challenge is to resolve the tension that emerges at the common vertex. A classic example is the conflict that emerges when a company tries to monetize a popular web site through adding advertisements. The monetization method can undermine the user experience, threatening to regress TU from fit back to misfit. A primary responsibility of TUBs (e.g., CEOs, product managers) is to reconcile such conflicts. My article Tension in the Product Network lays out the various forms of conflict that emerge at each vertex.

Startups are tempted to hire all talented engineers that come their way which leads to the dangerous trap of prematurely hiring vertex builders, engineers who lack customer and business understanding. Regardless of how technically gifted these individuals are, their presence reduces team pivot speed. The younger the startup, the more limiting vertex builders can be. Vertex builders need to be instructed where they can add value since they lack necessary product perspective. This is a slow communication process. Furthermore, after a company employs at least two sets of edge builders (e.g., design and sales), it is possible that vertex builders can receive conflicting instructions based on the biases of each edge. The vertex builder then needs to instigate the cumbersome procedure of bubbling up the conflict to the managing TUB who will need to devise a solution for aligning all parties. Such tensions can be resolved more efficiently without vertex builders in the mix at all. Hence, the following principle.

Principle #4: start up teams should avoid hiring vertex builders until they have reached 1, fit at all three edges.

When a team of full-triangle builders and edge builders collaborate to find fit at all three product edge, the product is at 1. When the company transitions from figuring out what works to scaling what works, vertex builders should be inserted to sure up the connections between each edge. When TUBs have reconciled how all edges come together, then vertex builders get to work at helping the product reach its maximum potential.

Testing Product Fit Without a Product

You can do a great deal to test market fit without building an actual product. However, until you’ve shipped something real, you can’t be certain you will have success. You could find yourself at a dead end.

To elaborate, I’d like to parse what “product/market fit” means. PMF requires a product that’s technically feasible to develop, loved by users, and meets the revenue growth expectations of its business stakeholders. An abstract representation of a fitted product looks something like this (where the “+” at each vertex indicates fit):

Screen Shot 2014-09-19 at 1.58.17 PM
The opposite of fit is misfit. A misfitted product is too expensive (or impossible) to develop, not valuable for a sufficiently large customer base, or lacks sufficient revenue growth. A completely misfitted product looks like this (where the “-” at each vertex indicates misfit):

Screen Shot 2014-09-19 at 1.57.57 PM
Product builders start with nothing, misfit at all three vertices (Level 0). They succeed 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 and the possible roads to victory.

fitroads_bare
I’ve circled in red above the farthest point a product builder can get without building an actual product. This is the “vaporware” scenario. You can sell a product without building it. This entails communicating the intended capabilities of your product to potential customers and convincing them to actually buy it before the tangible product exists. It can be hard to persuade people to buy something they can’t touch, but with sufficient sales technique, it’s doable.

This product building approach has its advantages. Building something with validated demand can be safer than investing in a technology that possibly nobody will use and/or pay for.

However, the success of this approach rests squarely on the assumption that the product builder can find a road from level 3 to level 4 in the above diagram. This requires that

(A) it will be economically feasible to deliver the product, and

(B) people will successfully interact with the product when it’s real.

Both requirements can break down leaving the product builder at a dead end.

An extreme example of requirement A breaking down would occur if you were selling time travel. Validating that there is a market for time travel is relatively worthless, assuming you can’t deliver on the proposition. A less extreme example would be an airline business. It’s on thing to prove that there is a big market for air travel, but another to prove that you can deliver profitably. You won’t know if you have a winning equation until you actually execute the service.

Requirement B breaks down when your customers are subject to an attitude-behavior gap; that is, when users may think of themselves as wanting a service that they won’t actually use in their real life. YC’s notion of “sitcom startup ideas” (see How to Get Startup Ideas) can fall in this category. To borrow one of Paul Graham’s examples, many people who care about their pets would say they would use a social network for pet owners, but few actually would in reality.

That said, sometimes discovering what people want and will pay for is the hard part of product building while developing the actual product can come relatively easy when the technical components are predictable. After, you’ve sold your vaporware, sometimes you can deliver on the value proposition and enjoy a thriving business.

A Visual Vocabulary for Product Building

(Also available in Japanese)

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

EmptyTriangle

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.

ProductFit

The Permutations of Product Fit & Misfit

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

Technology User Base Business Description
Misfit Misfit Misfit Nothing. Where product building begins.
Fit Misfit Misfit A genius technical solution that is searching for a problem. Think Pied Piper from HBO’s Silicon Valley show.
Misfit Fit Misfit Validated user demand with no product or business to satisfy it. Think a launchrock landing page with tons of signups but no actual product to use.
Misfit Misfit Fit A business model with no technology or user value proposition. The fantasy of an MBA.
Fit Fit Misfit A technology that users love, but it’s not profitable to build. The airline business.
Fit Misfit Fit A brilliant technology that some people pay for, but not enough to take off. Or a two-sided marketplace that never gets over the tipping point.
Misfit Fit Fit Vaporware that’s been successfully sold, but not delivered
Fit Fit Fit A thriving product that’s achieved equilibrium with technology, users, and a business.

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.

FitRoads_bare


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.

T Builders

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

U Builders

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 BuildersB 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

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: 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).

UB BuildersSales 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

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 my answer to the Quora question, Should a product manager know how to code?). CEOs and product managers are archetypal full-triangle builders.

FullTriangle

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.

CompanyBuilders


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

WhiteSpace

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.

T Tension

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 an art. It requires a feel for what really matters to users and how the product is positioned to evolve.

U Tension

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. Sometimes multiple inputs from one vertex require 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 a need for full-triangle builder to be ultimately responsible for the user experience and reconcile conflicting perspectives between team members.

B Tension

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

Three Types of Product Builders: Vertex Builders, Edge Builders, and Full-Triangle Builders

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

triangle_empty

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.


Vertex Builders

triangle_vertex

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.


Edge Builders

 triangle_edge

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.


Full-Triangle Builderstriangle_graph

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

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

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

triangle_full

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.

MVPs are built by MVTs (minimum viable teams)

The only role that software companies absolutely need to ship product are engineers. You need people to write and deploy code or there literally will be no product. It is a common pattern for companies to get off the ground with a pair of technical co-founders. While companies can ship product while only employing engineers, this leaves vast white space (see A Map of White Space for Product Managers). Developers can wear many hats, but ultimately companies need to enlist non-developer roles such as design or sales to optimally connect the product to users and a business.

Each role that a company adds brings complexity to the product development ecosystem. Natural tensions always surround a product as business and user needs tug in different directions. However, as dedicated roles are hired, the tensions become increasingly pronounced (see Tension in the Product Network). When the voice of a designer advocates for the user experience and the voice of a sales person advocates for revenue, elaborate communication becomes necessary to create a clear, actionable narrative for the development team and keep all team members aligned. Otherwise the company degenerates into some level of disarray.

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

To control a product’s complexity, it is critical for a company to surround it by the minimum viable team (MVT); that is, the smallest number of contributors necessary to perform the diverse functions that a healthy product requires.


Here are two strategies in building an MVT and preserving the simplicity of the communication structure that surrounds a product.

1. Hire “full-triangle engineers.”

The product triangle consists of the fundamental elements that surround a product: the users, the business, and the code. A full-triangle engineer values understanding, in depth, all of these elements. Such rare individuals lessen the need to hire non-developer roles because they can fill in large white space themselves. E.g., for an early stage startup that is striving to validate a minimum viable product (MVP), the need to hire  a dedicated designer is mitigated, if not eliminated in some cases, by a developer with sensibility for user experience and visual polish (this depends on the product).

Furthermore, by synthesizing the big picture dynamics of the company,  a full-triangle engineer can produce breakthrough work with less communication overhead. The number of cycles necessary to translate user and business needs into clear engineering requirements is reduced by a developer who has the the product triangle dynamics internalized.

2. Hire product management as one of your first non-developer roles. 

Product managers are particularly skilled at recognizing and filling the critical gaps around the product. It may ultimately be the case that the company should make hires to fill each gap, but having a versatile product manager is a way for the company to efficiently test which roles it actually needs before taking the complexity and risk of a new team member. In a sense, the product manager can serve as a prototype for each role such that it can be validated before fully invested in.

For example, a product manager may determine that web analytics is necessary to support the product design process. The product manager should be able to sufficiently own web analytics for the company eliminating the gap as a point of failure. If the product succeeds and the product manager becomes overwhelmed wearing the web analytics hat, then it’s time to hire a specialist.

Prematurely hiring a specialist perform a role that a product manager could perform sufficiently adds needless complexity to the ecosystem (and, consequently, the product). It could turn into a damaging distraction if  it turns out the company doesn’t need the role after all (based on a pivot or misconception of the original need).


These two strategies will help you reduce the number of people working on your product which will translate into simplicity and an ability to react swiftly to external signal as a product twists and turns it’s way to validating the MVP. After the MVP is validated, it must, in some sense, become less minimal to grow. It needs to take on features or characteristics that were not necessary to test the idea, but necessary to support massive adoption. As the product becomes less minimal, the team will need to as well. The need to add specialists (e.g., analytics, SEO, performance, security) heightens.

But here’s the key: don’t move beyond the MVT until you’ve validated the MVP.

Company Leaders are Game Designers

A company’s leader must act like a game designer. Before a CEO can lead their company to “win,” they must define the game that their company is playing.  A well designed game must meet the following criteria:

  1. It must have clear rules, objectives, and boundaries. Any game that does not have these elements, regardless of domain, cannot be played effectively.
  2. The players’ success within the bounds of the game must map to real world financial prosperity for the company such as an acquisition, IPO, or elevated stock price. That is, winning the game must have actual value within society.
  3. The game must be winnable by the company’s employees in proportion with the expectation of investors. The chance of winning some games may be intentionally low, but the difficulty level must be in line with the potential ROI.

It is the responsibility of all company employees to play the game designed by the CEO or, if necessary, influence the parameters to change. In devising strategies to win, managers may design their own games to optimize the company’s play in the area they are responsible for. This entails designing games that, if won, achieve progress against objectives of the top-level game. For example, a CEO may design a game with the objective to grow web site audience that can be sold to advertisers. The VP of Product Management may then design a game (among others) for his/her reports to increase pages  per session to various areas of the web site. A product manager, to win the game designed by the VP of Product, may design a game for the engineering team to reduce page load time. In theory, if engineering can win the ‘reduce page load time’ game, traffic will increase on the site which will fee feed the overarching goal to sell advertising. The sales team will design and play a parallel branch of games to maximize revenue based on the site’s audience level.

Company leadership should be very thoughtful in how game design and play is distributed throughout an organization. While everyone in the company, including the CEO, can toggle between wearing the game designer hat and the game player hat, there are some some important conditions to maintain.

The individuals responsible for the real work — tangible contributions to the product — should spend the vast majority of their time as game players, not designers. Maximum productivity and workplace enjoyment is achieved through entering a flow state. Flow requires clear objectives that are in line with your abilities. While it’s healthy for all employees to question the goals they’ve been given, if they lose trust that have been given the right game to play, they will feel perpetual anxiety that destroys flow, and consequently productivity. An optimal organization does not require individual contributors to constantly redesign their own game.

While a company struggles with execution if game design spreads too widely at the bottom of an organization, a company can also falter if game design is too consolidated at the top of the organization. In his book, The Hard Things About Hard Things, Ben Horowitz emphasizes the importance of pushing accountability down an organization. The question, “Is my company playing the right game?” is perhaps the hardest, most important question a company faces. It is essential that top minds in the company help the CEO answer that question. Otherwise the company is more likely to win the wrong game. This applies to the top-level game and all of the sub-games. In my answer on Quora to the question “What does a great product manager do day-to-day?’, I enumerate a few of the wrong games to play given the phase of the product.

To apply these principles to improve the operations of your company, here are some things to think about:

  1. What game and sub-games is you company playing?  Are they well designed according to the criteria described above?
  2. Who are the game designers and game players in your company? Are the primary contributors able to focus primarily on playing? Is game design overly consolidated at the the top?

 

 

 

My Writing Hypotheses

As a parent of two young kids and product manager for GoodGuide, my cognitive surplus is limited. I normally get an hour or two every night after everyone’s asleep to do what I want. My drive is to be creative and to produce (sometimes at the cost of entering a manic state where I can’t fall asleep). While the way I choose to use my free time can vary, I’ve recently made a commitment to develop my writing. While I’m deeply gratified by the feeling of self expression, my reason to write is largely pragmatic. I want  to (a) be better organized and thorough with my own ideas and (b) connect with individuals who value my ideas as a means to open up opportunities.

My writing strategy has been inspired by the ideas published by Venkatesh Rao on his blog ribbonfarm.

In The Calculus of Grit, Rao identifies three keys to personal growth: Reworking, Referencing, and Releasing. I suggest you read Rao’s piece to understand in detail what they mean. Here’s what what I’m doing on each front.

Reworking

Instead of spending my time spewing out new writing on various subjects, I’m focusing on a few core ideas that I want to rework until I hit them out of the park (you can find the kernels here, here, and here).

Referencing

I’m trying to break down my ideas into their most atomic form so I can efficiently link to them without having to constantly repeat myself. So far the best example is how I have decomposed concepts of product management through The Product Management Triangle. I link back to components of the triangle repeatedly.

Releasing

At every incremental point I reach, I publish on this blog, my Quora blog, and Medium. My goal is integrate learning from public reaction (or more often than not, lack thereof) into my process and do so frequently. Hopefully this won’t be my downfall.

In The Deliberate Practice of Disruption, Rao highlights the importance of getting “the law of large numbers to work in your favor.” Through extensively reworking your writing, your “‘errors’ can turn into mutations/innovations that can be developed further. Doorways that lead down very generative forks that have never been explored before.”

Now that I have been republishing a core set of ideas in various forms, I fear that I’m repeating the same errors again and again in way that’s limiting the number of pure permutations.  I’m not sure whether or not this coheres with Rao’s methodology, but, starting now, I’m going to experiment with being systematic about which hypotheses to test in an attempt to ensure sufficient diversity of permutation.

The one writing hypotheses I have banged on so far is this:

I can build a significant following for my writing by going deep on product management specifically.

This approach has come with some success. My answer on Quora to “What does a great product manager at a tech startup do day-to-day?” got pretty good traction. My Quora writing on product management led me to be recruited by major tech firms.

But most of my posts are duds. I have not achieved anything resembling hockey stick growth. So I feel like it’s time to take my core ideas, and rework them in new configurations. These are the next hypotheses I want to test:

I can build a significant following for my writing by…

(1)  Generalizing my ideas to  the broader craft of building software companies (i.e., not focus narrowly on product management).

(2) Writing pieces that respond directly to popular ideas published on the Web (like this).

(3) Writing self-reflexive posts about my writing thought process.

As you can see, this post is the first test of #3. Assuming I keep momentum, you will see my experimentation unfold if you follow me on any channel mentioned in the “Release” section above. If you have ideas for other hypthoses I should test (or have other feedback for me), I would be thrilled to hear it. In the meantime, hopefully I’ll make an error that clicks.