In this MTP Engage Manchester talk, Ross Webb reveals some simple techniques that can be applied to help us communicate and develop much more effectively.

For product managers, there’s often a troubling disconnect within organisations. More specifically, the wider organisation (including senior stakeholders) often doesn’t understand what product management is, or what challenges we face in its practice.

Don’t you just decide on a roadmap and a wishlist of features, and then tell devs to build them?

This is obviously disheartening, but it also makes it difficult for the product function, and the product people in the organisation, to flourish. So how might we encapsulate and represent the product function to the rest of the organisation, so that they can understand what we do, and we can understand what we need to do better? Can we apply a product mindset to our own practices?

In short: yes!

In his work as a product and leadership coach, Ross Webb has seen a few simple techniques that can be applied to our product craft to help us communicate and develop much more effectively.

Applying a Product Mindset to the Product Function

Ultimately, what Ross is describing is a fairly straightforward application of a product mindset to our professional growth, and to our roles within the organisation. It is about developing coherent, relatable clarity about the work we are doing, being able to focus our energy on important work that moves the team forward, and soliciting regular and frequent feedback.

We do these things every day for our products, and there is no reason at all not to do them for ourselves in the context of our peers.

First, we Need a Product Scorecard

The exact scope and granularity of your scorecard will vary from company-to-company and from role-to-role, but you need to take what Ross calls a “stock-take” of the key skills and activities that are crucial parts of your work. The goal is to develop a robust (but not overly heavy!) list of the things you do that make you an effective product leader, which you can develop, and which your peers can give feedback on.

Of course, once you have the list, you need to give yourself a “score”. This could be a traffic-light system (“red / yellow / green” for “under-par / adequate / excellent”), or it could be a numerical score. The exact rating system you use isn’t as important as the activity of honest self-reflection. However, Ross observes that one benefit of a numerical score is that it gives us a way to track overall development in the product function over time. Note that we’re not trying to replace qualitative insight with simple maths – we’re just using a tool to help us articulate where our relative strengths and weaknesses are.

Finally (the really hard part!), you need to share your scorecard. More on this later but, bearing in mind our product mindset, we need feedback early, and we need it often. The whole point of this exercise is to develop better rapport and insight from our colleagues, so we should invite them into a conversation around the scorecard. This will create opportunities for the rest of the organisation to:

1. better understand the product function, and
2. give us clearer feedback on how the product function is perceived, without linking “performance” to feature-based outputs!

We Need a Weekly “One Big Thing”

Many teams will already be doing something like this – it might relate to your product “epics” or dev sprints, but the intent is just to set yourself an ambitious-yet-achievable goal, and to do so in collaboration with your team to build alignment. Publically agreeing on the big goals for each week with your team is also a way to develop focus, accountability, and a stronger sense of collaboration.

Setting goals on a weekly cadence also helps you develop the intuition about what is achievable in a short timeframe, and gradually develop the skills to achieve more in that timeframe. It gives the whole team a sense of accomplishment as you see visible progress towards your overarching mission, and that trackable progress is an excellent framing device for your scorecard, as well as a way to demonstrate to your peers what it is that the product function “does”.

We Need Feedback and Lots of It

Returning to the topic of feedback, remember that we started this journey of clarification and improvement for one of two reasons. We either felt that the organisation around us didn’t really understand what the product function is for, or we didn’t feel like we understood how well we were performing relative to the organisation around us.

The only way to start to untangle those issues is to have regular, meaningful conversations with our peers and stakeholders. A structured scorecard (and any practices that come with it) is similar to a roadmap, in that the artifact is not the goal. The artifact is a tool for you to facilitate conversations, and spark meaningful feedback on how well the organisation understands what you do, and how well they think you’re doing it.

We understand this for our products – that feedback from our customers is invaluable – so we should apply that same product mindset to our product practices. Ultimately, it’s only by making our work more understandable and more visible to our peers and to ourselves that we’ll be able to understand how well we’re doing, and to help our organisations better understand how we can contribute.