Setting up a product practice part 2

In my last post I talked about my ambition to work on our team’s product practice. I started by focusing on what problems we might solve within the organisation.

As a next step, I needed something tangible that described a mature product team. Like a sort of toolkit that would help us agree on the role and work of a PM.

After some research, I decided to go with Matt LeMay’s CORE framework (Communication, Organisation, Research and Execution) because it is sufficiently broad to be applicable to our circumstances. It doesn’t assume that customer = user, nor does it assume that you’re selling your product at all.

It was also a personal choice, because I like how he conceives of product management as a discipline. I would really recommend his book Product Management in Practice, where I got the CORE framework from. 

Discussing the CORE framework in a workshop

I wanted to explore the framework within a workshop setting with my team. I didn’t have the time for them to read the chapter on the topic, so I decided to adapt it for my purposes. I synthesized and adapted his framework to our reality so that we could use it as a conversation starter.

Below are my sections from the workshops for each element of the framework.

Communication

As Product Managers, we are constantly communicating. With our product team, stakeholders, other teams, sponsors, users… anyone who is remotely impacted by our product

Why?
To create alignment and understanding between teams. We prefer clarity over comfort, that means we’d rather ask an uncomfortable question than run the risk of things not being clear.

How?
– Formal and informal
– Written and oral
– Active and passive (Listening is also part of communicating)

Some of the tools for that:

• coffee
• presentations, demo, show and tell
• roadmaps
• release notes
• posts on internal networks
• Jira
• styleguide

Organization

As Product Managers, we organise other people’s work. We make sure that our team knows what to do and why, without telling them how.

Why?
We know what problems need to be solved, but we have to rely on others to define how. In that we need to build a common understanding and work to build good collaborative processes. Ideally we want the team to understand the mission so well and collaborate so well that we become redundant.

How?
– adapt product development methodologies to our reality
– improve processes and practice

Some of the tools for that:

• user stories and acceptance criteria
• Ceremonies: retrospectives, stand-ups, planning
• Workshops: roadmapping, Prioritisation, kick-off, user-journey mapping
• product development lifecycle (discovery, alpha, beta, live)

Research

As Product Managers, we learn about our users’ reality every day. We are intrinsically curious and ask ‘why’ more often than a 4-year old.

Why?
What our company cares about and what our users care about are different things, so we have to be a relentless advocate for the latter.

Some of the tools for that:

• user research and user testing
• surveys
• market and competitor analysis
• product canvas
• customer meetings
• data analysis
• 5 WHys
• Assumptions mapping

Execution

As Product Managers, we are willing to do whatever it takes to help our team and our organisation succeed because delivery of value is paramount.

Why?
We care most about value being provided, and there is no work beneath, no work above. If it fits with no-one’s role, and it needs to be done, then it’s our role.

How?
– bring in the donuts and team motivation
– focus on where the gaps are and fill them

Some of the tools for that:

• food and casual time
• retrospectives

Next steps

The next step is a workshop with the team, to first review the problems, then inspect and discuss the toolkit, before in the third step reflect on what product skills we should develop and what tools we should adopt to help us address our problems. More on that in the next post…

Read part 3 of setting up a product practice.