10 Principles behind great Product teams
“Should we use Scrum, Kanban, or SAFe?” is a version of a question I get asked all too often. I’ve found it’s more useful to answer these questions systemically by looking at what weakness the team has behind the question.
As the ‘Product’ discipline is still developing, there are so many new ways of doing things. I often get asked what the best tool, methodology, or framework is to use for product roadmaps, creating a strategy, or running a backlog. The answer is always the same: It depends.
It depends on your team culture, expertise, and personalities; it depends on your industry and clients, as well as your current systems and tools. Many variables make it impossible to know which tool will work best in each situation. But how do you know where to start?
I’ve realised that by taking a first-principles approach by assessing the strengths and weaknesses of the team, the problem becomes a lot simpler. Comparing a team to the fundamental principles that drive all great teams and then picking a tool/framework/methodology that will help to correct for where your team is lacking.
Here’s a summary of the 10 Principles that I evaluate a team on:
Breakdown of the principles:
You’ve likely heard each of these principles before, and they’re relatively widely accepted. Effectively cliches that are so common they won’t go away. However trite they may be, I’ve found that they offer a valuable lens to be more intentional when choosing a tool or approach for a specific situation.
Below, I break down each principle in this context and explain what actions (⚡️) you can take to implement it and a list of tools, frameworks or methodologies (🛠) that could help. At the end, I’ll cover how I do the assessment and link to a repository that I’ve started building that can be filtered by principle. (These are still WIP, and I’d love some feedback.)
(1) Metrics & measurement
The first foundational piece that every team needs (and that we too often see missing) is actually collecting data on what your users are doing. Specifically, this should be something where you can track actions by cohorts of users (per month, account type or source) and not just generic traffic. i.e. Mixpanel or Amplitude and not Google Analytics.
⚡️ If you don’t have analytics set up, you’re flying blind and can’t do most of the other items on this list properly. Create a Tracking Plan, implement it and learn how to use it. Doing this right is table stakes nowadays.
Once you have it in place, create a few reports of key engagement metrics, how you define activation for your product and a retention analysis chart. Try to avoid focussing on lagging metrics or ones that don’t actually mean much. e.g. instead of tracking the number of sign-ups, track the % of people who signed up and took a key action in the last three days. Ensure they’re action orientated and not just a pat on the back. (Hint: Revenue is nice, but it doesn’t tell you much if it’s not qualified.)
🛠 Mixpanel, Amplitude, North Star Metrics by John Cutler at Amplitude
(2) Customer Centricity
While analytics will give you quantitative data, interacting with customers gives you qualitative data to balance it out. Having multiple team members engage with customers in the customers’ context is absolutely critical for hearing their issues and understanding their motivations directly. Too many teams operate in echo chambers where their picture of their customer is fraught with incorrect assumptions.
⚡️ Take actions like setting up a weekly block for customer interviews and then having an automated opt-in for customers to be able to get added to a wait list where they get sent Calendly invites to join in the time slots to provide feedback. Another is to have developers spend a day a month working with the customer support team to resolve tickets or shadow the sales team for the day. It’s all about creating a routine to lower the barriers for your wider team to engage with customers directly.
When you have multiple team members engaging the customers regularly, you don’t need intricate customer profiles, complex reports or a “customer representative” in the team. First-hand data backed up by analytics are far more effective. Remember that this is for qualitative data collection and creating a shared understanding — be careful not to let your customer innovate for you.
🛠 How to do customer Interviews by Teresa Torres
(3) Learning Loops of Experimentation
With the data foundations in place, a necessary mindset is to think in learning loops. Life is hardly ever black and white. There are always other ways to achieve your exact goals — each with its trade-offs. And you’re going to get it wrong the first time, which is fine.
If you respond quickly to change, it doesn’t matter where you start. Only that you do.
The core lesson from The Lean Startup is to increase the rate of learning. To do that, you run through the build, measure and learn loop as quickly as possible. You often do that by spending less money, but sometimes you need to spend more to accelerate. The trick is to rapidly keep running experiments and learning from the results before deciding what to experiment with next.
⚡️ To run any experiment, you need to have some key elements. Namely, a falsifiable hypothesis of what you believe, a method to describe what you’re going to do, something that you’re going to measure while you do it, and finally, success criteria for what the measurement needs to be for the hypothesis to be true or false. Strategyzer’s Test Cards are a great template for this. This approach also implies a high shipping cadence to deliver new iterations of your product.
This behaviour in a team will help you iterate through many solutions to find what works. It helps you get through what is an assumption and what is a fact — so that you’re not building your house on sand.
🛠 Strategyzer.com is a great starting point.
(4) Instinct informed, data validated.
Sifting through piles of raw data will sometimes help you discover a new insight, but usually, that’s not where new insights come from. It’s far more common for you to stumble across something interesting from qualitative customer data or an idea that sparks in a team conversation. It’s then up to you to find the qualitative data to back that up.
Similarly, identifying a data trend and blindly following it can also be risky. Both intuition and data are important counterweights.
Startup founders are all a little delusional — you have to be to see something that others can’t.
Data is how you don’t get lost in the delusion.
⚡️ Asking: “how might we know for sure?” is a great question to bring some balance to your team. Bringing an emphasis on validating assumptions with a real number helps too — but remember to expect insights to come from the softer stuff.
🛠 Assumption Mapping or Customer Journey mapping can be useful to make your assumptions explicit and easier to test.
(5) Outcomes over Outputs
This saying has become cliché for a reason. Far too many ‘road maps’ are feature release plans. Far too many “experiments” are specific functionality to be shipped and not hypotheses that can be tested in multiple ways. Too often, teams look at the data, decide on a solution and ship just that. They focus on the things that they are building, not the value they are adding.
⚡️ Focussing on the value that you want to create for customers and phrasing your road map as the order of problems to solve is one of the easiest shifts that can have a profound impact on the way your team approaches what you build. Having a definition of done that measures value delivery helps too. One of the huge benefits of this is that Outcomes can be measured, whereas Outputs are shipped or not. Part of delivering value is continually measuring the impact instead of just moving onto the next thing.
When you are Problem-focused, not Solution-focused, you are far more likely to see many possible solutions to any given problem. You’ll start working in trade-offs and compromises — how real life actually works. Remember that there is no ‘right’ way to build a product but if you’re focussed on value delivery, then you’re far more likely to achieve it.
🛠 Now, Next, Later by Jana Bastow from ProdPad is a great tool to help you be more outcomes focussed.
(6) Clear vision to align actions towards
I’m always surprised when founders can’t articulate their vision and mission clearly and compactly. Although often when they can, it still isn’t trickling down as a framework for decision-making throughout the organisation.
Your product strategy, product roadmap, financials and investment strategy are all just different representations of your core business strategy. They need to tell a coherent story of how everything fits together, each with its own angle and detail. If you’re struggling with prioritising backlog items, or evaluating what actions are more important, then you’re probably suffering from this. It would help if you had a better prioritisation framework that stems from your vision, mission, and business strategy.
🛠 My personal preference is this Vision, Mission, and Master Plan template. This typically feeds well into Ravi Mehta’s Product Strategy Stack. Sometimes if a team needs more structure, then I’ll nudge them towards using Flight levels or something similar. Whatever your approach, you need a coherent strategy that ties it all together as it makes the 1000s of smaller decisions so much easier.
(7) Acknowledging uncertainty
Traditional business loves certainty. Many executives that haven’t built software before — and a scary number who have, insist on committing to a plan of fixed items and release dates. Because of alignment and dependencies. But as anyone who’s tried to ship software before will tell you: there are always unknown unknowns. (And don’t get me started on Gantt Charts!)
Being Agile means, well, to be agile. It means things will change, and it means your systems need to adapt. Roadmaps should focus on sequencing what is most important, not timelines. If you spend the entire year only shipping and improving the most important thing on your roadmap, that’s the right thing to do. Yet I’m always surprised how often people just move to the next thing on their list.
⚡️ Speaking in terms of “bets”, “goals”, “hypothesis”, and “assumptions” instead of “features”, “releases”, and “deliverables” goes a long way to shifting the way your team thinks about certainty. Always communicating dates as ranges is another way to make the uncertainty ‘visible’. Subtle shifts in language and structure can go a really long way to helping your team have the right conversations.
(8) Shared accountability & ownership
Great teams wake up every day thinking about how they improve the product for customers and the business. It’s not just one person’s ‘job’. In teams where everyone takes accountability to deliver value, they are engaged, interested and collaborative.
⚡️ Is one person in your team making all of the decisions? Do you have the autonomy to try things that you think are worthwhile and have the platform to voice those? Does the rest of your team? Answering these questions and then reflecting on improving the status quo can help you achieve this. (It also plays very well with the next point on cross-functional teams…)
🛠 Marty Cagan’s book Inspired and this post is a great start
(9) Cross-functional inputs & decision making
Diverse teams aren’t “stronger”; they’re more resilient. They’re more adaptable, and the creativity from a broad range of backgrounds brings unique perspectives that will deliver more robust solutions. The evidence has been shown time and again.
We’re most blind to our own bias.
It’s worth noting that diversity matters in gathering the inputs and collecting ideas as much as making decisions and commitments. The bias is different but has the same effect. I often find that teams may be diverse in creating inputs, but the decisions always get made by the same group of people. Being aware of and adjusting for your biases and blind spots are going to make you a better team.
⚡️ Think of the last planning meeting or workshop that you had. What was the breakdown in gender, race, socio-economic background, seniority, and technical or functional skills? Now think of 1–2 people across your team that you could include next time to make it more diverse. If you can’t think of someone, then you probably need to hire for more diversity. It’s not about quotas or representation — it’s about better-performing teams and more holistic inputs.
🛠 I’ve always found the Insights Profiles to be the most useful for personalities and ways of work.
(10) Being adaptable & Team empowerment
When you have a clear vision (6) and acknowledge uncertainty (7) with a cross-functional team (9) that has shared accountability (8)… then it’s best to get out of their way. If you’re doing well on the other items but still micromanage them, then you’re missing most of the gold.
“Never doubt that a small group of thoughtful committed individuals can change the world. In fact, it’s the only thing that ever has.” — Margaret Mead
I’ve always loved these definitions: Responsible: has the ability to respond (without approval). Accountable: is held to account if it fails.
Giving a team responsibility and autonomy to respond in whatever way they see fit is incredibly empowering, particularly with the rest of the principles. It creates ownership and purpose and is great for motivation and job satisfaction. But making them fully accountable can backfire if they haven’t opted in. It takes a lot of trust to let the team run with something but you still be accountable. In my experience, doing this has been the most rewarding.
How to evaluate your team
I’ve explored more technical options with a series of weighted questions to evaluate how your team lives these values. But, honestly, they got overly complicated and didn’t add that much value — despite technically having more scientific rigour.
What I found more practical and faster is to evaluate how your team performs on each of these on a scale of 1 to 10. Each time I’ve done this, there are typically 2–3 areas that the team is weakest at. Those are the areas to focus on. You can then identify changes that can help improve these areas.
This process is not an exact science, but I have found this approach is a useful way to think about which tools compensate for where your team is weak. It also permits teams to adapt the tool/framework/methodology for their situation and empowers them to drop it and adopt something else as their situations change.
I am building out a repository of tools, frameworks and methodologies that these principles can filter, so please let me know on Twitter, LinkedIn or reply to this post with what you use or would like to add.
Thanks to Luke Naude and Pat Carmody for providing feedback on this post.
