Something that has been on my mind a lot lately is the question of how to structure and orient product teams. There are many different opinions about this, without much consensus, not even on what the “best in general” answer is. I recently came across another startup founder’s summary of the common approaches to this problem, based on his conversations with the product leaders of a dozen or so other companies. It roughly groups into three high level schools of thought.

• Roadmap deliverable oriented: the product team is responsible for planning a roadmap with items from other teams (which help them achieve business objectives), and delivering on these items in a timely manner with high quality.
• Business outcome oriented: the product team is responsible for achieving certain business outcomes or objectives, facilitated by the planning and execution of a roadmap.
• Learning oriented: the product team is responsible for creating a process that continuously generates validated knowledge and learnings towards achieving the high level business goals.

At first glance, the three types of teams seem to be simply the natural progression of a product team as it gains more and more autonomy within a company. In the roadmap deliverable orientation, the product team owns very little beyond the delivery of features. Other, usually more customer-facing teams (e.g. sales) determined what product items to work on in order to achieve the business objectives, with product playing more of a project management role. Moving to the business outcome orientation, the product team now gets to determine what items to work on based on the desired business objectives. Finally with the learning orientation, the product team is empowered even further. It’s now able to measure the effectiveness of the work done, and can actually reorient itself, in terms of the approach and even objectives, based on any new information learned, as long as it is still operating within the same set of high level business goals.

Upon a bit more reflection, it becomes clear that each of the three schools of thought has its own advantages and disadvantages. Roadmap deliverable oriented teams focus primarily on the planning and delivery of a pre-determined set of items, so they are very efficient at outputting tangible, high quality features. Because of the known-ahead-of-time nature of the items on the roadmap, teams oriented this way can plan far out into the future, and have quite a bit of clarity on the details of the features to be delivered. The downside is that the teams are not as aware of whether these delivered features actually help with the business objectives, after all this isn’t the main concern of the product team. On the other hand, learning oriented teams prioritize learning above all else. More specifically, the teams seek to learn what the most impactful thing to do towards the business goals is, and while incrementally doing that thing, constantly learn whether what has been done is indeed effective in the way it was expected it to be. In terms of raw speed and quality of features completed, this style of team orientation typically lags behind the others. But it gives the team a much better handle on the exact effect its work has on the business.

Perhaps then, these three approaches to product team orientation are suitable for different types of companies. B2B companies with complex, enterprise-facing products cannot afford to rapidly change their product offerings. Their customers, especially the ones who have committed to paying them in large, multi-year contracts, have much higher leverage (and justifiably, the right) to demand for clear, detailed long term product roadmaps. These companies would naturally gravitate towards the roadmap deliverable oriented team structure. Direct to consumer, B2C companies tend to favor the style that prioritizes learning (at least the successful ones do). The space and market usually change at a pretty fast pace, so pre-committing to a set of deliverables based on an assumption that could become out of date in a few months is not a very good idea.

Or maybe it’s not the market segment that the company operates in, but rather the size and maturity of the organization. Bigger teams have more management overhead, so planning ahead of time and sticking to the plan has a significant benefits for them. In addition, bigger companies usually already have some form of product market fit (otherwise they would have remained small or died), and have a pretty good idea of what their customers want from the domain expertise gathered throughout the years. Contrast this with younger, smaller companies, which are not as clear on what their product should be or do, and so need to focus on learning about their customers first. They are much more nimble, so it helps immensely with approaching problems through a more experimentative approach.

A common theme that emerges, which these different approaches reflect, is the level uncertainty that the team encounters. If the environment to operate in is filled with unknowns, be it business or market related, then it is much more beneficial to orient the product team towards learning. When no one is sure about the future, it’s best to question everything, take smaller steps, move incrementally, and carefully observe and reorient after every step. It is much more important to go in the right direction, than to go fast. On the other hand, if the environment is well understood and has very little volatility, then it’s better to optimize for the speed of feature delivery. It’s unlikely that nobody else understands the market or space, so it more or less comes down to a race to be first in this case. It is way more important to go fast when everyone is clear on the direction to go in.

Ultimately I think it is more helpful to think about this with more fluidity, both in terms of the schools of thought themselves, as well as how to apply them. These three types of team orientations are not really rigid structures, but rather lie on a continuous spectrum. The two ends of the spectrum are the archetypal, extreme versions of the “roadmap deliverable oriented” approach and the “learning oriented” approach, respectively. More moderate versions of these extremes, as well as approaches that are in the middle (such as “business outcome oriented”), and various hybrids, all lie somewhere between the two ends. There is little value in religiously sticking to the letter with any one of the schools of thought when structuring and orienting a product team. As long as the relevant pros and cons of the main ideas behind the different approaches are well understood, a team can simply craft a unique style that suits them the best, taking into account the tradeoffs.

Applying these ideas to teams is best done in a flexible, dynamic way, with nothing set in stone. As the team grows and matures, the structure and orientation need to evolve with the team. Depending on the stage that the business and its products are in, its teams may need to favor different things. A startup may begin with a very learning oriented, small team, and as it scales and learns more about the market, transitions into a more business outcome oriented team structure. Conversely, a larger organization that is used to operating in a mature market with high certainty may need to abandon its roadmap deliverable style approach when it’s looking to branch out in an unfamiliar vertical.

Even in the same point in time, it may be helpful to employ different orientations for teams working on different things in an organization. Teams working on existing, older product lines naturally tend to operate in an environment with more certainty, and probably have a lot of execution efficiencies to gain from more roadmap deliverable style structure. People responsible for newer product lines should definitely try to learn as much as they can, while not committing to deliverables too concretely too far into the future, since anything could change based on new learnings.

Beyond the age and maturity of the product areas, which style of team orientation is best could also depend on the current business or product strategy. Even in very old and core parts of the product, if the strategic plan is to try and do something new with it (perhaps a new way to use it for), then the team should probably be oriented more towards learning. Although the current product is very well understood, the new application of it is still new. The level of uncertainty that the team is expected to encounter and operate in, in my opinion, is the best indicator on how best to orient the team.