Product Transformation - Creating Products Collaboratively

How do great products get made at the team level?

One of the most foundational ideas in the best product companies is the idea of having the people best suited to craft something great be directly collaborating, and in direct contact with customers.

The needs of the customer and users, the needs of the business and what the technology and engineering can enable to connect them are the primary constraints we need to balance to create a great product. Every good product decision needs to be an integration and a tradeoff between primarily these three concerns.

So when deciding how to organize, the big idea is to purposefully optimize for continuous collaboration between the three main product creation disciplines - product management, product design and technical engineering.

The driver behind this idea is that frequent integration between these three disciplines lead to much better product decisions than less frequent integration.

For that frequent integration to consistently happen we deliberately build teams designed to have this form of collaboration on a daily basis.

The focus on “craft” and “makers” here is important. In most product organizations, your best engineers supported by strong designers are often your best problem solvers. However, in most average product companies your engineers do not have first hand access to customer problems. Rather, they are given descriptions and stories about these problems and they then build solutions based on second hand information, or worse.

For designers the situation is often similar in an average product company. In a feature team, the “box” that the designer has to work inside is often very small - make this already decided on solution user friendly, typically a smaller piece where a lot of the details are already decided on. In a delivery team, the box is even smaller, if it exists at all.

Product companies using the principles and concepts in the product model do the opposite, they organize to feature empowered engineers. Those are engineers with direct access to problems, who are “empowered to solve problems”. In a way, what the product model deliberately does is move engineers upstream and closer to customers, so they have direct contact with the problems they will be solving.

Their product designers are also given more responsibility to develop and shape solutions, together with solution engineers.

In the ‘Solve problems to drive results’ article, we introduced the metaphor of the garage startup, with their customer right across the street. In this setup, every engineer will automatically be an empowered engineer and every designer will naturally be involved in selecting the solution and shaping the product experience.

The best product companies are committed to organize this way also at scale because it creates better products.

Common challenges with adopting this principle

Organizing for direct access to customers does not come without its challenges. It takes active effort to make customers accessible from every product team. For every problem to solve, the team needs to identify and recruit customers and users who they believe will help them learn about the problem they are given to solve or to validate their solution ideas.

There will be a cost in time and effort associated with that everytime the team has a new question they need to answer that requires customer access. Minimizing friction and driving that “transaction cost” down is of significant importance to get the product model to work well in practice.

When moving to this way of operating we also need to ensure that our problem solving teams have the competencies they need. Do we have all three product disciplines in place, or do we need to staff, train and coach our people before we can expect our developing product teams to succeed?

‍

Making sure each team has access to the competencies they need, that they have access to customers and that they learn how to collaborate in a way that minimizes handoffs is therefore a product leadership responsibility.

If we expect teams to solve problems, but we do not give them the tools, support and environment they need to succeed - and they instead fail - then that is not just a team failing, it is also leadership failure.

Any plan to transform to this way of operating will therefore need to take into account the starting position and develop the change initiatives that will address any gaps during the learning period that all such organizations are going to need before these concepts and ideas become everyday good practice.

The idea of collaborating with minimal handoffs is in my experience often underestimated. A good way to think is to envision all the activities we need to perform to solve a customer problem as phases of the same work.

A common misconception when first trying to adopt this idea is to interpret the product manager, the product designer and tech lead as its own team - a discovery team - and the rest of the team as a delivery team, primarily responsible for building solutions.

What can be hard to see for people new to this is that such a setup would not be very far away from still having a feature- or delivery team setup.

With a discovery team and a delivery team you will by definition end up with handoffs, because you don’t have any overlapping participation between discovery and delivery. You will not be creating and featuring empowered engineers and you will not be connecting your whole team to problems and customers.

A good way to avoid falling into this trap is to realize that the collaboration we want to create needs to have an overlap in team member participation between all of the above steps required to solve problems.

We want engineers to have exposure to customers and to problems, with no intermediaries. We want PMs, designers and of course tech leads to have participation in solution development.

When realizing this another common misunderstanding is to adopt the expectation that all team members need to participate in everything. That would be a way to overcompensate in the other direction, and that is not necessarily what we need or even desire.

All we need is frequent exposure for all team members, it does not have to be in equal proportion for all problems. We just need overlap in team participation for all the above phases of work required to solve each problem. If we do that our customer centricity will grow strong over time.

A good way to explain this to people used to working in a good feature team is to make the following analogy. Today you do not have a technical design team, an implementation team, a test team, a build team, a deployment team or a bug team, right? We have very few handoffs between these work activities, for good reason. For a given work item, our whole team is not involved every day, right? And still, we all feel a sense of ownership and accountability for that work as a team. How could we treat these new activities as just another phase of work in a similar way?

The value of creating products collaboratively

Without this type of multi disciplinary collaboration to create products your team’s sense of shared ownership for things like understanding problems, confirming that they are actually solved and that we pick the right solution are going to suffer. And if that sense of ownership is weak, we are not going to create a strong product culture where our product people really understand customers and care about driving the results that help them.

If we get it right however, we get effective and capable teams that enjoy what they are doing because they are intrinsically motivated to help solve the customer problems they really understand, in innovative ways, for the customers they are already connected to.

That is a recipe for great products and happy product people.