(PM) Team retrospectives

Over the past year, I’ve experimented with retrospectives for the team of product managers that I lead. Here are some of my learnings as well as an account of a recent experiment: a retro for team wellbeing and mental health.

This is entirely applicable to other disciplines and jobs. I called this post ‘(PM) team retrospectives’, because I wanted to distinguish it from the retros a multidisciplinary team runs.

The goal

This retrospective is not exactly like the one for a product team who is working together towards an outcome. The product managers don’t work with each other. They will interact when there are dependencies, but they spend most of their time with their respective product teams. 

The PM team retro is there to: 

  • celebrate common drivers of happiness
  • identify common pain points and see whether we could address them together
  • develop empathy for your peers and offer support where applicable

It also helps the team lead (me) identify issues to address.

Here are a couple of things I learned 

Monthly is the most natural cadence:  We also tried quarterly and every 2 weeks. Monthly seems to give us enough to talk about, not be too repetitive while also not feeling like a rare occurrence. 

The format ‘mad, sad, glad’ works well: we tried ‘stop, start, continue’ as well as ‘happy, sad and idea’. For the latter I also tried to split it into different sections – your product team, the PM team and the department/the company. It became clear, however, that many items were things that were (at least partly) out of our control. The ‘mad, sad, glad’ format worked better because it is more about how people feel than about identifying steps towards continuous improvement.

Little bonus on the format: I use the Comedy Wildlife Photography awards for illustrations on our Miro board. Here’s mad, sad and glad.

A retrospective focused on individual wellbeing

This month, I sensed a general sense of ‘meh’ amongst the team. So I decided to run a different kind of session to talk more specifically about wellbeing, stress and mental health.

Looking for inspiration online, I came across @stephenmounsey post on team wellbeing retrospectives. There are several interesting formats. For my session, I borrowed the ‘self care grid’. I removed ‘spiritually’ as this seemed like a lot of boxes and I already thought that it might be difficult to distinguish emotionally from mentally.

Here’s the grid that we ended up using:

What currently energises me in my work?
What saps my energy in my work?
What would help to energise me more in my work?
What holds me back from doing what would energise me more?
Self-care grid adapted for a team retrospective

Each person had their own grid on our Miro board. That way you can reflect on your own experience and not be influenced (and intimidated) by what others may have written down.


  • 10 minutes to fill in the grid in silence/to calm music
  • 40 minutes to share what we had written (10 minutes each)

That day it was only half the team, so we were 4 people, and time-wise it worked very well. It didn’t feel rushed, it didn’t feel too long. I’m not sure whether it would have worked as well with the whole team.


This retro does several things:

  • builds empathy with your team mates
  • helps you be more kind to yourself, as you realise that everyone feels overwhelmed, stressed and low in energy sometimes
  • reflect on your own habits and identify things you can do to make you feel better

Other suggestions?

We’re still iterating the format and adapting to the context. I would love to hear about what other people are doing with the team they manage. Feel free to reach out here or on Twitter (@Ch_Foyer).


How to stop forcing PMs to make up delivery dates

Leaders and stakeholders in other parts of the organisation want to know what’s being delivered, so they can plan around it, adjust their work, create communication plans…

A common frustration is product managers being forced to provide predictions, and then these predictions not working out. We see constantly slipping delivery dates.

In my last post, I wrote about how a Product Manager can communicate uncertainty around delivery to manage expectations. Yet, what was missing was the role of product culture and organisation in this.

Product teams can only provide informed judgements about the future and give stakeholders a somewhat accurate picture of the future if they control their own destiny. That means that they can control what they’re working on and with who, are able to change direction, and can break things down effectively.

As a product or business leader you must ensure the environment is well designed to give them the necessary freedom to act.

The team’s ability to predict delivery will depend on:

  • how many things they’re having to predict
  • control over the team and their availability
  • how well they understand the task at hand
  • having had practice at working in that team, and having done that same/ a similar task in the past

It’s the role of the product leader to ensure conditions in which the team can better control what they work on.

Reduce the number of competing priorities for your team

The more priorities a team has to deliver against, the less able they will be able to effectively control how long it takes them to deliver each feature/epic/thing.

When you multiply the number of tasks, you exponentially increase the uncertainty, which cancels out the ability to predict future developments.

My favourite analogy for that is cooking an English breakfast.

I can easily predict how long it takes me to fry sausages, or how long it takes to heat up beans. But if ask me how long it takes me to prepare an English breakfast, that’s a lot more complex. Not only do I have to predict how long it takes to do each part of the breakfast, I also have to factor in how to do them in parallel.

For example, if I put bread in the toaster at the beginning, it will be done by the time everything else if ready, but it will be cold.

If I made it regularly (and therefore had a profound understanding in which order to do each task), then it might be easy, but it requires practice.

If this is a new problem (and often product teams have a lot more of those), I can give an estimate, sure. But if you insist on me delivering to what I guessed, you’ll probably have a half-burnt half-undercooked breakfast.

In the world of product management, this means reducing to a minimum the number of problems a team is tackling at the same time.

Empower the team to control their team’s availability

Reducing priorities applies also to how many products a given person is assigned to. I have seen a designer working across 5 products at once. Notwithstanding the cost of context switching for that person (and sheer exhaustion), this also created risk on the product side. The product team may suffer from another team needing the designer more urgently.

Someone being part-time in a team means they also can’t create the same trust and ease of communication with the rest of team that is needed to move fast and in a predictive manner.

This means assigning people for a given amount of time to the lowest amount of products necessary. Only in exceptional cases and in full transparency should you make changes to those assignments.

You may think I’m pointing out the obvious, but I’ve had developers reassigned to my team overnight because someone up top thought we weren’t moving fast enough (without talking to me first).

As a general rule, the further team assignment decisions are made from the team itself, the worse they will be. Of course, leaving teams themselves to decide who they need exactly will require a well-experienced team, but for me it’s definitely the ideal scenario:

Fundamentally, people will do what’s best, they are smart and well-intentioned. By vastly underestimating our people’s ability to make good decisions, and expecting them to waste money, we have created atrocious planning processes, that waste even more money.

Think big, but predict small

It’s ok to have big goals, but it’s crucial to help and empower your product teams to break those down into smaller and more predictable chunks.

However, this doesn’t mean that we will start predicting the size of all the chunks. Breaking things down only makes the first one or two chunks more predictable. Anything else we plan to do later is likely to be so full of unknowns that any exact prediction shouldn’t pass a lie detector test.

Even better, we’ll probably learn that things we thought we should do next are not that useful, and instead, we should focus elsewhere.

For complex problems, breaking things down doesn’t make the whole big mission easier to size, it only gives you something to size – which is the beginning.

John Culter drew this diagram, that illustrates this point.

Teams that become better and better teams

I alluded to it above, predicting effort and time is something that is a practice. Product teams will get better at it over time because they learn to work together. Experienced teams will have overcome problems and found solutions together, they know how each other work and how to optimise things so that they can work together. They also learn to develop trust and safety, which means problems can be spotted early, conflicts can be dealt with effectively.

Just like a sports team, a team gets better with practice. So the worst you can do for your teams is rejigging their assignments very frequently.

Of course, give people the opportunity to move across different teams so they can learn and develop by facing new challenges. However when we engage in “resource” planning (cringe), we tend to forget that people aren’t components that we can easily replace with another of the same type.


If we want better functioning teams, then instead of doubling down on control, we have to trust them more. Because it’s control that’s hampering their ability to do what’s best.

Decision-making needs to happen closest to the people implementing the decisions. As product or business leaders we need to trust, while providing the right tools and space for the teams to deliver value.

This isn’t easy, as uncertainty can be scary, especially if the leaders above you don’t embrace it either and want control and predictability from you.

However my sense is that this type of leader is a dying breed, as more and more product managers have the opportunity to see what good product leadership looks like and will be inspired to continue it and evolve it in even better ways.

Book recommendation: My reflections come both from good and bad experiences, but also reflect what I read in the book Reinventing organisations that I highly recommend.

Pretence of predictability: Am I being as evil as my washing machine?

It’s Saturday morning, I am waiting for the washing machine to finish its cycle so I can go out. However, a design flaw in the machine is causing me disproportionate frustration.

As you would expect it has a small screen that indicates the time left. However, it never indicates the entire time left, only the time left at that particular stage of the washing cycle. I don’t know what these stages are, nor how many there are. Nothing on the machine indicates that either.

This means that when I put it on, it says 1h35, but if you come back in about that time, it suddenly says 40 minutes left. When you wait another 40, it might go back up to 30 or 40 minutes. Every time it goes down to zero, another timer starts. It’s completely infuriating when I try to organise my day around the washing cycle.

I call this annoying behaviour the pretence of predictability.

Pretence of predictability in product

Today, I came to the realisation that I have been just like my washing machine. Especially early on in my product career. 

“Yes the feature will come in August”

3 weeks later:

“It’s planned for September! The work we’re currently doing created a lot of bugs we’re fixing!’

A month later:

“We’re aiming for Q3 (October-December), we think that’s more realistic”

A few months later:

“We’re hoping to be done by early in the year… “

I have been wrong by 6-8 months on several occasions, of course every time there were reasons for it. I also became excellent at announcing delays, and with time I felt less and less bad about it. I mean, I was merely communicating what I knew at the time.

I gave a timeline because (I felt) I had to. Both customer-facing teams and higher management wanted dates so they could relay them. Inexperienced, I gave them dates I established with the team, but still a wild guess. We didn’t have enough experience of the product or the problem we’re trying to solve for users. Of course, we learned lots as we were developing the feature, and found many dependencies, blockers, technical challenges, and had to iterate some of the design. We gave a timeline, before we could even get an idea of what we were trying to size. 

I know better now (most of the time), but I think the organisation also made a crucial mistake there. They didn’t ask what was going wrong, or why I kept shifting the deadlines, they merely accepted the explanations and excuses I gave. It sent the message that it was ok to give completely inaccurate timelines, and hindered any good collaboration between product and sales/marketing.

What about not giving any indication of time

Well, that would be nice. “Hey product team, here’s lots of money, let me know when you’re done.” said no stakeholder ever. People who bear the responsibility over the work you do want to be kept in the loop, they need to manage other dependencies and report back to their stakeholders.

Not communicating until you’re done, even if it’s possible because you’re flying under the radar, is a terrible idea because you’re missing out on crucial feedback and not building buy-in with your stakeholders or customers.

It can be very tempting not to communicate when things are halted or advancing slowly– usually linked to having the right people in your team. Nothing’s going on, so why tell your stakeholders anything.

Silence on your part leaves lots of room for stakeholders to imagine what’s going on. If in a positive mindset, they may think you’re delivering well, and will get quite the wake-up call when they realise things aren’t progressing. If in a negative mindset, they’ll start losing confidence in your product or mission, and might even seek to invest in something else, or discredit you with others.

Even, if it’s not a popular message, you need to talk about what’s going on.

Giving wild guesses to get people off your back

As established above, giving wild guesses as to what is happening is a bad idea altogether. But sometimes you can feel like there’s a metaphorical gun to your head.

Then, there’s two steps to take:

  1. Exaggerate your most generous guess
  2. Ask yourself whether you want to be in an organisation like that or think about how you can fundamentally shift their thinking about product management

Communicating uncertainty

Communication comes down to being clear about what you know and are confident about, but also making it clear what you’re not certain about.

This means avoiding communicating something too specific like a feature and its delivery date, unless you’re shipping it tomorrow. Instead, having a roadmap to explain what outcomes you’re working on – when, is a better compromise.

I also like to indicate degrees of certainty alongside my predictions. Here’s the legend from my 1-3 certainty scale:

3 – we’re working on it now and know what we’re talking about

2 – we know what this is, and think it’s reasonable to assume that we’ll be able to tackle it in that timeframe

1 – we don’t know exactly what this entails, our estimate is practically a lie

I like to be flippant like that, as it makes people react and face the facts. If I wrote a euphemism like ‘least confident’ for the low end – then a stakeholder could quickly read that as ‘well, they’re a bit confident’.

Communicating the future as a product manager is easy to get wrong (and that’s ok!). There is of course ‘best practice’ out there, but you have to adapt it to your own context – like company culture, the personalities of your stakeholders, the speed of your industry etc.

However, it’s not all on the PM shoulders. To be able to do this effectively, they also require a product culture that enables them to communicate effectively. More on that later!

Weeknote: Finding new ways to learn

The last year has made us rethink how we do many things in our lives. Forced to adapt, we have found alternative ways to see friends and family, to do our work, to spend a lot of time at home… One thing that I reflected on this week was finding new ways to learn. 

There was the initial boost of creativity and impetus to try new things in the first lockdown – maybe you also tried baking, gardening and sewing. But that enthusiasm went away for me as restrictions and lockdowns became a routine. Also, I was very focused on learning crafty things – but learning at and for work became secondary.

Learning at work became secondary

The first few months, I was in survival mode as we figured out how to adapt all our ways of working to the remote environment, while also getting to grips with how the world was changing. 

Following the initial shock, I have spent most of last year on creating a work/life balance. And this has taken a lot longer than I would have expected. I have experimented with my work hours, eg when I do what type of work. I have also experimented with my free time, eg what type of activities are best to get me out of the work mode. It has been journey of self-discovery and how to best motivate myself. 

I think I’m 80% there. I still have days where I find it hard to let go of work thoughts, despite all efforts to create better boundaries.

When it comes to ‘work learning’, this has been difficult to fit into my new system. I have always learned for and about work outside my work hours, be that on the weekend, or in the evenings. It’s something I am passionate about, and it’s something I’ve always done that way (just like I write this blog). But it also means that this has conflicted with the boundaries I have been trying to set up in the working-from-home context. There are days (and they are still quite frequent) where the thought of a work-related podcast or book just feels too triggering. I am in self-protection mode, where I ward off any work stress. But through adapting to the new context, I am slowly getting to a place where I can learn again.

What learning looks like now

Podcasts: I used to listen to podcasts on my daily commute, which means that my podcast consumption went down dramatically this year. In my new routine, I use food shopping and occasional walks as my podcast time. It’s not as much time as I dedicated before, so now I curate my listening more carefully. I only regularly listen to one product-related podcast (The Product Experience), my other regulars are HBR’s Cold Call, the Wired podcast,Intelligence Squared and Squiggly Careers. They don’t specifically apply to Product Management, but are real food for thought, opening my mind to new ways of doing and thinking. 

Reading: I have been trying to read, but as I used to love reading in coffee shops (and in France these have been closed for a good 6 months now) this has been harder. While I can read ‘fun’ books at home, I have struggled to read work-related books at home. That’s to do with the boundary-management I mentioned above. I splashed out on a Harvard Business Review paper subscription, and quite enjoy the format, as I can pick it up and read only an article a time, and don’t have to commit too much.

Learning with my colleagues – This is a completely new thing for me, and a much more intentional practice that I’ve developed this year. This can take different aspects, but to give you examples:

  • I recently watched a talk with a colleague (she shared her screen and sound), and we paused and discussed what was being said, how it applies to our context
  • With the product team, I’ve been organising learning sessions. We’ve been reading Product Management in Practice, and chapter by chapter we sit down to talk about what we found interesting, and what we could take away from it.
  • We also do a product clinic, where one person comes with a problem and we swarm around the problem to think of what we might do about it.

These practices are the most rewarding and effective. They are fairly easy to do, so I manage to stay focused, they are directly applicable to my work and they have also further strengthened the ties with my colleagues. 

Learning other things  Particularly after I listened to the episode of Intelligence Squared with David Epstein, I felt even more inclined to learn about things not related to my job or career. He argues that in most fields – especially those that are complex and unpredictable – generalists, not specialists are primed to excel. So learning about random things you’re interested in isn’t only fun, it can also be useful!

For the past few months, I have been learning to play the piano – fulfilling a childhood dream of mine. I have also been doing free courses on Coursera (one on Financial Markets I recommend!) to learn about things just because I find them interesting, for the joy of learning.

Weeknote: how to get away with murder (of a product)

You’ve just joined a new team, you’re being assigned to launch a product which is nearly ready, and from the moment you set eyes on it, something doesn’t feel right. You don’t quite get its value, you don’t see how others might want to use it, it doesn’t feel right… but then you don’t know your users yet. So what do you know. 

That feeling doesn’t go away the more you learn about the product. It’s your responsibility to manage the product, but what if it was your responsibility to kill it? 

This is what happened to me last year, and here’s how it went.

I found an ally

Coincidentally a new UX designer started at the same time as me on the product. After some getting to know each other, we started to feel enough trust to speak candidly. In theory the product was ‘ready for launch’, yet we both couldn’t understand how this product was going to do well. 

It was very complicated, didn’t look particularly modern, and while it did some things well, it was a NEW site that our users had to start going to. Considering it was meant as a daily productivity tool, we really were not confident.

However, we also didn’t want only our expert opinion to shape the course of the product, and wanted to seriously consider the possibility we could be wrong. We therefore tried to approach the process as objectively as possible.

Get evidence, all the evidence

While we felt that there were some big problems with the product, we also knew that the team had been working on it on and off for 2 years and the director had been selling it to stakeholders as an answer to some of our biggest problems. So we couldn’t just go and say ‘hey, we know we’re new, but we don’t think this is a very good idea’. 

So we did the following to build a case.

A private beta

We promoted the product to some 100 odd users we randomly selected to represent different job families, seniority and locations. We intended to observe their behaviour over 2 months. We saw that most went onto the tool and checked it out. Yet, only 1 user returned. 

We sent a reminder to see whether a second go at discovering the tool (or maybe a first for those who hadn’t visited) might trigger them to come back. But still nothing. 

Apart from that one user who seemed to like it. 

Design workshops

Through several co-design workshops we explored what users might possibly need from such a tool. Previous user research had only included interviews on work habits and testing of an initial prototype. We thought a co-creation workshop might help us learn more about the daily habits of our users. We pretended we were still at an early design stage and didn’t show them the live tool in order to get a fresh perspective. 

What we found in the workshops were that the things the users pointed out to us, were so different according to what type of job you worked, what your local conditions were like and your personal preferences, it would have taken a complex and highly customisable tool to actually create significant usefulness for our users before they would start using this tool. And we certainly didn’t have the budget for that.

User interviews and tests with our beta users

We also conducted user interviews and tests with some of the private beta users to see what happened. There we learned that indeed the page didn’t meet a significant enough need and they already had their ways of getting around and checking notifications, that they didn’t need another thing to manage that.

Some of the verbatim quotes the user researcher highlighted were a brutal wake-up call.

Bringing people along

Ok, so now, we had a lot of data to confirm our intuition, we needed to make a decision on what’s next. The way we approached the above steps were crucial in bringing people along to get to that decision point. All of the data-gathering was done in full view and often with participation of the two crucial groups we needed to bring along with us – leadership and the product team.

The leadership team

We needed to get their buy-in to stop developing the product, as they are ultimately responsible for our team’s work. We knew the evidence will get us most of the way – as our leadership team is very open to our inputs and will listen to facts (not something one should take for granted I have learned). 

However, we also needed to understand internal politics and the implications that a strategy change might have for the relationships we have with other departments. We also needed to understand the potential emotional attachment the leadership team had for the product, and their openness to change course and defend a new strategy. 

All of this was important to know, so that we could manage the change for them. Through my weekly conversations, I started sharing my doubts, first subtly, then more candidly. I asked about implications, first asking in terms of hypotheticals, then talking options. I also explained our approach to gathering evidence, and what we were hoping to learn from each step. By preparing them in increments, there was never a big ‘tada’ moment in which I revealed how I knew all along that the product was a bad idea.

The team

The concerns we had regarding the team’s acceptance were different. We knew that they would go along with a decision that was validated by the leadership, but we felt it important to keep morale high, and not let this process demotivate them. After all, this had been 2 years in the making. 

Especially as a newcomer it was important that others were on the same journey. We didn’t come with a new vision for the product immediately, we facilitated enough of the reflection so that the change felt gradual for everybody involved.

The feeling I wanted them to take away was pride in the fact that as a team we were able to take tough calls to do the right thing. To listen to evidence, and challenge ourselves to build what’s valuable.

The different team members, a junior PM, a developer, a UI designer, a content strategist discovered the data with us. They had access to our beta test dashboard, and we reviewed the data together and prepared the user research together. With the UX designer, we tried not to jump to any decisions too quickly and mainly discussed the facts, and we asked the team what their conclusions were. 

When deciding what to do next, we put the team in front of 4 scenarios (including one to go ahead with the launch). We empowered them to help us shape our next steps, and in the end they all agreed to go back to the original problem we tried to address. We also showed the leadership team the conclusion the entire team had drawn from the evidence.

Reframing failure

We had a final meeting with the team to discuss how we all felt about the fact that we stopped the launch of the product. It was a bit like a group therapy session. This also marked the end of our work together, as the next stage (back to the drawing board), wasn’t going to be with the same exact team. By giving everybody one last chance at sharing how this process made them feel, it gave us all the necessary closure.

We also had a big discussion about failure, and the role it played in product development.

How we talk about failure is very representative of our organisation’s culture. The reason it was important to bring the team along in this decision is to ensure that we could talk about failure in a constructive manner. They needed to co-own the process and realisation.

Yes, we got it wrong, yes we had good intentions but we lost ourselves on the way there. Then we all used evidence to stop the launch just in time to avoid investing in a product that was truly going to be a waste of money.

We insisted on celebrating that as a team we stopped a thing that was going to be a much bigger problem. Instead of feeling like we failed as a team to launch this product, we felt proud to have done the right thing and prevented a much bigger failure.

Sometimes you’re not the newcomer

In this process I had an advantage from the start, as I was new to the team. It can definitely happen that you’ve been part of a thing and it suddenly hits you that maybe it isn’t a great idea. Yes in theory we should be reducing risk and learning as much as we can as we go along, but in practice things can get out of hand before you know it. That could be because of stakeholder pressure, the difficulty of getting data, working in a reduced team, or just not being that experienced in product management. 

So what do you do when you start doubting your product? 

I believe you can follow similar lines to what we did, just the thing that’s missing is the ‘newcomer’ effect. As a newcomer people expect you to bring a new perspective. As an established team member how can you suddenly defend a new perspective – especially if you had previously defended this product? 

I think it’s important to start sharing your thoughts with people you trust most, see what they think. Phrase them as doubts, not a complete loss of confidence in the project. Establish what you need to know to eliminate those doubts. 

In addition, use the language of risk. Explain that you’ve identified this new risk – like the project might flop if we’re not completely sure we’re solving ‘x’ problem. Say how you want to mitigate that risk, and then start the process described above. Start working with your team on this, as soon as you can.

When one realises something that feels truthful, it can suddenly appear obvious, yet it doesn’t mean that it was easy to realise it without someone pointing it out or something triggering that realisation. (Most times when I realise something about the bigger picture of my product, I get the immediate feeling of ‘I should have realised this ‘x’ months ago’.) So, be kind to yourself and act with what you know now. It’s never too late to make the right decision and to change course in order to achieve user value. And even if it might be a tough thing to do now, in the long term the focus on user value will always be the right one.

Weeknote: Performance review

Last week I had my performance review, and for the first time I actually enjoyed it and was grateful for the conversation we had.

Until recently I would have described the performance review or annual review as the yearly awkward moment to talk with your manager about your achievements and skills.

When I worked at smaller companies, there wasn’t really a process, it was just a discussion based on impressions and opinions, a retrospective on what had happened. Sometimes it was an opportunity to set yourself learning objectives, but it wasn’t really helpful in making me think about myself. 

In my last job, the annual review looked at your objectives (that you had set yourself) and depending on how well you achieved them, you got a specific mark. As product manager that was often a bit difficult , as the success of your product and your objectives may depend on all sorts of circumstances outside of your control. Most importantly, it also never really gave me an indication as to how I could personally grow. 

I want to emphasize that this isn’t a stab at my previous managers, who helped me in many other ways. I firmly believe that they were not given the right tools to do performance reviews well. 

What specific process are we talking about?

I attribute the fact that this year’s experience was much more positive to the process set within Ubisoft, and to my manager who knows (and has learnt) how to have these meaningful conversations.

You’re evaluated against attributes defined by Ubisoft HR. They include your job competencies, how well you achieved your objectives, your leadership and your collaboration skills. I don’t think it matters whether these are the best attributes, but what’s important is that they look at your individual performance from different angles. 

This is what happens in practice:

  1. Line report or manager seeks feedback from closest colleagues
  2. The manager sets a mark against each attribute
  3. The HR Business Partner meets with the manager to discuss each of the marks and act as calibrator to challenge your marks (and in practice they don’t consistently challenge downwards, as you may cynically assume)
  4. Ahead of performance review, both the line report and manager add comments against each attribute in our performance tool – these comments are only shared the day of the review. The manager’s comments will include the mark as well as quotes from colleagues’ feedback.
  5. During the review, both discuss what they have written, talking strengths and opportunities for growth.

(There is also an element of performance-based salary, but I’ve left that out, as it wasn’t what made the process so different.)

Why was it better this time?

I tried to figure out what made the process so much better, and I have boiled it down to the following factors (which are somewhat difficult to emulate at an individual level, and mainly come under the organisational processes):

  1. Individual performance and competencies are evaluated, not objectives. This allows a tailored conversation on skills and self-discovery, not one focused on external factors versus personal input.
  2. The organisation trains their managers:
    1. There’s a 5-day management training for all new managers 
    2. Prior to the review, lots of drop in sessions with HR are available
  3. The manager is forced to spend considerable time to reflect on their line reports’ performance
    1. They have to justify each mark to the HR Business Partner who will ask probing questions
    2. They have to add comments against each attribute into the internal tool
  4. The line report also has to reflect on each attribute (and can’t just show up) because they too have to add their comments in the tool

Nothing I have written here is particularly revolutionary. Yet, this well-executed performance process made a real difference to me.

It helps me be a better manager

I directly manage 6 product managers and I now feel much more confident about having the performance conversation with them. In retrospect, I cringe at performance reviews I have held in the past. I’m grateful for having experienced this process, which will change how I do them from now on.

In preparation for my team’s performance reviews I’m also reading Petra Wille’s Strong Product People, which is about managing and helping Product Managers grow. I’m only halfway through but I’ve already drawn lots of useful things from thinking about my team’s development.

Weeknote: When you can’t solve the problem

I wrote this reflection a while ago, but as this week has been intense and my thoughts are all over the place, I thought I’d share this.

It’s a drab drizzly day in January. I’m queuing at the post office. Courtesy of covid-19, we’re of course queuing outside. There’s also a queue system inside: There are 4 queues, one for the bank, one for the post office, one for the ATM, one of the post office self-service tills. The queues with people (post office and bank) are very slow. The two with machines have no-one. Yet, the member of staff guarding the door insists on us queuing in one queue outside. 

I need the self-service tills, several people in the queue simply want to go to the ATM. We’re fuming. There’s no reason for us to queue in the cold. Some give up, whispering insults under the breath. My heart is racing, I’m pissed off. This is my lunch break, I’m wasting my time. 

Then I remembered a thing my high-school French lit teacher said:

‘There’s 2 types of people in life. There’s the person walking home in a snowstorm at night, gripping tight onto their collar, swearing and cursing, eager to get home. Then there’s the other person, who’s going through the same snowstorm yet whistling their favourite song.’

I often think about that, even if I feel Monsieur Tenret probably forgot he said this in one of his many tangents. Too often, I am the first person he described. Frustrated with the world around me when things don’t go my way.

It’s especially bad since I’ve been working as a product manager, because I made it my career to make things easier and better for users. And I know how they could fix this bug or that workflow on a website. It got so bad, my husband sat me down one day and asked me to stop complaining when a website or app was terrible. 

Similarly, since working at the UK Government Digital Service, I have much higher expectations for public services, and a much lower tolerance for absurd bureaucracy, because I know they can do better.

But here I was at the post office, suffering another pain sprung out of someone’s process they had devised. But I thought about M Tenret’s point, and I needed to let go. Yes it sucked, and yes they could do better. But right now they didn’t, and I could just stand here, breathe, maybe listen to some music,or a podcast, and have a good time. Then I really won’t be wasting my lunch break.

Weeknote: product communities and networks

This week I have been thinking about product communities. In my last organisation, there was a fairly active product community, both at cross-government level and within the organisation. However, in my new job, there is no such community, as our product team of 7 is integrated in the ‘business’ and fairly isolated from other PMs.

For the last few weeks, my colleague who supports communities of practice across the company has teamed up with me to find those other product managers. Because our main business is video games, and product management is in a supporting role, product people don’t sit in the same departments (nor countries) and therefore don’t know each other. The organisation also grew organically so it’s even hard to look for people by job title. For example, we have already discovered that ‘IT project management’ could mean you could be a product or a project person. There is also a role called ‘product specialist’ that we aren’t yet sure about.

Yet, we have started finding pockets through reaching out to people recommended to us and their subsequent recommendations. We’re curious as to whether there is an interest in a company-wide product community.

What struck me was a conversation my colleague had after she found a small community of product managers, all from the same department. They had a structure and sharing practices in place, so this seemed to be a good find. Yet what a person told my colleague was that they are happy with their community how it is, and don’t think that other people in the organisation would have the same challenges so wasn’t quite interested in a company-wide community. 

I was very surprised when she told me that. I automatically assumed that product communities are great! So why didn’t that person realise that? As I didn’t speak to the person, I can only make assumptions as to what created such doubts – maybe a fear for how much work it would be, maybe a lack of confidence in the quality of product management in other parts of the business? Most importantly, maybe what wasn’t obvious to the person is that we need communities – plural.

Therefore I thought about the different communities that form my product network.

1. PMs who work on the same product or domain in your organisation

That’s simple, that’s the product managers I work next to. We’re a team of 8 and we meet twice a week to share what is going on with our products, so that we can manage dependencies and identify opportunities for collaboration. We also do learning activities every month. For that we watch a talk/ read a book chapter/blogposts and discuss them. We also have monthly sessions to inspect our product practice (I wrote about this here: Setting up a product practice).

While this group will understand your problem space well, they will also have the same assumptions as you, and won’t challenge you in the same way someone external might. What I’ve also found is that sometimes it’s difficult to focus on the product craft, and dissociate it from team challenges we experience.

2. Organisation-wide product community

That doesn’t currently exist for me, but from previous experience, it’s a coming together of product managers every month or every 2 months where different people may present what they’re working on, a specific method they’re trialing or hearing from people in other disciplines (UX, accessibility, tech…). Of course this only makes sense when the organisation is of a certain size.

This community is better for talking about the product craft dissociated from specific team issues, but still within the context of your organisation. While our products may vary vastly in terms of what problems they solve, we can see how they complete a bigger picture. We can also identify opportunities for collaboration and to reduce duplication of work. Plus, sometimes you want to talk candidly about organisational challenges and that tends to be easier within the company.

This type of community will make us all better product people, and a company should really invest some resources in helping to organise it, as without a structure, such as a community lead or a committee, this will very quickly fall apart.

3. Product communities outside of the company

I’m typically thinking of the networks that exist on Meetup, such as local chapters of Product Tank or Women in Product, and other such networks. They are a brilliant resource because they bring together a large diversity of voices, allowing you to learn about new practices, reassure yourself that everyone has the same problems and learn about how other organisations do product.

These often rely on the goodwill and enthusiasm of a few people, but those that persist over time tend to have really good content.

4. Personal network of PMs

This is less a community in the strict sense, but more my personal network of people I regularly catch up with to talk product things. They are all people I worked with at some point. I tend to meet them one-to-one on a monthly basis. These conversations help us both reflect on our practice, and offer suggestions and ideas to the other person. In this community is the product circle my PM friend Tobi wrote about as well as people I mentor and support in their journey across the product management jungle gym (we know it’s no longer a career ladder).

Why it’s important

All these communities bring complementary benefits, and any product manager not taking advantage of these networks is missing a trick in growing themselves and their practice.

Having more than one community also creates resilience and allows you to be flexible when you’re moving countries/cities or say – the world is going through a pandemic. While going to product events was part of my routine when I was living in London, in the last year I’ve been much more engaged with my personal circle and the immediate PMs I work with. While industry events will still help you gain knowledge, there is a gap of personal connection, which I now get from my smaller networks.

In the meantime, I will also see what I can do about a company-wide community. Even if it starts small, I hope it’ll be a fun project over the next year to try and spark a product conversation.

Weeknote: How do we know how much others need to know?

As product people one of our roles is to ensure people external to our team know what is going on and where we’re heading. That is simple enough as a principle, yet in practice, this is hard.

The situation

This week, I’ve trialed an email to share updates across all our products to send to the whole department.

We know people have been asking for more information as to what has been delivered and what’s coming. They told us so in person but also in a survey we conducted. But the question I was struggling with was – how do we know we’re providing the right amount of information?

People are likely to speak up when they have too little information. Maybe not immediately, maybe not obviously. But what struck me is that people never (rarely?) complain about there being too much information. That is also a problem, because too much information makes it harder and sometimes impossible to get to the information that is needed.

For me there’s two imperfect but complementary strategies:

  • Understanding our stakeholders, their role and the pressures they face
  • Trial and error, and getting feedback

Understanding our stakeholders

If we invest time in understanding the people who need information from us, we’ll be able to adapt our communication. Spending time with them, shadowing them, seeing client meetings first hand can help us understand what type of information they may need. And we should definitely do this. 

However, this strategy isn’t perfect: 

1 – This takes time, and when we’re new (and product people do tend to move products if not jobs fairly regularly), we can’t wait to fully understand all our stakeholders, before we need to share information. Getting them to trust us and for us to understand their world will take time.

2- Things change and we can’t predict all the changes that will occur. That could be new clients, industry changes, a new tool. We have to try to keep up with them, but doing so in real time is often impossible. So we’ll always have to combine that with the trial and error approach.

Trial and error

Trying something out and getting feedback complements the first strategy. We can make some informed guesses about what would be useful and seek feedback. However, I have often heard people say ‘we stopped sending out that information because we didn’t know whether it was helping anyone’. 

For this approach to work, we have to be proactive and persistent. We have to spend at least the same amount of time trying to elicit feedback, than we spend writing the information. 

If there’s too little information, people might ask follow-up questions. While stakeholders will not be able to tell us that they need to know about something they don’t know exists, they might tell us that they needed certain information earlier. So we’ll get feedback, even if it’s a bit later.

However, I’ve never heard anyone say : “there’s too much stuff in your update that I don’t bother reading any of it”. Even though I hear people say it about other people’s updates and presentations ALL the time. 

And I know I’m guilty of the same. How often do you admit to someone that you don’t read any of their updates or emails because they’re too long, too confusing? Yep. Somewhere between not wanting to offend, and not wanting to look like we’re not doing our job properly, we’ll never say that. We also might assume that maybe it’s just us that don’t find it useful, so we don’t want to be the person to complain about a format that must work for everyone else.

What we can do to prevent this as the people providing the information:

  • in doubt, keep it shorter and only add more if requested
  • provide easy opportunities to access further detail
  • most important: spend time learning to write clearly and format well (or ask someone who can help us with that)

Finally we need to also accept that our communication is never going to be perfect, and therefore we can only strive to making it good enough.

In conclusion

I hope this week’s reflection is interesting for some. I worry a lot about striking the right balance, not wanting to overthink things to prevent me from moving fast enough, while also not wanting to storm ahead and having to deal with the consequences of implementing a half-baked idea. So with the release notes, I went with my experience with what had worked before, plus what I’ve understood our stakeholders need, even if the information wasn’t perfect. Let’s see what the feedback will be!

Weeknote: the surprisingly good day

Ok, that’s it, I’ll try it out! For several years I’ve been seeing colleagues and people on Twitter write weeknotes, and I’ve finally reached a point at which I feel like I should do it and I have sufficient motivation and courage to do it.

Something happened this week, which brought it home to me how journaling can help you.

Last Thursday evening, I was in a good mood and I couldn’t understand why. My week had been pretty standard, nothing special to see here. To give you some context, I generally finish work feeling mentally exhausted. I can’t even read a book about work, an article or even podcast in the evening. I find them just too triggering. (working from home clearly isn’t the panacea).

But not on Thursday. I went back to my laptop and read stuff about digital employee experiences.

What was going on? I couldn’t explain it, but I enjoyed it.

On Friday, I was too intrigued. I needed to understand what had created that positive feeling, and how I could make it happen again! So I wrote down what had happened that afternoon (I boiled my feelings down to the events of the afternoon, as I had a quasi-breakdown over Jira in the morning. There were tears. I think we’ve all been there).

In the afternoon, I had 6 meetings, all back-to-back with different sets of people. I don’t want to go into details about the meetings ( as it’s probably quite boring for you, and the not-so-boring bits are probably the ones I can’t write about publicly). Overall, I met with

  • a team we previously had a strong disagreement with
  • the product team to discuss a feature improvement
  • another team and the leads to discuss the collaboration with a supplier
  • a team with whom collaboration has been tense in the past
  • our design lead

While I expected some of those meetings to be quite easy (my one-to-one and the product team chat), that wasn’t the case for all of them as you might imagine.

So what was it about the meetings that had made me feel so energised?

I could rule a couple of things out: It wasn’t about the specific people, as I saw a few people twice during the afternoon but always in a different configuration. No meeting resembled another one. I also hadn’t done anything special at lunch time, or had got particularly good news.

Once I had written down in more detail what the meetings were about, I could finally see what the common factor was: the level of trust was high. By that I don’t simply mean for me personally, but in general for the whole room. It’s rather difficult to describe and you might think this is quite subjective. I understand. However, I also noticed the absence of markers that have been quite common in our meetings:

  • people stay quiet and later tell you they’ve been annoyed by something that was said in a meeting
  • Tumbleweed moment when walking through a plan (nobody has anything to add, or just one person says that the plan sound good)
  • People taking a sharp or accusatory tone
  • Rehashing of things that had gone wrong in the past
  • Blaming something we can’t change for our problems

None of these happened, but what did happen was that people:

  • cracked jokes
  • shared how they felt
  • challenged what others were saying with empathy
  • asked thought-through questions
  • took responsibility over things that happened
  • recognised that others did the best they could

This day was different.

I think what amazed me is how much this change affected me personally. Clearly the lack of trust and psychological safety in some of our meetings and collaborations has really been wearing me down. Despite most of my interactions with my colleagues being actually really positive, the few meetings that are more difficult (and some weeks there have been more than a few) clearly really affect me.

I don’t know whether that’s particularly the case for me. I suspect that most people will have somewhat similar reactions to me, though maybe stronger, maybe much more fleeting.

Next week, I’ll start tracking where I feel high or low levels of trust. I hope that’ll give me some indication as to where we can make things better.

Also, it was really clear that it is much easier and faster to get things done when we do trust each other and can challenge each other with empathy.

When trust isn’t there, I’m not sure why we bother trying to get things done. We should figure out how to work together first, even if it’s hard. If we don’t do it, the value we’ll be able to deliver will be negligible compared to the effort it’ll take to get something done, and the emotional strain of disagreements further down the line.