3 Organisational Conditions for Successful Product Teams

How and when to set up multi-disciplinary teams to tackle complex challenges

Oct 26, 2021

I've learned the hard way and from several vantage points that creators of Product teams (funders, executives, directors) need to give them exactly 2 of the following 3 Conditions before expecting significant impact:

🧭 Remit (or Purview, for the Americans)
💰 Resourcing
💃 Autonomy

Firstly, I use the presence and strength of these Conditions to differentiate between Product, Project and Operations teams. Secondly, I use them diagnostically to assess and increase existing teams' chances of success. And lastly, I use them proactively in decisions about how and when to create new teams.

What's a "Product team"?

I'm using "Product team" as a shorthand for a "multi-disciplinary team doing Complex work". A team can consist of a Product Manager, Delivery Manager, Designers, Engineers, Researchers, Data Scientists and so on, and therefore look like a Product team, but if their work isn't Complex, I wouldn't call them that.

What does "Complex work" mean? Anything that is beyond carrying out routine or checklist-based procedures, well-defined and predictable projects, maintenance responsibility, or tasks that are obviously automatable. Complex work involves high degrees of uncertainty or risk surrounding either of Remit, Resourcing or Autonomy, because it is solving for a new type of problem, or aiming for a significantly better solution to an existing problem.

This means Complexity is relative. Depending on the experience levels of the people involved, the maturity of the organisation and market, the available technology, and other factors, one team's Complex work might be another's simple project.

Assessing Team Conditions

Below are sample starting questions I'd ask about a team looking for better odds of success:

🧭 Remit: What is the team's scope of responsibilities? Are they able to define and work towards Clear Goals based on that scope?
💰 Resourcing: Do the team have the people, experience, skills and tools needed to tackle the Remit?
💃 Autonomy: Do the team have sufficient freedom to use their Resourcing to address the Remit?

Keep in mind that the 3 Conditions affect each other so diagnosing a team will require asking several rounds and variations of questions.

In my Coaching and Consulting work, I'm looking for positive, clear and confident answers to at least two of these questions. These answers (as qualitative measures of the Conditions) need to be coherent and matching each other in strength eventually. It's no good to 'max out' one of them whilst the others are lagging far behind. For example, a bunch of money and talent (Resourcing) thrown at a team whose Remit isn't clear nor has the Autonomy to make its own decisions won't allow the team to succeed. Yes, I also thought this was obvious but I've seen some things ... 🙃

💃 Autonomy is worth explaining a bit more. This condition is about the degree of freedom a team has from rigid dependencies & structures. Such constraints can include:

Approval processes from higher-ups or siloed parts of the business. For example, consensus from a committee to add a new component to a Design System, or sign-off on content from the legal department;
Prescriptive ways of working e.g. only one tool or workflow allowed for tracking tickets;
Burden of maintaining a legacy product;
Compliance with industry standards or statutory law;
Conflicting remits with other teams;
Inability to define and refine the team's goals aka being handed targets to hit without the team's input.

It's also worth noting that constraints on Autonomy aren't necessarily bad, and can in fact lead to creative solutions. Some exist for good reasons: to protect important stakeholders or underserved users (such as accessibility compliance), or to serve a larger purpose (maintaining an old cash-cow product allows investment into new work). The point is to be aware of these constraints and how they affect the team's Remit and Resourcing.

Why 2 out of 3 Conditions is Desirable for Product work

3 out 3 → Project or Operations

If the leaders creating a team can easily provide them with a clear Remit, high Autonomy and enough Resourcing to match, then great! We are likely not dealing with much uncertainty or risk and the challenge at hand is not Complex. Therefore the work can be treated either as:

A Project: get from state A to state B via known path P
Or part of on-going Operations: keep doing X activity and producing Y results.

Projects and Operations can be highly intricate, complicated and difficult, of course, but may not need as much multi-disciplinarity nor have as much uncertainty and therefore not what I'd consider Product work. Instead, outsource it, automate it, or train specialists to operate it.

In other words, when you have 3 out 3 Conditions, create a Project or Operations team. Putting a multi-disciplinary group of people who expect to solve Complex problems on such a task will lead to them either getting bored and leaving, or seeking to increase the scope of their work to include more interesting and Complex problems to solve (this could be good!).

2 out of 3 → Product

If Remit is unclear or Resourcing is limited or Autonomy is low, then there is more uncertainty and risk, and therefore a Product team might be needed to find solutions for getting from A to B (or even defining A and B!). Leaders shouldn't put any team on a task when less than two Conditions exist, because there is minimal chance of success.

However, if leaders can provide two of the Conditions and it's proving difficult to provide the third, they're likely facing a Complex challenge and it's a good time to create a Product team. 2 out 3 Conditions is ideal for a Product team because with the help of a competent Product Manager (or Engineering, Delivery or Design Manager), the team can do a better and faster job of creating the 3rd Condition than the leadership can. The Product team are closer to the work than most leaders and thrive on such challenges as part of their Product Practice. There are some examples coming to illustrate this.

Eventually when a Product team creates their missing Condition and all three are present, their work can become a well-defined Project or be absorbed into Operations. At this point, the more experienced (i.e. better-Resourced) team can change their Remit or gain more Autonomy in search of more opportunities for helping their customers and business.

So: 3 out of 3 Conditions means promising Project or Operations work. 2 out of 3 means promising Product work. less than 2 means minimal chance of success.

Here come some examples of good starting Conditions.

The Bet: Rich and Free

Flush with cash, the CTO of Faang Corp. hires an all-star team of Engineers and Designers with a long leash and a very broad Remit to "innovate within the consumer space". This team play around to find opportunities, define their own goals and change course often, launching several interesting products within a year. One product starts to make money, so a sub-team is created to maintain it, and another one improves an existing product and is integrated into it, increasing Faang's competitive advantage. Faang placed a bet. They've likely placed several like this and for the long haul, so they are likely to succeed with some.

The Disruptor: Focused and Rich

NewBank's VP of Product assembles an experienced Product team from existing staff, gives them a large marketing budget and asks them to "double sign-ups to Premium accounts this financial year". The team has to navigate compliance with banking regulations within the Premium product as well as conflicting goals with another Product team tasked with improving user retention. It takes them 2 years to reach x2 sign-ups, whilst barely regulation-compliant, and only because half the "marketing" budget went towards partnerships and relationship-building with the financial regulators and winning some temporary leeway.

The Start-Up: Focused and Free

A Product Manager and an Engineer at StartX are asked to turn a feature that was custom-built for one client into a standalone product. They iterate on a prototype & test it with real users until they have a version that they are confident will be valuable for multiple clients. With the the strength of their user research and promising projections of increased retention, they convince management to fund a full team to design and build a production-ready version.

Note that in each of the above examples the presence or absence of each Condition is only that way in relation to the other Conditions. Without the team figuring out how to leverage the two strong Conditions into strengthening the third, they and their work will vanish one way or another.

It's much, much harder to use only one strong Condition to strengthen the other two for a Product team. That's why funders and leaders who create teams need to take it on themselves to provide two. I sometimes think of the Conditions as the three legs of a stool, with one often missing or broken, and a good Product team as being able to hold the seat whilst gradually and iteratively fixing the last leg.

How do you assess your team's levels of Remit, Resourcing and Autonomy in relation to each other? What does this tell you about the nature of your work? What support could you ask your leadership for? What can your team do next to create the Conditions for Success?

Peachy Product Practice

Discussion about this post