👋 Hey, it’s András here! Every two weeks, I write about product management concepts, hot takes, and frameworks to help you build better products. Subscribe to The Product Principle to get each article delivered to you when it’s published!

What’s the best way to structure the product development function inside a company? Squads, long-lived features teams, frontend vs. backend, one team per app, or something else?

While this is a challenging question, the answer would only help us with the way of working. It wouldn’t answer how to distribute a company’s focus, and how to split our business priorities.

Generally, there is no perfect answer on how to scope product teams.

And the boring one is: it depends.

Based on the industry, the product, the customers, the staff, and many other factors. It’s always a custom formula; there is no one size that fits all. Some setups work well for one part of the organization, but not the other part.

In this article, I explore a framework for designing product teams, how that’s similar to making investments, and how it can be translated to deciding on feature priorities.

From empowered teams to investments

Drafting the product organization structure is one thing; creating well-equipped teams for success is another. On the second matter, I very much like Marty Cagan’s empowered product team description and how he defines the responsibilities of roles:

“In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.”

Of course, there is more to this description, and if you haven’t read Cagan’s article before, I’d highly recommend it.

It takes a lot to create empowered product teams that can operate efficiently with minimum handholding from leadership. But those teams need to be set up first. Kicked off by the leadership who must provide vision, strategy, and frameworks to make that happen.

It wouldn’t be reasonable to assign two teams to a product with only one customer. Or to have one person working on the biggest cash cow functionality, right?

Lackluster team scoping can lead to overinvestment in the wrong priorities and underinvestment in the right ones. To structure teams well, the company vision has to be backed by market knowledge, a list of potential customers, and a demonstrated hunger for a solution.

Even with a good vision, teams can grow a product in different directions — ending up with functionalities that are great for many subsets of customers. But those subsets are not aligned across the whole product.

If the vision from the top is incorrect, individual teams will rarely realize they’re building the wrong thing. How often do teams question their reason for existence?

But then, how to structure product teams as a company to leave room for innovation, maintain popular features, while keeping a healthy level of technical excellence?

There is a way, and the title spoils it all: thinking about product teams as investments.

Long-term, short-term, and the money for food

So how do people structure their investments?

First, people need to run their life: paying rent, buying food, managing utility bills, and taking care of household items like toothpaste and cleaning liquids. Maybe even a car.

Then, a good portion of people has long-term investments: saving for a specific purpose, storing money in low-gain and low-risk assets, as it’s better than just parking the savings in a bank account.

Then again, some people make short-term investments: balancing the sizable risks with potential gains. Ten years ago, this would have meant stocks; today, it’s also crypto and NFTs. (Note: this is not investment advice.)

This splitting makes sense because you’d like to structure wealth so that there is growth potential, but it’s very hard to lose all savings overnight.

And the same approach applies to structuring product teams.

The money for food and basic needs

Teams who provide foundational functionalities to run infrastructure, hosting, and generally enable other teams to deliver value faster. Organizations at scale operate infrastructure, DevOps, or platform product teams. These teams focus on a technical domain, and at most companies, they’re the smallest subset of teams from the list.

Overinvesting in these types of teams can lead to increased efficiencies, but with two caveats:

1. If the problem being worked on by a company is not valuable enough, no matter how good the infrastructure is, the product will eventually fail.
2. Second, improving efficiency is often an exponential curve: putting in an X amount of resources doesn’t result in an X amount of gains.

Long-term, low-risk initiatives

A few cornerstone product features that companies want to continue to capitalize on because they’re driving most of the bottom line. Customers expect them to work well and to gain new functionalities once in a while.

Spotify’s music player, Google’s search, Twitter’s feed, or Jira’s board are a few examples. Here, companies don’t want competitors to catch up just because they were neglecting a feature, so they continue to moderately invest in those.

No one expects colossal growth from these features, but keeping them well-maintained drives further business opportunities.

Short-term, high-risk bets

Additional areas companies are exploring. Areas with great growth potential but also an increased risk. Things that people consider building or already building, but the market/interest is not fully there yet. And for the company, it wouldn’t make sense to bet all of the revenue solely on these.

This group represents another subset of teams, and depending on the lifecycle of the company, could be smaller or bigger than the previous low-risk group.

Startups belong to this high-risk category: they either succeed by finding a product-market fit, just barely stay afloat, or they fail. The risk is high, and the lack of sustainable revenue makes the opportunity window short.

Eventually the a company’s leadership decides how they want to structure the teams based on the three groups above, and what portion of them will be leading bets.

Not focusing enough on innovation can bankrupt any company. And Nokia’s failure to innovate enough in the phone industry before competitors took to the top is well-known.

Betting within product teams

Structuring initiatives like investments can be also translated to how individual product teams prioritize features. Product managers responsible for a single team are equipped with the same set of tools as senior product leaders, just on a smaller scale.

All the functionalities a team is building can be put into one of these boxes:

• Necessary changes: technical work to keep the servers running, reacting to disruptions, enabling scaling, fixings bugs, or upgrading systems. These are the basic needs, so the money for food.
• Long-term & low-risk: adding functionalities to existing features to serve more use cases, optimizing the workflow, improving the user experience, or changing some icons. Small initiatives that keep the core product compelling.
• Short-term & high-risk: brand new solutions that either extend what the whole product is capable of, or increase the number of user segments served. Usually tracked through adoption metrics and whether they’re lifting other KPIs.

The challenge is similar here to scoping multiple product teams.

How can we identify what items belong to which bucket from the three?

Letting short-term bets run long-term without proper measurement can lead to product creep. Having additional functionalities or teams that are costly to maintain and not bringing in the expected returns.

To avoid this, we have to set up rules for graduating bets to long-term initiatives. Defining at which point we should consider a bet as a success and start building on top of it.

Also, what’s the expected return of long-term initiatives? There will be cases when a previous core solution is not performing well anymore, and then we’ll need to choose what to do with that: improve it, replace it, or discontinue it?

And that’s all part of the true cost of a feature.

Conclusion

There is no perfect answer to the ways of structuring product teams, or how to balance different functionalities inside a team.

The best we can do is to think of them as investments:

• money for basic needs,
• long-term & low-risk initiatives,
• and short-term & high-risk bets.

Even if the current organizational setup is not ideal, start somewhere, experiment, take the learnings, keep what’s working well, and gradually improve the other parts.

The conditions, the market, and the opportunities will continuously change.

The best you can do is to adapt to them.