What does product practice mean to you? I have worked in organisations where product teams and product management were fairly well defined. We often had debates and discussions about the product role, but it was within an overall framework of expectations and understanding of what the product role did.
A few months ago, I started a job where that did not really exist. I lead a team of 6 product managers with about 15 products (depending on how you count). And while there are other product managers in the organisation, they are in other departments and we have few links with them.
Stating the problem
As I was learning and observing, it felt like the PMs weren’t PMs like I had known them elsewhere. Some things that I considered fundamentals seemed to be missing. For example, there didn’t seem to be an easy way to find information on what was planned for the products.
I felt I had been hired to bring in a strong idea of product management, but I didn’t want to blindly impose my idea of what a product manager should do. I know that PM roles tend to be quite different depending on the circumstances of the organisation and the product. Therefore I found it hard to pinpoint where there was a gap in product practice, and where it was the idiosyncrasies of the organisation.
In order to disentangle “what a product manager should do” versus “what the organisation needs”, I eventually reframed the question to.
How could product practice and skills answer some of the organisation’s most pressing problems?
In 2021, I want to trial different approaches to answer that question and find a product practice that works for us. I plan to use books and blogs for inspiration, but let my team construct the practice.
There’s two objectives in this:
- Help the organisation with its most pressing problems
- Build a mature product team
Objective 1: help the organisation’s most pressing problems
In my initial assessment, I identified a number of problems which all lead to value not being delivered to the users.
Alignment – It was hard for me to gather information on the products when I started, and unsurprisingly that it’s also the case for our colleagues whose primary focus isn’t the product but who are impacted by product developments. I’ve already seen several teams take decisions at odds with the roadmap. They eventually realised what was planned, had to reverse decisions and change plans, sometimes doing twice as much work. Each situation was different, but in every case there was a lot of frustration for the product manager (who felt undervalued/ignored) and for the team in question (who felt out of the loop and undervalued).
This lack of alignment has primarily resulted from considerable team changes (people leaving and arriving), the move to working from home, and also the increased pressure the team has felt this year. Things are finally stable enough so that we can address this issue.
Severity: Very High. It’s systemic across our products, and the frustration caused is starting to impact people’s wellbeing at work.
Complexity – It took me a while to fully grasp what we were doing and I still find it hard to communicate what we do and what we’re working on. There are so many initiatives, so many stakeholders, my brain continues to struggle with containing all the elements. This is to some extent on the products, but also within the department in general. The main issue here is that it makes communication hard, which in turn makes it hard to align people.
It might be difficult to make away with complexity within the short and medium term, but I think we can work on how we communicate it, and hopefully influence others to help reduce complexity overall.
Severity: High because it affects alignment, but also it’s not all in our control
Delivery – Delivery of software looks different for our different products, partly due to the fact that we manage both custom products and off-the-shelf solutions. For some of them, we’re operating in continuous delivery, but for some there are elements of waterfall practices and big bang releases, and all the added risk it adds.
Severity: Not a problem for all products, but definitely a risk for some (including those our important stakeholders are watching).
User-focus – Evidence around user needs and behaviours are inconsistently used as drivers for our roadmaps. While we work with user researchers and UX designers, they are stretched across our products, and fairly often, we see management wants, political negotiations and best guesses make their way into our roadmaps. Often because we don’t have the information to counter their arguments.
Severity: Not a problem for all products, but something that can be improved, and avoid investing in features that later on require significant rework or get killed off.
Objective 2: a mature product team
The idea of what a mature product team looks like is much more blurry for me. I have already started digging into industry literature, reflected on my own experiences and used fellow PMs elsewhere as sounding boards. This is definitely still macerating in my head and will likely be the subject of the next post.
My plan is to build a rough idea of ‘product practice’, so that we have things to pick from when building ours.
What’s next?
Once I have my rough idea of a product practice, I plan to do a series of workshops with my team of PMs. First to validate my idea of the pressing problems, and then try to build the first element of our product practice around one of the problems.
Digital Good 
2 Comments