Category Archives: Product Management

Following part 1 and part 2 of this series which detailed my reflections on how we might set up a product practice, this post gives insight into the workshop I ran with the team. Below is a breakdown of the activities we went through

Logistics

• 4 hours (2 sessions of 2h)
• 1 facilitator – yours truly
• 7 product managers 
• Miro for the workshop
• Microsoft Teams for communicating

Part 1: Review and discuss the problems

In the first exercise, I confronted the PMs with four problems I had identified (see part 1). I added a description of the problem and asked them:

• Reactions? Do you agree? Disagree? Have nuance to add?
• What would the problem look like if it was 100x bigger?
• What would the problem look like if it was 100x smaller?

After everyone had reviewed the problems, we read the post-its and discussed them.

To be transparent, we didn’t go into the answers of what the problems look like if they were 100x bigger or 100x smaller. Time was ticking, and the real value of these questions was for each person to really think through the problem, less in what the actual answers were.

Based on the critiques, we changed the problems and reframed them. It was an interesting debate, that led us to discuss which problem was the source of which other problem. Together, we came up with a refreshed list of problems.

How might we follow an evidence-based strategy for our products so that we have a clear idea as to why we are doing what we are doing and can say no to things that don’t fit with our strategy?

How might we get more clarity on the role of product manager and how we should work with others so that we can more easily work with them?

How might we provide other teams in our department with more visibility over what we are doing so that we don’t duplicate work/move in opposite directions and so that we build trust?

How could we work in more consistent ways as product managers so that others know what to expect from us?

The problems we agreed upon rephrased as opportunities.

I was thrilled by the thorough critique of the initial problems I had identified and overjoyed that we were able to reframe them into problems we all understood and agreed.

There’s nothing as satisfying as being disagreed with and then finding common ground.

Part 2: Review the PM toolkit

As the first exercise took the entire first session, we started exercise 2 with a clear head 2 days later.

I presented the PM toolkit I had adapted from Matt LeMay’s CORE framework for product management skills. I asked everyone for their comments, questions and disagreements. I also asked what skill gaps each of us identified for themselves. 

Once everyone had time to review and reflect we discussed each reaction. This helped us get on a similar page as to what product management is to us. You can read more about the details of this section in the second part of this series of posts.

Part 3: How could product practice and skills answer some of the organisation’s most pressing problems?

We had about 30 minutes for the last exercise, but it was definitely manageable. With a problem on each row, we discussed what we could do:

• Immediately
• In the next month
• In the next year

In a very short time, and following the reflections from the previous two exercises, we built a roadmap for the next year for our team to improve their product practice in a way that makes most sense to the organisation.

Next steps

The next step is going to be following this roadmap and regularly checking in. The biggest risk I foresee is losing momentum, as everyday work and burning platforms may take over our headspace. Though I hope the public accountability I set through blogging will keep me focussed. Let’s see!

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.

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.

Read part 2 of setting up a product practice.

‘What are you building here?’ was an interview question that dumbfounded me 5 years ago. That day, I mumbled an incoherent answer. 

In hindsight, I have a better response: a squiggly career*. With every new product job I have changed industries, working across non-profit, legal, government and now gaming. I have chosen to focus on the product craft without settling on a specific industry. 

Here’s my thoughts on what’s good/bad or easy/hard about that approach, as well as some thoughts on how to make that choice for yourself. 

Employers and recruiters may say ‘become an expert’ 

While this isn’t everyone’s view, I have repeatedly heard from companies and recruiters that they look for PMs with the right industry experience. My most recent example is a recruiter from Spotify who shared some insight into how he selects CVs.

He considers 6 seconds a generous amount of time to spend reviewing a CV. Being time-poor, beyond focussing on experience as a product manager, he requires relevant industry and domain experience. That means that it’s not just music/ subscription services you should know about, but also he’d like you to have experience in the domain you’re applying for (eg payments). 

When asked about what to do if you didn’t have the necessary industry/ domain expertise, he said be prepared to either go in at the same level as you are or potentially go down in seniority. Also, you should invest a lot of time in learning about the domain/industry before applying for the role and be ready to make a pretty strong case as to why you are pivoting. 

What I also sensed in his answer is that his expectation was that you would only be pivoting that one time. You should show your commitment to focussing on this industry and domain for the longer term. 

I can definitely see where he is coming from, and for a company like Spotify with hundreds of PMs and a high appeal, maybe having these types of requirements makes sense.

I can also see it from a PM’s perspective – becoming an expert in an industry can be highly stimulating when it’s your passion.

However, I know it’s not for me. I never had a 10-point plan for my career. When I changed jobs it was because the next opportunity was something I was excited about and where I would learn a lot, not necessarily because it was an obvious choice.

Why it’s worth it

In the short term, a squiggly career may be hard. It requires resilience, an ability to learn, and a true openness to new ideas and ways of working. However, it also gives you the exposure you need to become really well-rounded and develop a broad perspective.

Through my squiggly career, I have not only explored different domain, I’ve also worked in companies of different sizes, on both very technical things as well as transformation/change management projects, have managed a team on a shoestring, and have had a well-resourced team.

This means I am now extremely adaptable. I have learned the advantages and disadvantages of these environments and am able to adapt to a new role and bring in the things I have seen work elsewhere. 

Through these experiences I have become really good at being thrown into new things. While I get stressed and nervous like everyone else, uncertainty isn’t what scares me. I have acquired techniques to make sense of uncertainty and ambiguity, and I have the resilience to know that I have been in this situation before and will be able to deal with it, and I know how to support my team through it as well. 

Some top tips on making a squiggly product career work for you

1. Decide whether this is really what you want

It’s hard work. And from a logistical perspective, it also requires you to be in a place where there’s lots of product jobs, or you’ll have to be flexible with either working remotely or be willing to relocate. 

I was in London for my early career, and am now in Paris, and that has made this approach much easier.

Life has many different priorities, so this might just not work for you.

You may also find that you particularly love a domain. If that’s the case, that’s great, go for it!

2. Get really good at learning

A growth mindset will support you through the different stages of your squiggly product career because learning has to be at the centre of everything you do. 

The most crucial part is to learn about yourself and really understand how you learn. Then it is to be intentional about your learning. Have clarity on what you need to learn, don’t let the world happen to you. 

3. Build a strong narrative

With a squiggly career your job titles and previous experience are unlikely to tell a coherent narrative. You need to take charge of your story, and make sure you have a good idea of who you are and what you care about. 

Finding the golden thread throughout your different experiences can help create that. Add that to your intro on your CV or LinkedIn, but also have that ready when someone asks you why you want a job, or ‘what are you building here?’.

4. Keep your network going

Your professional network is a crucial aspect of your career development, regardless how squiggly your product career is.

While you may remain connected to your product network, changing industry can mean you lose touch with people you know from previous roles. This may be ok, but it’s worth being intentional about who you want to stay in touch with and make efforts to do so. Squiggles don’t mean you can’t return to a previous company or industry.

*When I was trying to describe my career, I first thought to call it a ‘portfolio career’, but then I came across the squiggly career’s podcast. It’s a brilliant podcast by Amazing if that strives to make work better for everyone – particularly in the context of careers that don’t follow a linear path. 

So I thought to name the blogpost squiggly careers to reference Helen and Sarah’s excellent work – but also because I realised that it reflects my career better than ‘portfolio career’.

A couple of weeks ago I wrote about feeling like a product fraud, which got me thinking about what this PM archetype is that we imagine the role of a typical Product Manager to be. And then, considering how many blogposts I have read about that particular question, I wondered why we spend so much of our time pondering about what our role is and should be.

There are hundreds of books, blogposts, podcasts telling us what product management is, or alternatively what product management isn’t. I am curious as to why we seem to question the role over and over again. So I explored a few reasons that I can imagine.

A recent discipline

It is a recent discipline, and it’s still being shaped by this ever evolving world. But product managers existed in a pre-tech world as the person that would care about a product from all angles, that would bring together the manufacturing and marketing of a product. I wonder whether pre-Medium and pre-Twitter product managers asked this many questions.

The world of work is changing

The world of work is changing and it’s particularly affecting the industries that Product Managers are working in. But then again technology has changed most jobs.

If most jobs are changing, are all professionals going through this? A whole industry has been spun up to answer what product management is or should be. I don’t know other industries so well, but do other job families ask themselves ‘But what is my job?’ so frequently as we as PMs do? I’ve never heard any of the developers ask that question. But I might simply not know what I don’t know.

Diversity of experiences

To come back specifically to product managers. I think another challenge is to conciliate the experience in a small startup compared to a large organisation. While there’s certainly an overlap of skills, what you’ll be doing day-to-day and the overall responsibility could well be very different. So the product community is trying to figure out what the overlapping skills and responsibilities are.

Is it because we’re fighting for legitimacy

I’m sure all PMs have faced remarks that play down the role of product managers. I still remember someone saying ‘I don’t understand why Product Managers get paid so much, they don’t do anything’ (and I’m aware that I should just get over stuff like that), but really it indicates that we as a discipline may feel the constant need to define ourselves in order to justify our place at the table… or rather at the Kanban board. In multi-disciplinary teams the boundaries of roles get easily blurred and since we’re not one of the ‘makers’ we struggle to point at something to say. “There- that’s what I did!”.

Always delivering value

To put a more positive spin on this, maybe it’s also because our day-to-day job is always making sure that our team delivers value. It could be that we have internalised the question of value so much that we need to constantly re-appraise whether we as a discipline are bringing value to the team. In a way this is my favourite reason because it paints the conversation about Product Management as a way for us to stay accountable to ourselves and always making sure that our role is needed.

Do you have any thoughts about why we ask ourselves what Product Management is or should be? I’d love to hear your views!

Throughout my career as a Product Manager, I’ve had several existential crises, thinking that the job I was doing did not reflect what I imagined a Product Manager should be doing. Several years into being a PM, I came to realise that no-one really does this ‘typical PM role’ I imagined, because it doesn’t exist in the real world, and that is the beauty of the job.

I’ve listed some of the moments in my career where I’ve felt like a fraud and why – with hindsight – I now know better.

Because there are no developers on my team…

When I started in my current role, my team was very odd, it was multi-disciplinary, but lacked the roles I was used to — developers and QA engineers, or a visual/UX designer. My team had a user researcher, a delivery manager (akin to a scrum master) and a content designer. Needless to say I was rather clueless as to what I could do with that team constellation. Building anything would be rather tricky!

But then, I was working on a product that wasn’t yet built and our team was this shape because we didn’t understand the problem space at all. Throwing a team of developers at the problem wouldn’t help, but the user researcher and designer were the right people to get the team to a place where we understood the problems better. And a few months later, we were ready to welcome a developer into the team and start building!

By that point, I had understood that as a PM I was just as qualified to set the vision and advocate for our users in a team without developers. The skills of product management equally apply in a team with different types of expertise — be that designers, researchers, data scientists or even policy experts.

Because I am also doing UX design, user research, QA and making sure the printer doesn’t run out of ink

Like many, when I first learned about product management I was in a job already acting as a PM. I was translating the needs of our users and stakeholders into stories and providing the necessary context for our developers to build our product. However, next to that I was also doing a lot of other jobs, such as drawing wire-frames, doing user research and testing the product. It was difficult to feel like a legitimate product manager.

However, looking back this was a wonderful opportunity. Not only was it my route into the role of PM, it has also given me a huge appreciation for some of the other disciplines. In small startups, this can certainly happen, and there are also plenty of project or consultant roles that are disguises for a product role. So forget your job title and feel included in the product community.

Because I am executing orders from senior management…

As a PM you can be in a situation, where you want to represent your users but senior management is much more keen for you to just do what they say. You can fight back with the user research you do and the analytics, but ultimately if senior management doesn’t offer you the freedom to build the product based on your users’ needs, then they are simply not doing their job right. And it certainly isn’t on you. I was legitimately a PM, I was just in the wrong place.

Have you ever felt like a product fraud? I would love to hear your experiences!

Two of the talks at MTPcon were concerned with designing for our future. On the one hand Amber Case was advocating for calm technology, while Josh Clark was talking about considerations for designing machine learning and big data products.

Amber Case, who is a scholar at MIT, started talking about a few worries of hers: a connected kitchen, where every piece of the kitchen would be using a different technology system with its own username and password, asking for your attention all the time, and were you to move, you’d have to get all the credentials from the previous tenants, making sure it works with your current devices… it all seems very disruptive.

Amber Case is an advocate for Calm Technology and she has a set of rules she to define calm technology:

1. technology should not be intrusive, it should remain in the background
2. technology should only be there when you need it
3. tech should inform and calm
4. tech should amplify the best of technology and the best of humanity: machines shouldn’t act like humans and humans should act like machines
5. technology can communicate, but it doesn’t need to speak
6. technology should consider social norms
7. the right amount of tech is the minimum amount to solve the problem

Josh Clark also had the future in mind, thinking about what rules we should apply to build big data products and he had a few recommendations as well

• Principle 1: embrace uncertainty. Machine learning products such as image recognition technology has still a lot of short comings — for example this one:

Clark suggests that we need to embrace the lack of knowing instead of building the perfect machine that is always right. Here is his suggestion for the same image:

• Principle 2: improve the data. Another challenge of our time is the quality of the data that we feed into big data products. We are running the risk of teaching it pre-existing prejudice and inequalities, reinforcing structural inequality rather than creating a level playing field. Algorithms are in no way objective. They represent the agenda of the agenda of the person who is behind them.
• Principle 3: responsible data gathering. As we are getting better at gathering lots of data, we need to be more responsible in the way we do it. We need to be loyal to the user, and take responsibility, as your product will have the values that you put into it.

More MTPcon 17 themes:

(1) the contribution of leadership

(2) creating space and opportunity for teams to perform

(3) rejecting or embracing the past