GROWTH BLOG: Top ten product discovery mistakes: How product teams get continuous discovery wrong
AKF Partners Logo Technology ConsultingScalability - We wrote the book on it ℠

Growth Blog

Scalability and Technology Consulting Advice for SaaS and Technology Companies

Key skills for adaptive product teams

March 31, 2020  |  Posted By: Tanya Cordrey · 6 min read

Adaptive product teams key skills

There is growing recognition for the need for adaptive product teams.. The process of delivering software may be very similar across almost all companies but there is a need for product teams to empathise, evolve and adapt to different company cultures, industries and geographies. 

How do product teams know when they need to embrace the adaptive product teams model approach? Which type of teams are most at risk of becoming disconnected from the rest of their organisation? And what are the key product team skills required?

At AKF, we see certain situations time and time again. For example, a firm starts on the journey to become product and tech-centred. This is usually complemented by the hiring of a new team or high profile leader or there are multiple proclamations of intent from the CEO. Love for all things product grows within the company. But after a short period, when the rest of the organisation begins to understand fully the implications of building a strong product and engineering function, that product team love often plummets.

‘It would not happen to me’, you say. Well, let us tell you a story of a chief product and technology officer at a large B2C legacy company.  The CPTO and the team were delighted with their progress. They had moved to best in class ways of working in software development, revenues and user engagement have reached record levels, and a new product and tech strategy had enthused and excited the team.

Sounds great? But then, at an executive awayday, one of the most senior and respected members of the exec team stood up and gave a speech on how the introduction of product management and agile software development was:

  • a threat to the culture,
  • a threat to retaining key talent in areas such as sales and marketing,
  • and a threat to the very being of the organisation as the staff had no desire for it to turn into a Google or Amazon or Facebook.

This CTPO was stunned. She thought the organisation was proud of the team’s successes and had become comfortable with the new ways of working.

How could she and the team have read the situation so wrong? 

Afterwards, when trying to subsequently unpick the problems they faced, they realised:

  • When the team talked about the role of product management - the organisation felt their long-established responsibilities were being taken away
  • When the team talked about process - the organisation felt that this was a way to brush aside their opinions
  • When the team talked about this is how you do great software development - the organisation felt they were acting with a cult-like mentality. ‘Worshipping at the altar of the Agile,’ to quote a frustrated CEO

It appeared the team was doing everything right in terms of how you build great products - EXCEPT they were failing to take the organisation along with them. 

So how do you know if you or your teams are not aligned with the rest of your organisation?

Well, the truth is, you probably feel it in the pit of your stomach. But in conjunction with these pit of the stomach feelings, do you recognise any of these?

  1. There is talk of setting up a Project Management Office (conversations about the need for more governance is often a clear sign that something is not working)
  2. There are painful conversations about who owns the customer or who understands the customer best
  3. You cannot put forward platform or essential tech debt projects as there is no support from the rest of the business
  4. Or finally, other departments outside product and engineering want to debate principles such as agile, mvp or discovery.

So how do product teams find themselves in this situation time and time again? There are two dominant groups within product which often fall into this trap.

Optimisation optimists who are overly-confident in their view of the world and ignore the need for a compelling product strategy. The result? They are stuck in a constant cycle of optimisation which offers little more than diminishing returns.

Framework fanatics who make process - rather than outcomes - their North Star.

Optimisation optimists

Teams can see low hanging fruit. And of course, it makes sense to improve experiences for the user. But teams need to weigh the opportunity costs of every decision.

Just because an initiative may improve a metric or improve things for the user, does not mean it should automatically be done.

A good idea is not the same as a great opportunity.

We have yet to meet a product team that suffers from a shortage of good ideas. But we have met many teams that have clogged up their roadmaps with lots of good ideas that cumulatively have had little impact.

Saying yes to every good idea, however small, means you are not making time for the great opportunities.

It is often said in our industry that if improve things for your users, the value will follow. That is true. BUT it is the job of a product team not to just identify ANY opportunities but to identify those that will create the MOST value for the users AND their company.

Framework Fanatics

As a discipline, we are spoilt with the number of processes and frameworks.  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 How we do it becomes the focus. And there is often little regard to the environment of the broader organisation.

We have even met product teams who define their mission as being ‘exemplary at agile’. Agile is not a strategy.  It is a capability, a very valuable one which has immediate operational benefits, but one that cannot permanently affect a firm’s competitive position unless there is a strategy behind it to help the team take the right decisions at the right time.

If you recognise elements of your team in the description of Optmisation Optimists or Framework Fanatics, you are at risk of causing a disconnect between the product and engineering teams and the rest of the organisation.

So what are some of the key skills needed within adaptive product teams?

Awareness of your context: Recognise the the need for adaptive product management and work out where your organisation and your team fit in the model and understand the cognitive load you bring to areas outside your department. Teams regularly need to set aside time to assess their stakeholder relations and course-correct where needed.

Building shared vision and goals. If teams are not aligned across the organisation,  product teams will likely suffer at every step. Adaptive teams also put data front and centre. It is difficult to change an organisation or improve working relationships if constantly debating opinions.

Communication: This needs to be part of any product team’s operating model. Make communications an overt task not just a nice to have. Build communication skills into job specifications and career progression frameworks. If you are a manager, add it as a recurring topic on one-to-one agendas with your team. And make sure you you are focused on effective communication.

Collaboration: Both in strategy and execution; Every great product team, in whatever quadrant of the model, needs to have a great strategy.  Look to develop ways to do this collaboratively with the rest of your colleagues. Strategy done in isolation often falters.  In terms of execution, adapt working processes to suit the environment. Sounds small, but having key colleagues from outside your team sit in the same area or attend stand-ups, can make all the difference.

Be open: As described, don’t be too rigid, especially about process. For example, consider adaptive roles suitable for your quadrant. When we look at our industry, the more mature teams are often more cross functional. Consider other people as part of the sprint squad where appropriate. For example, if you are in the product amplifier quadrant, would your team benefit from having an ‘expert’ on the core, non digital, product such as journalism or a physical product?

 

Next: Technical Debt for CIOs Leads to Organizational Debt for CEOs

Categories:

Most Popular: