Why Product Teams Can’t Work in All Companies

To have true product teams requires a new leadership and organisational paradigm not seen in most companies.


Last week, I tweeted this in response to Marty Cagan’s recent article on Product vs Feature teams. My comment seemed to resonate with some people, but it’s very generic, so let’s explore this topic in more detail!

What are Organisational Paradigms?

An organisational paradigm is a stage of development determined by the perspective, point of view, or world-view of an organisation. This perspective dramatically affects the way of working within the company. 

In his work on organisational development, Frederic Laloux defined five paradigms, red, amber, orange, green and teal, that describe the major stages of organisation development. For the sake of simplicity in this article, I’ll focus on just three of them:

Amber:  At this stage, organisations strive for stability. They have clear roles and ranks within a hierarchical structure. Leadership is command and control with stability and order enforced through rules and processes. Innovation is not encouraged, and competition is viewed with suspicion.

Orange: At this stage, organisations see the world as a complex machine whose inner workings can be investigated and understood. Leadership changes from command-and-control to management by objective generally focused on competition, innovation and performance.

Green:  At this stage, organisations strive for harmony, tolerance and equality. They usually keep a hierarchical structure but focus on empowerment to lift motivation and to create great workplaces.

Many governments and large organisations today operate from either the amber or orange paradigm, and this has a significant impact on their ability to manage product teams.

Why do Product Teams Require a Different Paradigm?

Empowered product teams are cross-functional; measured by outcomes, and empowered to find the best way to achieve the results they have been asked to achieve. These teams must be allowed to make decisions and take responsibility for them, yet in many organisations, product teams are not empowered to do this. 

The reason these teams lack empowerment is ultimately down to the paradigm the entire organisation operates within. I believe it’s impossible to have genuinely empowered product teams within organisations that work at either the Amber or Orange paradigm because the leadership model is based on principles that contradict the trust, autonomy and collective responsibility required to enable teams.  

How Can Organisations Shift Paradigm?

Consciously or unconsciously, leaders put in place organisational structures, practices, and cultures that make sense to them and their way of dealing with the world. As far as we know, there aren’t yet any organisations that have evolved beyond their leader’s stage of development. A switch in paradigm requires leaders to either pull the organisation toward their stage of consciousness or push it back to a previous paradigm.

To demonstrate how leadership can shift the organisational paradigm lets look at an example from Reinventing Organisations. 

Let’s say I am a Product Manager who naturally operates hierarchically, telling team members exactly what to do and how they need to do it. Now imagine a new leader arrives who urges me to empower the employees that work for me. Around me, I see other product managers giving their teams decision making power. Then at my quarterly review, I receive feedback from my team telling me how well I’m doing on empowerment and how much they enjoy working in this way. 

Within a dominant context of culture and practices, my management skills and behaviours will likely shift. The environment has pulled me up, and perhaps, over time, I will genuinely integrate into that paradigm.

To have genuinely empowered product teams, I believe you need organisational leaders that operate from a paradigm that encourages autonomy, self-management, collective ownership and, above all, trust. 

In many ways, having leaders that could create an environment suitable for product teams is actually about creating a product organisation. Undoubtedly, this is a much more significant undertaking than relabelling delivery teams as product teams, but ultimately, it is essential if you want to gain the value that comes with a genuine organisational paradigm shift.

Embrace Constraints For Startup Success

Image from Salesforce

I’ve always felt founders should be wary of raising money. An investor writing a check can feel like validation that your company is on the road to success, but be careful. Are you just avoiding the challenge of market validation?

In the early stages, before you find product-market fit, I think you are better off without much money. This lack of financial resource is a considerable constraint, but when you don’t have money, you need to make money. And to make money, you need to build a successful business.

The constraints that limited financial resources put on your startup will make you focus; think creatively, and drive you to early market validation.

Invest in yourself, reinvest in your business and increase your upside when you succeed.

The Product Value Equation

In his book, Scaling Lean, Ash Maurya introduces the product value equation. I believe this simple but important equation holds the key to understanding any business model as it demonstrates how customer value, revenue and costs are linked together.

The first part of the equation shows how your business generates value. Your product must create more value for your customer than you try and capture back from it. Essentially this means your product or service must be worth more to your customer than they have to pay for it otherwise they won’t have the incentive to use the product in the first place.

The second half of the equation shows how you monetise the value you’ve created. Simply, the cost of creating value for your customers must be less than or equal to the value you can capture back from them.

When launching a new product we tend to focus on the first half of the equation, trying to provide value to our customers and demonstrating our ability to capture some of this value back. Being able to do this repeatedly, is the key to gaining traction with your product.

Once we demonstrate traction we begin to think more about the second half of the equation. We can either reduce our costs or increase our price but eventually, we need to ensure that the captured value is greater than our costs so we can turn a profit and run a sustainable business.

As product managers we are always trying to balance this equation, but we don’t have to successfully balance it from the outset. It is through iterative experimentation that we can gradually adjust the numbers within this equation until we have a sustainable model.

If you’re interested in learning more about how to model your product and run experiments to balance the product value equation my colleague Monira Rhaimi and I did a talk on this very subject! I hope you find it useful!

The Three Types of Product Management

A few months ago I was asked to speak at a ThoughtWorks event about what a Product Manager does. This turned out to be very difficult to explain and speaking to other Product Managers didn’t help gain much clarity either!

People are rightfully confused as to what a Product Manager does and to be honest I think they always will be as the vague nature of the role is in essence why product managers are valuable in the first place.

I’m not going to try to end this confusion, or claim I have a solution. I’m just going to propose that you start first by looking at the problem your product is trying to solve and then consider what kind of product management you need for that problem.

I believe that most products fit into three problem archetypes: Experience, Business Model or Tech.

Adapted from original diagram by Martin Eriksson

The ‘Experience’ Problem
In domains that are technologically “solved problems” and leave little room for business model innovation the problem your product might be solving is around user experience. 

Products such as Trello or Slack fall into this category because it is their customer experiences that provide their biggest differentiator. In this case PM’s that come from a design background are most suited.

The ‘Business Model’ Problem
In domains with a familiar customer experience that utilise commodity technologies, your product may be trying to disrupt and differentiate with an alternative business model.

Products like Deliveroo or Uber fall into this category because they have provided a different business way for customers to transact with existing services. In this case PM’s that with previous commercial experience are best suited, for example, startup founders or those with sales and marketing experience.

The ‘Tech’ Problem
In domains where the user experience is simple, and the business model is already proven elsewhere, it is often improving the tech that differentiates a product from its competitors.

Most of the products Google creates are good examples of this category. Google users care most about finding what they want quickly, and Google’s technology enables them to do this better than anyone else. In this case it is often PM’s with technical backgrounds, such as software engineering jobs or computer science programs who are best suited.

In Summary
What good product managers do, and where to find them, varies greatly depending on your product, strategy and maturity. It’s unlikely, if not impossible, to find one individual who possess all the capabilities, approaches, and values needed to solve any type of problem.

A better approach is to understand what type of problem your product is addressing and find PMs with strengths in the areas you need most.

If you would like to read more on this topic I recommend checking out this post by Dan Schmitt and this one by Daniel Demetri who both influenced my thinking.

Todays Products, Tomorrows Platform Capabilities

On March 14, 2006, Amazon Web Services launched EC2, enabling users to rent virtual servers to run their applications in the cloud. EC2 was a revolution and grew rapidly, but overtime, what previously differentiated the service became commoditised as competitors developed similar products.

Then in 2014, Amazon launched another revolutionary product, AWS Lambda, a serverless computing platform that enables customers to run code without setting up servers in EC2. Amazon was the first mainstream cloud provider to launch a serverless product, again differentiating themselves from their competitors. They managed to get to market quickly by building on the existing capabilities of EC2.

Eventually, Lambda will become a commodity service, but Amazons next revolutionary product could be built on the capability Lambda provides, just as Lambda was built on EC2.

So, how can you do the same as Amazon and turn today’s products into tomorrows capabilities?

The first step is to understand what capabilities already exist in your product. To find these consider which components of the product could provide value to a potential customer independently. For example, most products have an authentication system, if you have built your own, you *could* sell this independently.

Next, you want to understand which of these capabilities could provide unique value to a potential customer. In the case of authentication, it’s unlikely your system is much different to anyone else’s so it probably won’t provide unique value. In contrast, the ability to run any function in the cloud with no infrastructure setup would be a great example of a core capability.

These unique, core capabilities are the ones to invest in. As Adrian Cockcroft, says “Don’t do your own undifferentiated heavy lifting”, focus your resources on building core capabilities that are differentiators. You should turn these capabilities into services with interfaces that can be utilised by your existing product, new products and maybe even sold to external customers.

Equally, you should stop investing in undifferentiated capabilities, like authentication, which you can buy from external providers. The time and money spent on ‘undifferentiated heavy lifting’ is much better invested in innovation activities that extend upon your core capabilities rather than reinventing the wheel.

As the speed of innovation continues to increases so does the time it takes for a new product to become commoditised. To reduce the risk of competitor disruption organisations need to find ways to enable faster product evolution by creating enablers of innovation and removing organisational constraints.

ThoughtWorks Digital Platform Strategy

Creating interfaces to core capabilities is one of these enablers. Provided as a self-service platform, these capabilities allow teams to build on what came before, leading to faster innovation. They also increase the number of new products you can launch, boosting the likelihood of you finding that next successful product.

The Product Management Talent Challenge

The role of a product manager has evolved dramatically from it’s origins at Proctor & Gamble in the 1930’s where PM’s sat within the marketing department representing the “voice of the customer” to being seen as a part of the engineering function during the rise of the technology disruptors, and then more recently beginning to be considered as a stand-alone function on its own.

During this time, the breadth of activities product managers participate in has grown considerably and now crosses multiple organisational functions. The McKinsey Product Management Index highlights just how many activities demand the attention of modern product managers.

As you can see product managers are playing an increasingly central role to influence every aspect of making a product successful. Indeed, as more companies become innovation-focused, product management is becoming key to the success of the whole organisation.
Because of this CEOs and technology leaders often identify the role of product manager as one of their top talent priorities and some of the most forward-thinking organisations are elevating product management to an executive level function to drive the product mindset across the organisation.

But despite the value product managers’ bring and the central role they play in software organisations it is common that the role is misunderstood.

This lack of understanding has led organisations to under-appreciate product managers and underinvest in the development of their product management capability. The McKinsey Product Management survey found that:

  • Only 35 percent of product managers have clarity on what it would take to advance their career at their current company.
  • Only 20 percent said their companies had highly effective programs to identify and retain the best talent.

If you want to develop a world-class product management function it requires a multi-pronged approach but I believe there are a few key areas to focus on:

Develop a product management leadership model – Clearly articulate what the organisation wants and expects from its product managers. This should be behaviour led and inline with the organisations strategy and priorities. Not just a shopping list of skills and capabilities.

Design an end-to-end learning journey – Look to develop a bespoke career development pathway that teach core principles first and develops skills that can be applied in daily work rather than generic or aspirational training.

Make hiring a strategic priority – Understand what your organisations value proposition is for prospective candidates and develop interview approaches that assess for the real-life skills you need. Ensure existing product managers have time allocated to interview.

Over the years I have seen the challenges organisations have faced developing career paths for engineers, designers and now product managers. I’m intrigued to see how others will look to develop and support these roles in the future.