There are at least four states that a product team can be in. As a product leader, if you can understand these states, you can find ways to change the team state to build better products and deliver more value for customers.
Team states are defined by two dimensions. The first is the pace at which new products & features are developed and delivered to customers (”shipping”). The second is the impact that those products & features have for customers, in the market, and on your company’s trajectory.
The state of a team is a combination of a bunch of different ingredients: the market you’re going after, company culture, exec leadership, product strategy, organizational incentives, and the members on the team. Team state is rarely caused by any given team member, or any one factor.
Teams naturally move between states as the market, company, strategy and internal incentives evolve. Some states are stable and can remain in a state forever (e.g. not shipping). Some are unstable, with structural reasons why they will not persist (e.g. teams shipping high-impact products are prone to talent drain)
States are not sequential. Teams need not to move between them linearly.
A product organization can and will have teams in various states. A product leader can be measured by their ability to consistently move teams to a desired state, and keep them in that state.
To understand why a team is in a particular state, you first need to understand the underlying conditions and factors that caused the state. For example, a team that’s not shipping could be due to attrition, tech debt, unclear strategy, inability to hire, missing skills, bad incentives, internal team tension. To move a team to a new state, you need to change the underlying conditions.
Let’s look at each state and ways in which a product leader can help change state.
Your Team Doesn’t Exist (Yet)
This state is where all product teams start.
In this state, there is The Idea but there is no team dedicated to pursuing The Idea. You (and perhaps a recruiter) are responsible for building the team that will turn The Idea into a product.
This state is independent of whether The Idea is a good idea or a bad idea. It’s independent of whether The Idea is a broad problem to solve (best case) or a specific product that someone thinks is a good idea (worst case).
There are two paths out of this state.
The first path out is to invalidate The Idea. This can save you months and years of your life trying to build something nobody wants. Go talk to customers. Prove or disprove your hypothesis. Build a prototype and actually test whether The Idea solves the problems you think it does. Killing The Idea is the fastest way out of this state.
Your second option is to build your team, which means you need to hire. Hiring in this state is tricky because it’s a “cold start”. You don’t have much momentum or validation that The Idea is worth anyone’s time. You don’t have other teammates that can help sell candidates. The best thing to do is to develop a clear vision and hire a team of folks who are excited about the vision and willing to take a risk.
The other thing to optimize for in this state is flexibility around The Idea itself. This can be internal (not letting yourself get too attached to any solution) or external (not letting the org pre-define a solution). That flexibility will allow your team to have more ownership and creativity to expand, iterate, or even change The Idea once hired.
Your team doesn’t consistently ship
In this state, you have a team but they do not consistently deliver new products, and are not iterating on existing products and features in meaningful ways.
There are many conditions that can lead to this state. The team can be working on a multi-year project. They may have shipped something that caused a SEV and are fearful to ship again. They may be carrying a lot of tech debt, that makes it difficult to ship.
The challenge with this state is that it’s self-reinforcing. This state falls prey to a perverse version of the Lindy Effect: the longer a team doesn’t consistently ship, the longer a team will typically go without shipping. That’s because teams in this state do not have access to all the benefits of shipping (positive customer reactions, release parties, the excitement of launch day) and the muscle required to deliver products to market will atrophy (don’t know the process, unclear how market or leadership will react).
To get out of this state, first you need to understand the underlying causes. There are two strategies that can be help you understand those. The first is to get the perspective of the team, to encourage them to share their problems. The second is to find the smallest possible thing to ship, and work with the team to ship it. Doing so will highlight where the friction is, while also building the shipping muscle.
Your team consistently ships low-impact products
The key to this state is that the pace of development is good, but the quality and impact of the products is poor. This can take many forms: products can be unstable, prone to outages, not solve a clear need, too expensive, and not have the right user experience. There are many ways to create low-impact products.
In smaller organizations, low-impact products are typically a symptom of lack of focus. Teams are moving too quickly and not enough validation, architecture design, diligence, QA, and testing are being invested into what’s being built. In larger organizations, low-impact can be a symptom of incentives and culture that celebrates splashy launches over measured impact of those launches.
To change state, you need to change incentives and culture. One way to do that is to introduce metrics & dashboards that emphasize customer impact and stability that the team can use to measure their own performance.
Your team consistently ships high-impact products
Teams in this state are high-context, high-trust, and high-talent density. They work closely with customers and feel empowered to take risks. They are consistently delivering products and features that delight customers.
There are two reasons why teams will not tend to remain in this state.
The first is that the mission of the team will naturally evolve as the product (or project) progresses. The initially value prop that attracted team members will erode. The excitement of building a new product, or fixing a long-standing problem in the infra, will cease to be the work. The product has been built. The infra scaling challenge solved. Team members will seek out new challenges.
The second reason is that you (or other leadership) may be tempted to “spread the talent out”. You may want these team members to go teach teams that aren’t shipping how to ship, or to go build their own teams. These changes may be best for the org, but risk changing the state of the team as members are redirected to new challenges.
Team states are malleable
As a product leader, you can and will change the state of your product teams. Team states are malleable. As conditions change, so to will the state of your teams. By understanding these states and being thoughtful about state change, you can build an org of product teams that consistently ship high-impact products.