Product Management for Non-Product Managers
One of the things I’ve seen quite commonly, in organisations where product management (and an agile way of working) is introduced, is that people often fall into two camps. The first camp is those that are resistant to the new way of working (either through lack of understanding or communication, or they are unconvinced of the benefit), and the second camp is those that are keen to get on board and want to apply it to everything they do.
The first group is a topic for another blog post I’m working on, so hold that thought!
Thinking about the second group though, I’ve seen a lot of examples of teams outside of product and engineering, who can see how the approach is improving how product features and capabilities get delivered, and want to apply the same approach to their own teams. I’ve probably been a bit cynical of this approach in the past, seeing it as an attempt to fit a square peg into a round hole (i.e. taking something that was designed for delivering software changes in an agile way, and trying to apply it in a space that might naturally not lend itself to agile), but in reality there are lots of elements of product management that can be applied more broadly to a business, regardless of whether change has to be delivered in an agile or more waterfall way.
So, what are the core elements of product management that can be more broadly applied?
Communication
The various ceremonies, that are used in agile product management and software delivery, are generally there to improve communication and collaboration. While some of these are very specific to delivering engineering changes (e.g. refinement sessions — to clarify functional requirements, acceptance criteria and sizing for a product deliverable), there are some that can be useful in any team.
- Stand-ups: Regular (e.g. daily?) short meet-up with the team to share what everyone is working on. Keep it short (e.g. 10–15 minutes). Keep it concise (we don’t need anyone’s life story). If topics come up that require further discussion (which is part of the purpose of stand-ups), then take them offline with just the relevant people. A really great way to make sure everyone is aligned, and no-one is blocked.
- Retros: A semi-regular catch up with the team to talk through what’s been going well, what’s not been going so well, what we want to do more of, what we should be doing less of, etc. Everyone should contribute in these sessions, and they are a really valuable way to tease out any issues early, and a good way to get quieter team members to speak up.
- Demos/showcases: Tell the rest of the business what you’ve been doing and what you’re working on. It’s a great way to raise your team’s profile in the business, and to ensure you get the credit for the work you are doing, as well as a chance to capture any feedback.
Customer Focus
This is going to sound really obvious, but make sure you are being focussed on your “customers”, rather than a dictated set of priorities. Who are your customers, and what are the problems that you are trying to solved for them? This is called Product Discovery. Who your “customers” are will depend on what kind of team you are. And you will need a way to measure how effective you are being at solving their problems.
So for example, if you are a customer service team, your customer will be the end consumers that interact with all of your services. The measures you’d likely want to track probably already exist, and could be things like:-
- How many customers are able to self-solve issues without having to contact customer services?
- What is the customer satisfaction score of people who had to contact your team?
Metrics like average call time, whilst useful from an operational efficiency point of view (e.g. help to highlight colleagues that might need more training, etc) tend to be very cost focussed, and are not likely to be a good measure of how happy your customers are. Most places I’ve worked, there has always been significant pressure on customer services teams to reduce costs, but rather than focus entirely on “how can I reduce costs the most”, a simple reframing of this question to be “how can I deliver the best customer experience in a cost effective way” may lead to making different decisions about what to actually do.
If you are a people team, your “customers” are most likely to be colleagues, so you would want to be thinking about how to gauge their needs (what are their pain points, what things could be made easier for them, what problems are they encountering in the course of carrying out their duties) and what is a suitable measure of how successful you are being (e.g. colleague satisfaction).
The key thing is to make sure that your team are fighting for your “customers” (making sure they have a voice), and being prepared to challenge anything that will disadvantage them.
Not all “customers” are created equal, however, so you may find that the needs of one group of customers (e.g. paying end consumers) are considered higher priority than another (e.g. colleagues).
Being data driven
Making decisions based on fact vs opinion is a proven driver of success. That’s not to say experience is not valuable. Experience can help to form initial hypotheses about what your “customers” need, but you always have to accept that you might be wrong. Hence why you decide what metrics you are trying to drive, and you use data (surveys, metrics, behavioural analytics, etc) to track how effectively what you do is improving those metrics. If it is not improving those metrics (and they are the right metrics, aligned with the broader organisation), you are probably not working on the right things.
Where you are not able to track the metric you are trying to drive, you either need to find a way to track that metric, or choose a metric that can be tracked and is semantically similar enough.
Management of work
All teams should have a way to collate the things that they are responsible for delivering, so that they have a way to track those things, a way to communicate what those things are to the rest of the business, and a way to order those things (see Prioritisation section below).
Now, whether that is a roadmap or a project plan or whatever, is entirely down to how complex that set of things is. Now, for the sake of clarity, pieces of work that need to be delivered in a sequential manner, and to relatively fixed timelines, in a waterfall way (i.e. do thing A, then thing B and then thing C) are often handled better in project plans. That’s not product management, and in large organisations they will have a PMO function responsible for the delivery of large cross-team streams of work, so I don’t plan to talk about that, other than to call out that for some teams, traditional project management is still entirely appropriate.
e.g. if you are building a house, you can’t start building until you have foundations, you can’t fit electrics until you have walls, you can’t paint until you’ve plastered, etc. You can’t really build a house in an agile manner.
However, there are some lighter weight ways to manage “things” in the product management world that are easily re-usable by other teams
Roadmaps
A roadmap can be as simple as a prioritised list of things that you plan to work on. You may even have a sense of when those items may get worked on, but once you start getting into very specific dates for delivery, that’s where you have to be careful to understand why there is the need for a date (which will typically be a best guess), and use approximations rather than exact dates (which are a false promise).
You don’t need to pay for an expensive roadmap tool in order to track a simple roadmap. There are lots of simple tools out there (e.g. Trello) that can let you manage a prioritised list easily.
Backlogs/Sprints
If you have a regularly changing list of things (e.g. constantly getting requests for new things to work on), this is where a backlog may be useful. Tools like Jira are the most common way I see people managing this backlogs of requests, as they provide a full audit trail for progress of each item. Let’s face it, lots of teams do this already (e.g. require you to raise a “ticket” before they will work on something), but the key difference I see is that they should be applying a consistent form of prioritisation to that list, based on customer centric measures.
Where you’re trying to prevent your team from being overloaded, you can even use sprints as a way to limit the number of items a team is working on concurrently.
i.e. pick a number of the most important items from your “backlog” (based ideally on a sensible prioritisation of that backlog) and allocate those to be worked on in a fixed timeframe (e.g. next two weeks), and the team will only work on those items, in order to avoid too much context switching (which can impact how effectively the team works, and whether any/all of those items will actually be completed). If something comes up that HAS to be worked on as a priority (and I would argue, needs to meet the same prioritisation criteria as was used for other backlog items), then you agree what item(s) to drop out of the current “sprint” in order to accommodate the new request.
Delivering iteratively
One of the biggest differences between traditional project management and agile delivery is how capabilities are delivered. The product management approach is to deliver the most impactful “slice” of functionality first (this is called an MVP — Minimum Viable Product), and then incrementally deliver additional features/capabilities in priority order over time. Delivering new capabilities to your “customers” in an iterative manner has multiple benefits.
- Your “customers” get value earlier, through having the most impactful features/capabilities delivered first (rather than having to wait much longer for all features/capabilities to be delivered in one go)
- You are able to get feedback/data earlier on how effective the new features/capabilities are at improving your customer metrics, and can change direction accordingly
- The process of delivering the first slice of functionality/capability can be extremely informative in how to more effectively deliver the next set of capabilities, how long it might take, etc. In a traditional project management approach, you don’t get this learning until the end, when it’s frankly too late to be useful.
Prioritisation
If you have a number of “things” you’d like to do, there are a lot of useful frameworks that can be used to help get these into a sensible priority order.
Which framework to use will depend on what success measures the team are trying to drive. Crude frameworks like effort vs impact are a good place to start, but are a limited lens through which to view your roadmap/backlog. Where teams have well established (customer centric) sets of metrics that they are trying to drive, frameworks like ICE/RICE (a scoring model that combines Reach, Impact, Effort and Confidence) are useful to put these into a sensible order to help deliver the most benefit. For teams that have less tangible measures (e.g. satisfaction), then lighter weight frameworks like Kano may be better, that focus on the level of customer delight for any new feature/deliverable.
For more information on prioritisation frameworks see ProductPlan’s Ultimate Guide to Prioritization Frameworks
So, lots of ways that product management practices can be applied more broadly, but you need to select just the elements that make the most sense for your team.
