If someone asked you that question how would you answer it? Maybe you point to qualitative research or find some metrics which may suggest customers are getting value from your product. Or perhaps you use things like your product Net Promotor Score (NPS), bookings or MAU growth over time.
This view of a successful product is through an external lens. A lens which is often lagging and reflective of work done in prior months, or sometimes even years. Do we ever stop and reflect on this question through an internal lens? How do you actually know you’re doing a successful job as product managers?
The success of your product doesn’t necessarily mean your product management team is crushing it. Building great product is a team sport.
Sure, you can taunt great growth figures, but at the end of the day there is a team behind that effort working hard to fulfil your product mission. If your team isn’t rowing in the same direction it’s only a matter of time before things change for the worse.
So, is your product management team doing a good job? I’ve been reflecting on this for our team of product managers. To answer this we went back to first principles. What is it that we do?
Insert obligatory product management venn diagram:
See the diagram in its original context here
Probably the most used, but I believe, somewhat misunderstood diagram you’ll see in the product management discipline. The intersection between all those roles is incredibly blurry, and for most people, they’ll see this diagram without the original commentary and end up exhibiting behaviours of what I call “project manager product managers”. Our primary job isn’t to be a router between engineering, design and “the business” (whatever that means). We aren’t project managers.
The single, most important way, we influence our products success is by influencing our teams.
We have to drill down further to get anything meaty out of this. I’d like to propose three key things we should be asking ourselves as product management teams. These things revolve around the who, the what, and, arguably the most important, the why. Our primary job is to build a shared understanding of these things, which in turn helps our teams build better products.
As your teams grow, the most important thing I believe a product manager should be doing is to build this shared understanding with their teams.
Practically applying this within your team
Within one of our product teams at Atlassian we surveyed our sub-teams (developers, designers, engineers…) about this. Side note: I’m generally not a fan of surveys (this blog nails it), but if used correctly, they can point your team into some things you need to drill into.
We asked our teams to respond by indicating their level of agreement (through a scale of 1 to 5) for a few simple these questions:
I have enough customer context and feedback on what I’m working on.
The goal of this question is to test if we have a solid understanding of who we’re solving the problem for, and equally as important, the context in which the problem manifests itself. A second goal is to capture if we have appropriate feedback cadence to ensure we’re building the right thing.
I have a good understanding of the customer problem I’m working on.
Here, we’re attempting to get a confidence level on how well teams feel like they understand the problem they’re solving. Notice we’re not focused on the solution — because there are many things we could do, but the first and most important thing is to ensure we have a shared understanding of the problem. If we want a beautiful solution then we need to fall in love with the problem.
I understand how my work fits into the bigger picture.
In this question, we’re digging in to work out if our teams have a shared understanding on why they’re working on the particular problem — do they know why it’s important and how it fits into the vision? Do they know why it’s on the roadmap? Do they understand why it’s more important than anything else we could be doing?
We also asked a bonus question to work out if we are doing a good job of evangelising the problem to our teams. Again, from a scale of one to five, we asked team members to indicate their level of agreement with:
I’m proud of the product we’re building
Results in, what next?
We ran this survey across multiple teams (each with different product managers). The results were incredibly useful. It helped us identify where we were doing a good job, and more importantly, it informed our team of where we had gaps in our shared understanding.
Was our product management team doing a good job? We now knew where we have room for improvement.
The action plan from here is pretty simple. Assuming you’ve done some further qualitative research to get some context from those who responded to the survey, we can start to tackle each item with the most appropriate tool, framework or technique to address the feedback.
The purpose of this post isn’t to go into how to run each technique in detail, but here are some rough pointers for what you might do if you score low in any of those questions:
- The Who: Look into building a shared understanding around personas, customer interviews or contextual visits.
- The What: Consider exploring techniques which help understand user flows. Things like a journey, story mapping or the five whys. Maybe also ensure the team is aligned on what decisions have (or need to) be made.
- The Why: Look into your toolbox for techniques or frameworks to align on the bigger picture. Do we have a vision painted? Are we clear on our mission? Can we connect what we’re doing to our company goals and strategy? Does everyone understand why our roadmap prioritises something over another?
…and what about that bonus question about passion? This is a perfect opportunity to work alongside your engineering counterpart (such as your engineering leader) to discuss what could be done here. Do we have the right engineers working on the problems they’re most passionate about? Are there any techniques we could deploy to build empathy for our customers?
A product managers job: building a shared understanding with their teams on the who, the what and the why. I hope this framework gives your product team a simple way to measure their progress and success.
If you run this with your teams and have some feedback, suggestions or just want to share how you went I’d love to hear from you.
Some practical logistics:
- If you’re running the survey for multiple teams, be sure to scope the questions by asking what team someone is on first. You want to ensure the appropriate feedback can be redirected to the product manager of that team.
- Running the survey again a few months later will help you to measure how the team is progressing (e.g. We’re looking into doing this quarterly, but making sure the survey remains short).
- Make sure the results are discussed as a product management team. Before you jump into techniques to help improve the who, what or why make sure your team has the confidence they understand why some of those gaps may exist. If they don’t first do some further research with those who filled out the survey to get their context.
- Post-survey set an action plan and assign owners for who will do what. Agree on a date you’ll check-in to see how things are progressing.
- Celebrate your successes. If there is something a team is scoring well in ask yourself why. What did that team do? There might be techniques to share with other product teams.