A tale of two Roman Pichler classes and a bit of what I’ve learnt from my Product tribe
The last couple of years at NHS Digital has confirmed my professional outlook as being Product led and helped refine my Product Management skills by working with some excellent people steeped in Agile ways of working.
I thought I’d capture some of what I’ve learnt here, so I can refer back to this and remind myself to stay true to our creed as I step into ‘what next’.
Below are reflections from two Roman Pichler training courses I attended, and some general thoughts derived from being a Lead Product Manager in a complex health setting.
Product Strategy and Product Roadmap
The sketch above shows what was going through my head after I attended Roman Pichler’s Product Strategy and Product Roadmap training.
I see this as almost the foundation level of product thinking — it allows you to think about discrete artefacts and how to stitch them together in a “platform as product” way.
You need a vision for your product — and Roman suggests a simple Vision Board to match your vision, with target groups, needs, product and business goals.
And you need a goal oriented roadmap — which maps your releases (dates and names), with goals, indicative features, and metrics for success. I’ve used this quite a lot — and it’s a great way of sharing intent with stakeholders (and getting buy in) and helping teams understand a view longer then the next sprint (I’ve drawn roadmaps out for a couple of years ahead).
And a backlog. In my experience having articulated Features (the big things) and Epics (the slightly smaller things) helps people understand things higher upstream (the roadmap, the vision, the anticipated benefits etc) and also allows you to articulate the user stories for the team to build. There’s lots of good examples out there about how to create and manage a backlog.
And I don’t think we talk enough about the Product lifecycle (but Roman did).
We often understand the ‘product market fit’ stage of a new product because it’s all about launch — but I’m not sure we use data well enough to proactively manage the lifecycle, and that crucial stage of extending a product, or ending it.
If you’re a Product person it should be as natural to close a service as it is to launch one — but in my experience too many products and services linger on.
And just to point out the obvious — high discovery effort upfront but also throughout at different levels of intensity.
The course also covered some techniques we haven’t used in the NHS, but I can see would be relevant in different settings.
- The Product Portfolio matrix — combining the roadmap with the product lifecycle to take a portfolio view — and using a matrix (of growth and benefits) to categorise products as question marks (high growth, low benefits), stars (high growth, high benefits), cash cows (low growth, high benefits), and pets (low growth, low benefits). This fits with the product life cycle where question marks tend to be products in the introduction stage, stars are products in growth, cash cows are mature offerings and pets are declining product.
- The Kano model — which matches product development to customer satisfaction (see Wikipedia re the Kano model). A little bit ‘management thinking’, but an interesting lens.
- The Iron Triangle — whereby the quality of work is constrained by the project’s budget, deadlines and scope — where one of those factors has to flex to accommodate the others (again, see Wikipedia re the Iron Triangle). A useful reminder of constraints!
Product Leadership Skills
I found the Product Leadership Skills course interesting — because it wasn’t quite what I expected, and it took me a little while to realise how brilliant it was, not just for being a product leader but also for life.
The course helped me put some things I’d touched on before into a Product mindset. Some highlights for me were…
Practice right speech…
… to build trust and gain respect by using speech that is…
- Well intended — based on goodwill and respect, intends to connect people, not caused by impulse or the need to sound important or funny
- True — not overstated, out of context, blown up or sugar coated
- Beneficial — helpful for the listener, even if not liked — and can understand the message
- Kind — firm and direct, but not harsh, cynical or nasty
- Timely — a good chance of being truly heard and understood; right time and place
And be positive first e.g. ‘That’s great, AND maybe you could…” — previously I’ve tried to practice “Yes, and…’, not “Yes, but…” The above based on Buddhist teaching.
Covey’s Listening levels…
… which are…
- Ignore
- Pretend to listen — eg day dreaming
- Selective listening — doing things at the same time, which may be listening and judging rather than keeping an open mind
- Attentive listening — the information is received
- Empathetic listening — listen for feelings, facts and interests with a non-judgemental mind
With a side order of being open minded before you make any judgement.
Referent power
Which is all about how you’re perceived, how you’re liked
- Be present and warm hearted
- Grow likelihood to be trusted and followed
- Have empathy, be open minded, be inquisitive
Gaining consensus
Being conscious of where you are at on a scale — an ‘agreement gradient’, and understanding if you can’t agree then you may need to disagree but still commit.
Ultimately if you can’t reach a consensus, the Product Owner/Manager decides — hopefully not in isolation, but with discussion. Which is what @Mattedgar said at a Product away day (and I always love quoting this) …
Being a balanced effective product leader
On the scale of things I came out as a balanced effective product leader, I was expecting to be nearer to dictator.. 😉
I’m still working on being an empathetic listener, using right speech, growing my referent power and gaining consensus, but hey, life is a work in progress isn’t it?
Applying this thinking to a complex health context
If you think of the above as ‘small pieces’ — skills and tools a product manager might need or use — it gets interesting when you think how you take a Product minded view into the broader context of complex organisations.
Governance processes may not have caught up with Agile or Product thinking and it’s interesting to think how we can help influence corporate systems to fit with Agile Product delivery.
Hence the sketch…
The model above would be a shared one, operated in the open, and includes a range of artefacts which are jointly owned — but led by people with the expertise to do so.
The ‘Owner’, who might be a sponsor or SRO, leads on the outcomes, benefits, and strategy — but somewhere down the ‘yellow line’ as you go through vision, roadmap and mission planning the responsibility shifts to a Delivery Director, a multi skilled leadership team (made up of Product, Delivery, User Research, Content, Tech — and in health Clinical) and one or more Product led squads — and that’s where the backlog is formed and stories are prioritised into sprints.
If you have all the above, built on shared standards, respect and trust — well hey, what you need for formal governance, risk management and business cases to secure funding should just follow shouldn’t it?
So here endeth a loose connection of Product minded thought…
Ps — Roman’s courses covered a lot more than what I’ve written about here — these were the things most relevant to me. His classes are excellent, he’s very engaging and responsive to the needs of the class, and you get such great takeaways — including lots of tools and templates from his website. If you have chance, work with Roman or attend his courses.
Ps2 — on reflection this should probably be 3 blogs, but I’m a bit time poor at the moment, maybe will revisit later.
Ps3 — @mattedgar recently published (in his words) a paean to high-trust workplaces and multidisciplinary teams — highly relevant to the above and a great list of links at the end to expand your Agile and Product way of thinking…
