Product Transformation - Solve problems to drive results

Why do we organize into teams when building products?

One of the deepest and most fundamental ideas in the product model is how this question is answered differently compared to in average product companies.

The big idea is to create problem solving teams. This means that we give work to teams in a different way - we give them problems to solve, not things to build.

We call these teams “product teams”. We say these teams are "empowered to solve problems", which is why they are also sometimes called "empowered teams".

‍How a key insight is gained...

Imagine a startup, a handful of people in a garage - with the customer next door on the other side of the street. This team needs to understand what the customer needs, and solve that problem by building a solution that fits the problem - the right product.

To people in that garage it is obvious that only if the important customer problems are solved can we create meaningful results - for the customer and for the startup company.

When such a startup team succeeds it is because it is forced to directly understand the customer, to test out their solution ideas and confirm that what they decided to build actually worked for the customer. This is what resulted in the customer wanting to pay for the product, which allowed the startup to thrive.

...and then lost through success

As a small company grows, the awareness of this fundamental idea is often gradually lost. As the company gains customers due to initial success, we feel we now know what the right product is to build but we become bottlenecked on capacity to build things. So the company adds teams and organizes them as solution building teams - delivery or feature teams, as we call them in contrast to product teams.

Of course, we gain other advantages as we grow compared to the garage team where it all started. But gradually, our teams lose the capability to solve customer problems. New people are added and some people from that garage may leave, and with that memories of the garage days. Teams now no longer have direct access to that customer across the street, so they now need to be told what to do.

Awareness of the key insight decays, and over time the attractiveness of the product decreases. With that the competitiveness of the company weakens.

‍How to organize to make the big insight work consistently

The key insight is that only when we successfully solve customer problems can we create successful products that drive results.

If this is a fundamental and high leverage idea, why would we not organize like this at every level of the organization?

To organize around this idea, we need to consistently give work to teams in a different way.

We need to give teams customer problems to solve and freedom to select the solution that solves that problem. With that freedom comes the responsibility to understand what the customer really needs, and building a product that not only solves the customer problem - but a solution that also works for the business and fits into the bigger picture.

This also means that after the team selects and builds a solution to the problem they were given, they are responsible for confirming that the solution solved the problem from the point of view of the customer. If it did not create the result we wanted, the team is responsible for going back to square one and create a new solution that does.

To make all of this work, longer term desired outcomes and larger customer problems to solve need to be decomposed into smaller problems to solve; small enough that they can be given to individual teams to be completed in a shorter time frame. For each such problem to be given to a team a success metric needs to be developed, that helps the team determine if they are making progress in creating the results that we want. Without a success metric, the team can not fully take ownership of creating results.

This work is not done by the teams responsible for solving problems. It is done by senior product leaders, responsible for selecting what problems to solve.

Some challenges when adopting this big idea

One of the most common challenges when adopting the idea of problem solving teams is to over-focus on the team level. Making sure a team can get started with product discovery in a helpful way is one of the obvious challenges, as this is a new type of work activity for a team that has been focused on delivery. Most organizations try to account for this part of necessary change.

While focusing on the team level is necessary, many organizations underestimate other pieces that also need to fit. I want to briefly mention two areas worth highlighting.

The first is how product leaders describe future work that needs to be done, and what other changes need to happen that relate to how to give work to teams as problems to be solved. Typically, the needed shift here is significant and often requires product leaders to completely shift how they work with strategy, create expectations and very often a significant cultural component around what is considered product success.

The second has to do with the extension of that last part, how we operationalize our now different definition of product success. Both the team level and the product leadership level, which is responsible for converting big picture strategy into actionable product strategy and team objectives, often now needs a whole new system of metrics to both express and follow up if we are gaining traction. Most organizations are so conditioned to align on pieces of solutions and output metrics that the shift to aligning on problems to solve and outcomes can create confusion around how I now am expected to contribute and how we now need to modify our collective tools and habits for governing our product organization.

This can manifest as a major struggle to break down large business goals to team objectives, in a way that when there is time to give new team objectives to teams there is very hard to see a clear line of sight between the two.

In a way, this common problem can be summarized by under-serving the need to shift competencies and practices when it comes to the whole product leadership discipline, and how to operationalize strategy in the product model.

There are many ways to tackle these types of challenges. One way is to start with product strategy and help product leaders develop new collaborative habits to get more comfortable expressing future work to be done as problems to solve and desired outcomes, and only after that start with the team level.

Another way can be that in parallel with a shift at the team level convert current output based roadmaps and goals into outcome based equivalents, as a stop gap solution. While at the same time strengthening strategic insight generation so that product strategy assessments can start with a much stronger knowledge base at the strategic customer problem level.

As this work and at the same time insights generated at the team level emerge, product leaders gradually gain a much better base for their product decisions and opportunity to communicate a better product context. This is typically needed to improve the situation long term, as it is common that insight generation to support strong product strategy decision making is weak in organizations previously not familiar with this way of operating.