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:
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.
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.
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.
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.
Product Logic 