The 4 Elements of Effective Product Teams
A model for making sense of, levelling up, and having a good time in your Product Practice
Itβs a truth universally acknowledged that a Product Person in possession of a few good years of experience must be in want of a bespoke approach to his practice. I am, alas, not immune to this.
How can a Product Team choose the most effective course of action at any point in its journey? After working in and around dozens of Product teams, I started seeing patterns in what makes them effective and cohesive. Like the 3 Conditions for Success, these emerged through a diagnostic lens: Why is this team struggling to produce meaningful outcomes? What will enable the team to level up the quality of their work and have a good time doing it?
So here is the core of my model for a Peachy Product Practice and answering these questions. Iβll introduce the 4 Elements1 that a Product team needs to continually assess and balance to be effective and content, and a taste of how to make the assessment. The Elements are:
π― Clear Goals
π¦ Landscape Awareness
π₯Ύ Balanced Empathy
π¨ Creative Capacity
I visualise these on an π Elements Diamond πΒ which is to be used like a simple Radar chart:
What the Elements mean
Before we jump into an example, some definitions:
π― Clear Goals
The ability of team members to connect their work to intended real-world results, whether directly or through intermediate steps. This can come in a variety of guises such as: Product Vision -> OKRs -> Epics -> Stories, Jobs-To-Be-Done, Opportunity Solution Trees.
Some activities that can strengthen this element are: OKR setting and reviews; North Star metric creation; Backlog grooming and refinement.
π¦
Landscape Awareness
Market and domain knowledge: other players and existing solutions in the market and the trends within them, structural/cultural/legal/technical obstacles and opportunities on the horizon. This element is usually at play when weβre talking in terms of aggregates, analyses and generalisations.
Representative activities: competitor analysis; customer data analysis; commissioning and summarising industry reports.
π₯Ύ Balanced Empathy
The range and depth of understanding of the key people involved inside and outside the company. This is individuated knowledge, nuanced, and highly context-dependent. Balancing empathy is usually at play when weβre considering stories about an individual user, customer, colleague, external partner, or reconciling things that stand out as anomalies to the generalisations, analyses and assumptions weβve made elsewhere.
Representative activities: generative user research; stakeholder interviews; immersion into user forums; corresponding with a government representative.
β οΈ This element is particularly tricky to get right. Itβs well-accepted that Product teams need to develop empathy for their users and customers to deliver good products, and in an ideal world that aligns many of the players in the business. But the reality is that stakeholders from the most senior to the most junior have their particular personalities, political realities and incentives that need to be considered, and there are lawmakers, external partners and vendors with their own goals. Product Managers are often on the sharp edge of these interpersonal challenges whilst shielding their teams from it, so this element can seem opaque and mysterious.
Here is an example of an often-overlooked experience Product Managers have that is heavily reliant on considering complex relationships and Balanced Empathy:
Say a decision has been made to roll out a new pricing model for a freelancing platform as a result of employment law changes and needing to reduce the risk of lawsuits from freelancers. This means considering the users & customers (obviously) before communicating the changes. Behind the scenes, however, there are many conversations to align the Chief Science Officer who disagrees with the risk calculus and decision, with the CFO and CPO who are sponsoring the work. It also means mitigating the financial impact on companies hiring freelancers on the platform, and ensuring the Account Management and Customer Success teams on the frontline are updated and have processes for switching customers over to the new pricing as oon as possible.
π¨ Creative Capacity
The quantity, quality and novelty of the solutions a team can deliver, test and iterate on. This element is dependent on the experience and skills of the engineers, designers, marketers etc. but also the levels of autonomy, motivation, and collaboration that their environment enables.
Representative activities: technical spikes; high-fidelity prototyping; continuous deployment; usability testing.
So how do I use the Elements?
The actual assessment process is an art that Iβll expand upon in future posts. Here I want to give a flavour of how to make the assessment. What I will say for now is that assessing the Elements of a team looks like a mini-Due Diligence process that an investor might carry out before funding a company. Itβs more qualitative than quantitative and is most effectively done through frank interviews with key leaders and operators in the business. I always find one Element stands out as the strongest or weakest, and the other Elements are assessed relative to that, rather than in absolute terms.
Once I have a sense of the strengths and weaknesses of a team across each Element, it becomes relatively simple to suggest the highest leverage Element to focus on and possible activities to implement.
An Archetypal Example: The Overthinkers
Imagine an overly analytical B2B Product team, letβs call them the Overthinkers. They are staffed mainly with analysts and engineers focussing on the latest market opportunities & technologies but missing design & qualitative research skills. They have one person acting as de facto Salesperson, Account Manager and Customer Success representative all-in-one.
This teamβs goals are overly skewed towards financial targets at the expense of improving metrics representing user experience and needs. In interviews with the senior team members, there is barely any mention of user personas, spotty awareness of feedback from prospective or existing customers, and several puzzled expressions when I directly ask βWho is your ideal customer?β. They are overly fixated on βHow do we get more sales without having to hire more salespeople?β.
The several engineers on the team are experienced and skilled but seem to spend a lot of their time jumping from one project to another, so despite their talent, they donβt create much and feel rudderless unless thereβs an immediate fire to put out.
The Overthinkersβ Elements Diamond would look like this, with π¦ Landscape Awareness as their strongest Element and relative to that, other Elements are medium and weak:
So what do? The following is my initial recommendation for this team:
Focus on strengthening their Balanced Empathy first: bring in a User Researcher or Service Designer to improve their understanding of the B2B sales and onboarding process and the obstacles customers face in that journey. Identify the different types of customers and their needs.Β
The strengthened Empathy will then feed into strengthening the other weak elements. Hire a Product Manager experienced in Product Discovery who can mix this deepened understanding of customer needs with the analyses that the team is already good at to turn their obstacles into tractable problem statements, prioritise which customers to target first, crystallise the high-level commercial goals into OKRs that can be tackled over a few quarters and work with the whole team to design hypotheses and experiments to verify theyβre on the right track.
Kick off the design and development of initial solutions, and start working on branding and messaging for the chosen target audience. This is all to be minimally scoped, tested and iterated on.
Visually, these activities would result in the following transformation for The Overthinkerβs Elements Diamond, keeping their high π¦ Landscape Awareness as their existing strength and balancing out the others with the increase in π₯Ύ Balanced Empathy as the lever:Β
More easily said than done (particularly the culture change aspect), but that's the idea and I find that once shared with the team, this type of assessment smooths the way for the changes to come.
I find this example to be prevalent in many teams founded by technically-minded folks or ex-academics. By contrast, in the charity and #TechForGood world, Iβve found a common tendency to be strong on Balanced Empathy with major weaknesses in Landscape Awareness and Clarity of Goals.Β
So, back to the theory.
Navigating Product Management with the Elements
Working with the Elements Diamond reveals the cyclical and non-linear relationship between the types of work that happen in a Product team2.
Identifying the weak and strong elements within a team leads to bolstering the weak areas, but over time the balance shifts, the previously strong elements become weak and the focus of activities moves to restrengthening them. For example, after some Discovery work which strengthens Balanced Empathy and Landscape Awareness, the Clarity of Goals improves, and more creative solutions can be deployed. However, during the delivery and iteration of solutions, Empathy and Awareness will atrophy, because the landscape is changing or we discover we could serve a different segment of users than originally intended or refine our goals with a new understanding of the user after testing our solutions with them.
You might see this as a different perspective on the classic Double Diamond that models the design process, representing the divergences and convergences inherent in designing anything. What makes the Elements Diamond more useful is that it can be applied at any point in a team or product's lifetime and produce tailored guidance for that context. Importantly, it allows for thinking about Discovery and Delivery happening at the same time or in unorthodox orders3 or by non-traditional roles, whether that's a decision to hire a researcher in the middle of planning a big launch or to clean up the codebase to unlock capacity, or for a Finance Manager to double up as an Analyst in a pinch.
This leads me to some subsequent definitions of commonly used concepts in terms of the interactions between Elements. Iβve taken the four stages of Discovery, Definition, Development and Delivery that are familiar to many of us and shown how they are represented by the Elements Diamond.
The solid arrows in the following diagrams can be read as βstrengtheningβ an Element, and dotted arrows as βconstrainingβ.
Discovery (π¦
, π₯Ύ)
Discovery is the process of creating more π¦ Landscape Awareness and π₯Ύ Balanced Empathy so that Clear Goals can be defined. Discovery is an exploration and expansion process and can be visualised like this:
Definition (π― = π¦
Γ π₯Ύ / π¨)
The Definition of Clear Goals is then a process of convergence and decision-making, informed by the findings in our exploration and constrained by available π¨ Creative Capacity. This is often a sobering moment where ambitions and excitement meet reality, but it can also be an opportunity for getting out there to find more talent, funding and autonomy for a Product team now that it is backed by a convincing narrative and rationale from Discovery.
Development (π¨ = π― / π¦
Γ π₯Ύ)
With well-Defined Goals in hand, the makers in your team can start Developing candidate solutions that meet the needs and constraints youβve Discovered across your landscape and on the ground amongst your users and stakeholders.
Delivery (π¨ x π― = π¦
, π₯Ύ)
Delivering and testing your solutions hopefully not only meets some of your Goals but perhaps more importantly, will give you feedback for future iterations. Delivery directly leads back to Discovery since thereβs nothing like an actual product out there to test your assumptions both about your landscape and your customers and users. This new knowledge leads you back to refining your Goals.
And Finally, Product Practice
Product Practice is facilitating and maintaining a balance of the 4 Elements such that cycles of Discovery and Delivery lead to Sustainable and Scalable solutions to real-world challenges.
I intentionally don't mention Technology in this definition, since it's simply one (even if the most common) means for achieving Scale and Sustainability.
We have Scalability when putting X amount of investment into a solution creates much more than X result (i.e. a greater-than-linear relationship). Technology helps here, but it doesn't have to be fancy. Sometimes the cultural & operational changes to support such a solution are harder, for example moving from a traditional sales process to SaaS subscriptions.
Sustainability is about the longevity and elegance of the solutions along several dimensions: financial, operational, ethical, environmental, and yes technical. Which of these matters will be highly dependent on the organisation's values and long-term strategy.
The cycles part of Product Practice is important and what makes it a Practice - you keep learning and doing within an ever-evolving context. MVPs, concierge tests and quick and dirty hacks are all stepping stones towards well-oiled systems that need minimal intervention over time and can evolve into simpler Operations or Project teams. The accrual of Product and Technical Debt is part of the cycles, but so is paying them down eventually, or π¨ Creative Capacity gets stifled.4
So whatβs next?
At a Product team level, this model is useful for: strategic decision-making, getting everyone on the same page, resolving 'roles & responsibilities' conflicts, hiring and team configuration changes, asking for support from outside the team, and more.
You may also have the following questions:
How do you assess a team and identify ways forward?
What does this mean for different roles in a Product team (not least, the Product Manager)?
What's the interaction between these Elements and the Conditions for Success?
I'll be exploring these soon π€.
In the meantime, how would you assess your (current or past) team on the Elements Diamond? What does it tell you about where you need to focus? Drop me an email or DM with a doodle and/or your reflections if you take a minute to do this exercise!
Psst, if you want to improve your Product Practice, Iβm available as a Product Coach for 1:1 offerings or for larger projects - take a look here: https://hajizamani.com/
Expanding on this 2021 Twitter thread where I first shared anything publicly about it: https://twitter.com/amirhhz/status/1450112487332978700
If youβre wondering how I distinguish βProduct teamβ from other types of team (namely, Project and Operations teams), I wrote about that in my last post.
The classic Double Diamond does not strongly suggest that the processes of Discover, Define, Develop and Delivery occur linearly but in practice, Iβve seen teams contort themselves into linearity when itβs not necessary.
Someone please remind me to finish my draft about Technical Debt and the Half-Life of Requirements, please