One Size Does Not Fit All Sweather Label

Image Credit: AzoraArashi Flckr

‘As such, there is no one-size-fits-all approach that anyone can offer you. The hot water that softens a carrot will harden an egg’,

– Clay Christensen, How to Measure Your Life

Many product teams today fail to understand the basic concept that a one-size-fits-all approach will not set themselves or their organization up for success. Why? Because time and time again we as an industry are guilty of prescribing the same set approaches and the same set processes to different organizations, different cultures and different industries.

We need to shift our thinking away from believing teams are collections of interchangeable individuals with certain skills like PM, engineer and UX that will succeed as long as they use the right process.

Instead we need to understand that different organizational contexts require different actions and behaviours.

Understand the Organizational Context

Unfortunately one of the common themes we hear from CEOs is how hard and painful their organization finds building a product and tech team and culture.

In fact, it is not uncommon for the product managers to feel like the most unpopular people in their company. Feeling unpopular is not necessarily a bad thing. A product manager’s job is always going to make them unpopular at times. The role is to balance the business needs and the user needs. Product managers cannot make everybody happy all the time.

BUT – when do you know that you are bumping up against normal day-to-day pressure and resistance Vs creating a pressure cooker of declining trust and growing resentment?

Unfortunately we increasingly see product teams trying to do everything right in terms of how to build great products – EXCEPT they are failing to take the organization along with them.

As a discipline, we are spoilt with the number of processes and frameworks.q But product management is not painting by numbers. Frameworks, rituals and process are a guide - not the solution.

Too many teams today are making their role about the execution of the process, rather than the impact of the work. In this model, The What we do and the How we do it becomes the focus. And there is often too little regard to the environment of the broader organization. As we have written before, you need to start with people first, approach second.

Cognitive Load

A great book was recently published called Team Topologies: Organizing Business and Technology Teams for Fast Flow by Pais and Skelton.

They talk about how to organize teams for effective working. One of the key themes is how to manage the cognitive load of a team. Too much, a team becomes less efficient and less effective.

But product teams rarely think about the cognitive load that they bring to departments outside Product and Engineering.

So product teams need an adaptive approach. Today we want to share a new model for adaptive product teams - on the modes of product team engagement. The objective of this model is for teams building products to understand that it is not just about doing it the right way – but also about ways of doing it right.

The X Axis of Adaptive Product Teams

The X Axis is which team has the closest relationship with the customer.

On the right you have product teams which are the closest team to the customer. But in some organizations, even where there is strong product focus, other teams may be closer to the customer. For example, enterprise software firms where the sales team may have the closest relationship with the customer

The Y Axis of Adaptive Product Teams

The Y axis looks at the type of organization and product. This defines whether you as a product team make the actual product or not. For example, on a news site like the NYT, the real product is the journalism.

Each quadrant recognises the different stresses and strains on these different types of product teams. The process of delivering products may be very similar in each quadrant but we kid ourselves if we don’t recognise the need to emphasise, evolve and adapt.

So What are the common pitfalls we regularly see in each quadrant?

AKF Partners Product Model

Models make things seem simple. The truth is there are probably elements of each quadrant that resonate with product teams. For every senior product manager needs to do thought leadership as part of their role.

But it is unlikely that you can do this successfully if you have not built a foundation of trust and credibility which, depending on your environment, comes from partnering , enabling and amplifying as well as thought leadership.

Here are some of the key attributes that we believe product teams need to have front and centre when engaging across the broader organization. These are "must haves" – not "nice to haves."

So ask yourself, are you explicitly doing these things in your relevant quadrant? If not, how can you?

Here are some examples:

  • If your team is in Product Partners, look to establish join customer discovery with shared KPIs.
  • If your team is in Product Thought Leaders, look to ensure your operating model includes an overt strategy process.
  • If your team is in Product Enablers, make sure you have a stream of educational work to help stakeholders and executive team know what good product development looks like.
  • If your team is in product amplifiers, consider new roles that allow for the non traditional experts to be part of the process.

A couple of final provisos; We are not asking product teams to be soft and compliant. Teams need alignment and collaboration. They don’t need constant consensus. Not everyone has to agree with everything, but they all need to have input. Get this right and your team will significantly reduce its cost of distractions.

Secondly it is important not to compromise the spirit of small autonomous teams. Team bloat is an expensive anti pattern and large teams do not build trust.

Finally if you were to do one thing this week, look at your communication. We have yet to ever meet a product team that does this too much. Regular communication is often neglected but one of the easiest, fastest and cheapest ways to reduce the cognitive load that you bring as a department.