The Many differences between 0→1 and Scaled Product Teams

“This isn’t going to be just another typical project” is one of the first things we find ourselves covering when working on ambitious products with innovative product teams. That’s because inventing a product which does not yet have a fit (and may not ever achieve fit), and scaling an already invented product with fit, are two?very different?processes that require completely different approaches and skill sets.?

There’s no better visual representation of this than this slightly modified graphic about the journey of a startup from inception to market winner by Nithyl Singhal (from his excellent?post?on the First Round Review blog):

As you can see, there are stark variances between the left-hand side of this graph and the right-hand side. And in this post, I’ll cover some of the key differences between the type of work and people required to operate between the 0→1 phase (left) and the 1→n, or scaled, phase (right).

Using the above as our guide, let’s analyze these critical differences further.

Core Skill Set

0→1 = Ability to learn quickly:?It is impossible to precisely forecast which version of your product will be a success, if any, due to the non-linear nature of trying to establish fit for your product within your market (that’s what the up and down waves in the graphic illustrate). The product you first create may not even resemble the one the market claims it wants. Because of this, it’s commonly agreed upon within the 0→1 community that the fastest approach to determine fit is to get rudimentary, non-scalable versions of your product in front of your target audience. In other words, “be embarrassed by the first version of your product.”?By way of example, see a great repository of embarrassing v1s?here.

Scaled = Ability to build deeply:?By the time there are dozens to hundreds of team members working on your product, millions of users interacting with it, and potentially large revenues associated with it, the most important skill set for each team member is to own and maintain/grow their relatively small surface area of the product. These team members need to work together to incrementally, but meaningfully improve the product on the market without harming it. Additionally, the product has become so complicated by this point in its lifecycle that it is hard for a single person to comprehend all of its inner workings. Instead of “the full team” like in 0→1 teams, decisions are taken, and change management is planned by the committee and leadership. As a result, the most productive team members are those with extensive knowledge of their particular product area.

Roadmap Confidence

0→1 = Low (resets weekly):?With 0→1 exploratory work, the furthest a PD team can see out toward the horizon is the next milestone at which they will acquire meaningful net new information on whether their product direction is promising. Since the variance in outcomes at this checkpoint ranges from “wow, this is really working, let’s double down” to “this is DEAD ON ARRIVAL, let’s go back to the drawing board,” there is no way to see past this point (it’s sorta like trying to looking into a black hole). These teams should be showing new concepts to users every week, so their roadmaps change week to week. Their job is to run an insights-generating machine vs building out a pre-defined, meticulously detailed product according to a specification.

Scaled = High (resets quarterly or biannually):?The team typically has a mission in place, and a strong product plan to achieve that mission after a product is working and scaling. Here, everything is turned around, and?product execution trumps product exploration. As the team grows, a significant percentage of execution comes down to coordination, which necessitates many strong interfaces being drawn between teams. The product roadmap serves as the ruleset for these interfaces. To keep this effort on track, well-coordinated, and providing accretive value for its users, product roadmaps are often defined at this stage with at least a steady 90-day perspective.

Team Size

0→1 =?Small (<20):?When building to find product fit, the limiting factor is not getting enough features built or tasks done. It’s figuring out the?right?product. Almost every tech product we use was built by an initially tiny team because the magic of the product can be found with a relatively small audience of users. What matters is the resonance of the product with those users and finding something that, once used, cannot be taken away without a mutiny on their hands. As we’ve established, the objective at this stage is to locate the correct product as soon and effectively as possible. As a result, team size immediately trades off with speed. Small teams don’t have the same information/process tax as large teams. The majority of goods working hard to discover fit have teams of no more than 20 people and are frequently made up of 5 people or fewer.

Scaled = Large (>100):?At this stage of maturity for the product, it really is all about getting useful features out to users to increase the value of the solution you’re providing. Feature requests always outnumber the available bandwidth for a product that’s in full-scale mode, so hiring, coordinating, and ruthlessly prioritizing are the key specialties at this stage. Complicated products like Google’s AdWords or Facebook’s Newsfeed have thousands of people working on them at any given time, which makes sense, given how valuable those properties are and how many users they serve.

Priority

0→1 = Speed:?The most important thing to consider when building 0→1 is, “are you moving quickly enough to build something your market wants before you run out of gas?” In many ways, the 0→1 builder is a generalist and methodologist specializing in building a learning machine whose output is a scalable product, vs. a classic engineer, product manager, designer, or researcher, defined by their skills and not their role. 0→1 PD teams should give away product cycles for learning cycles, i.e. they’ll launch an experiment that looks perfect to the user but doesn’t work behind-the-scenes (called a?Wizard of Oz test) to learn something about user behaviour or motivation.?

Scaled = Stability:?On the other hand, scaled PD teams have a key duty to care for their users and support the product’s achievement of its maximum global impact. Scaled teams should conduct experiments as well, but they must do so within the service and limits of the larger product. For instance, it would be irresponsible to haphazardly introduce a new feature before it has been thoroughly tested because doing so could result in the entire product being offline (and when that happens, major consequences follow!). Stability is the key factor for scaled teams to focus on, as taking product risks and degrading the core product experience in some significant way is unacceptable.

Tools Used

0→1= Whatever is quickest:?“What tech stack should I use for my Minimum Viable Product (MVP)?” is one of the frequent queries 0→1 teams have when they first start out. Although these companies anticipate a response along the lines of “use React with NodeJS backend and a NoSQL DB,” the solution is much more approachable (and many Google searches will provide similarly prescriptive advice). For 0→1, the only tech stack that should be used is the?one that your team already knows. The goal is to bring fresh product concepts to your target audience in the order of days. Using what you know is, by definition, the fastest path to this goal. Once you find what works, you can recreate it by taking the long, scaled view after deciding?what?to scale. However, you must first confirm that the product has a lifespan of at least a few months.

Scaled = Whatever is already in place:?Decisions made to stand up the product and onboard droves of users are very hard to change, and thus, scaled PD teams almost always extend those choices until the product is in a place where it risks falling over without a wholesale re-architecture (which can span years depending on the scope and complexity of the product and the work required to migrate users to a new version). When developing features for a scaled product, it is possible to introduce new tools, but these tools must be thoroughly vetted and integrated with the core incumbent tech stack rather than simply replacing their predecessors. Additionally, there must be extensive prior discussion to ensure that stability or security is not jeopardized. In this reality, it is highly likely that teams will use the same tools that have been used to date to extend the product.

Goal

0→1 = Find the product fit for a set of users:?Finally, and some would say most importantly, the main goal for a 0→1 PD team is to find the true fit for their product with a set of users. Fit (also called Product Market Fit, or PMF) is a very high bar with no guaranteed outcome for any 0→1 PD team. This must be every 0→1 PD team’s priority because if it isn’t, priorities 2-10 don’t matter. Teams can get bogged down in externalities (branding, PR, raising capital, blog features, conferences, podcasts etc.), which slows down the work required to achieve exit velocity of an idea to initial product to scaled product, as our journey graphic above so beautifully shows. Every 0→1 team should reassess their time-based investments monthly to ensure that finding a fit for a set of users is their #1 goal and where almost all of their time and resources are flowing (or into activities that directly contribute to this cause). This is survival of the fittest in its most pure form.

Scaled = Grow user base and improve the product:?A scaled team’s objective is to increase the number of users they’re serving and to provide as much impact as possible on them. As a direct consequence of this goal, scaled PD team members fight for resources and time on the larger product roadmap by developing mini-business cases for why their areas of the product require prioritization. If handled well, this benefits the product, the business, and its users. Encouraging members of the scaled PD team to concentrate on making a measurable positive contribution to the product rather than working on tasks that have little or no downstream impact, creates the right incentives to get these large teams to all row in the same profitable direction. It is no wonder that many tech companies try to develop frameworks to measure this impact in their performance review processes. The secret here is to set up a lightweight system to handle this massive amount of complexity, which is a constant struggle for large companies with massively adopted products.

Final Thoughts

The key characteristics of a 0→1 PD team and a scaled PD team are starkly different, as demonstrated above, but this does not mean that one is more important than the other. Both are crucial for achieving the impact we’re aiming for with our products. The important part is aligning yourself with the type of work that resonates with you and then focusing on impact through that lens.

Hopefully, the list above will help you assess whether you’re doing the work that you believe you should be doing; if not, perhaps it’s time for a change…?