Weeknotes #154

Interviews vs. group challenge

I’m recruiting a Product Manager to join our team. We’ve been lucky to receive lots of applications. The challenge for me is in recruiting for a organisation I’m very new to, and knowing that the skills and practices we need now might be different to what need in a year or two. Part of me says I need to have a clear idea about the person I’m looking for, and another part of me says I should be open minded to allow for someone to bring something I wasn’t looking for but might need.

I always find recruitment hard. Partly because of the responsibility to get it right for the organisation and partly because of the impact it can have on the people involved (the people who don’t get the job, the person who does get the job, and the people in the team they join).

I did eight telephone interviews and two face-to-face interviews. I’ve got three more face-to-face’s to do next week and then we’ll have a second round of interviews with a presentation to some stakeholders. I’m not convinced it’s a great way to interview and recruit. I think it relies too much on them being able to extrapolate their skills and experience from their current context into what they think we’re looking for, and then us to be able to extrapolate from what we understand of what they say and fit it into our context. There seems like lots of opportunity to misunderstand. I wonder if it would be better to pay them for a day to get them all in a room and present a real problem that we have, along with all the contextual information, and then see how they work as a team to approach solving the problem. I get it might feel like we’re pitting them against each other, but that’s what implicitly happens in interviews anyway and at least this way they can all see what they’re up against and do something about it. I also think it’s closer to demonstrating the skills and behaviours we’re looking for, e.g. approach to problem solving, working as a team, curiosity, communication. Unfortunately, I don’t think our recruitment team would agree with me.

Visualising work

One of our Product Managers led her first ever workshop with twelve stakeholders from different departments. She started quite timid but quickly grew in confidence, got them thinking, and generated lots of ideas about things to do with the current product, areas of research, and things to explore for the new product we’re working on. It was fantastic to watch.

The interesting thing about the workshop was that we used different techniques to get people engaged. We switched from individuals writing on post it notes to group discussion to taking turns talking, to writing on whiteboards. This way of working doesn’t happen very often. Most of the time when people get together to work they sit around a table and talk, or at best share a PowerPoint presentation on a large monitor. Leading workshops is definitely something our PM’s need to be good at. I think it opens up different ways of thinking and captures those thoughts in a visual and open-to-all way that helps to create shared understanding in a way that just talking about something can’t achieve.

My roadmap

I’ve been working on my personal roadmap for my time at BSI. I bought Product Roadmaps Relanched and have been reading posts about roadmapping, including some by Jamie Arnold to try to frame my thinking about using roadmaps for understanding and planning work.

Roadmap

Having a personal roadmap gives me single place for all the things I’m working on now and in the future. It helps me to prioritise my time and focus, broadly in three areas; People, Products, & Process (although I’m thinking of changing this to Practice). Each of these columns is a ‘mission’, has a objective, and if I get them right, these three missions will multiple each other and achieve the greater mission for Product Management at BSI.

Personal roadmaps have a slightly different focus to product roadmaps. They aren’t about developing a shared knowledge or communicating with stakeholders, but they are very much about identifying opportunities and setting direction to explore those opportunities and make decisions about what to and not to focus on. It’s more than just a backlog/to do list (I have one of those too), it helps me strategise about what to deliver to achieve the mission. It enables a force ranking of the opportunities (compare two things and ask which is more likely to contribute to achieving the mission), limit work in progress (setting the cards I’m working on to ‘in progress’ helps me not start new things), and ensure I’ve captured all the ideas and opportunities for the future (as these help to remind me to embrace uncertainty in setting direction), all of which help with focus, which is our great challenge.

Project managers are people too

There is some longstanding animosity between the Product team and IT Project Management Team.

One of the business project managers from a different team’s approach to challenging this was to be demanding of them to the point of making the IT Project Managers feel uncomfortable for not having all the answers, and I think others have taken this lead and began to copy it. I think this is unproductive. People who feel bad don’t get better at their job. People who are positively motivated to feel part of a high performing team do.

The issues are in the function of IT Project Management and the value it brings to the business, not in the people who have to work within that. If Project Managers are expected to be administrators who organise meetings then that’s the level they’ll work at. Project Managers who feel like they own the solution the project is implementing will be motivated to excel.

So, I’ve been showing more kindness towards project managers than usual. I refuse to be negative towards them. I want to model good behaviour for my team and I want to maintain my own integrity about how I treat people.

Tee-ing off

We had our Team Away Day. It was a chance to get everyone together out of the office and have a bit of social time together.

We had a little challenge to test our problem solving and communication skills (both things Product Managers should be good at). We were each given a part of picture which we weren’t allowed to show and had to communicate to the team what was going on in our picture and then work out the relationship between all our parts to construct a larger image. I think it took us less than two minutes to figure out that the relationship between the parts was zooming in on a smaller part of the previous image, and another four minutes to describe and order the images to create the final picture. We then questioned how the Sales Team would have fared, and whether they would have wanted to talk over each other, and then what if the group doing the exercise had people from different teams.

Our Director of Product talked about some of the challenges he saw for the team, including:

  • Getting closer to customers – This was number one of the list, and if it isn’t already, should be number one on everyone’s list. It’s not something the Product Team has done very much of, and there are lots of barriers; from just being too busy to take a day out of facilitating features, to not really being sure how to ask customers if we can visit, to fear of getting negative feedback about the products and dealing with that in positive way.
  • Measuring what we do to show value to the organisation – I’m keen for us to move away from obscure output measures (work requests submitted, features delivered) to outcome measures around driving customer behaviour. This requires some strategic understanding and thinking about what behaviours customer want to do (which is why we need to get closer to customers), and what we can do to make those behaviours easier for customers. Once we know these we’re in the position to say these are how we want to be measured, but until then people will always default to the easier to grasp operational outputs.
  • Telling the story of the product – This is an interesting one. I haven’t got even close to an idea about how we do this effectively yet, and from discussions I’ve had (including throwing it in as an interview question) no one else has any idea either. I’m still thinking it starts with the heroes journey elevator pitch I was thinking about a couple of weeks ago to tell the customer’s story, and then through user story mapping we can understand in more detail the steps we need for the customer to go through that journey. We then need to wrap the design and implementation around our understand of what were doing and why were doing it. This approach puts ‘why’ in the middle, and includes the ‘what’ and the ‘how’, and I’ve no doubt people will also expect the ‘when’. All of this is leading towards a roadmap that helps us tell the story.
  • Collaboration between the two product teams and with other teams – In an organisation that culturally values golf teams more than basketball teams (I’ve realised this isn’t a uniquely Product Team phenomenon), how we work together collaboratively (and whether that is even the best approach for us) is a huge challenge. I think the first step is to stop departments competing with each other on the same business opportunity and market share, but that requires changes at the highest level of the organisation. Perhaps there are some margin gains to be had at the lowest levels of working but there are far more isolationist and adversarial behaviours going on, so we’d have to break those patterns before we could given begin to work collaboratively. Perhaps working cooperatively is more realistic first goal.
  • Accept risk, take action – We do play it too safe. As a team and as an organisation, but if there is any team that should be a position to accept more risk and take action more quickly, then it should be Product. Of course, just saying, “Take action” doesn’t help people understand what is being asked of them; in what direction should they take action, how do they tackle the barriers to action, etc., but we absolutely need to build motivation and capabilities behind having a bias for action rather than the ‘wait and see’, ‘softly softly catchy monkey’ approach that we end towards.
  • Changes – The future of Standards, of BSI, of the Product Teams, and of how we work looks nothing like the how it is now. We have to figure out how to change to be part of the future, and how to lead into it. How to face an uncertain and ever-quickening changing future is the challenge of our time. It’s far too easy for us to fall into following the path of least resistance, put our head in the sand, get on with the day-to-day work and not do anything about it. Right now, we have a choice. We can choose how we face the future. Soon, we won’t have any choice at all.

I told the story of my first six weeks and the 142 meetings I’d attended. I talked about how the new product we are developing will be an enabler for the ways of working we want to adopt, and how it will challenge us to elevate our thinking, and how Product can and should lead the way in understanding the customer needs, our organisation’s value proposition, and bringing those two together. I talked about how inspired I felt to be part of a team that through it’s good work, help the organisation do good things that improve our society. I ended with, “I’m looking forward to my next 142 meetings and being part of showing BSI the value good Product Management can bring to the organisation.

I din’t have any slides or handouts, and choose to present in a very impassioned, story-telling way. I wanted it to feel like I was talking about my personal experience rather than just relying the professional position of our Product Team. I wanted it to feel more like a recounting my reflections and thoughts about the future than a strategy or plan. I wonder if those listening felt any difference between my presentation and the other presentations which did have hand-outs and were much more corporate in their style.

One of the things the Labs team mentioned in their presentation was Malcolm Gladwell’s 10,000 hour rule. Whether 10,000 hours is the magic number required to become an expert is questionable, but the idea that sustained meaningful practice over a long period being necessary in order to become really good at something got me thinking. It makes sense if you want to become a chess grand master or champion tennis player (anything where there is an objective and comparative measure), but does it work for being a really good Product Manager?

First we need to identify what we want to become really good at. Given a limited amount of time, should we pick fewer things, or even one thing, or lots of things? If the aim is to become a good PM then I think you’d probably need to practice all of the skills, which of course means identifying all those skills, and then creating opportunities to practice them.

If you were to spend four hours a day five days a week doing actual product management work it would take two and half years to clock up 10,000 hours, and I’m not sure we can manage four hours of meaningful practice a day.

I’ve got lots to think about for getting our PM’s to take the longer view and focus on meaningful practice and improving their skills rather than just getting stuff done in the short term.

In the afternoon, we played Disc Golf. It’s one of those interesting niche sports that very few people know about but those that do are very passionate about. I think mountainboarding (another sport in the same situation) has ruined my chances of every being good at Disc Golf as in order to throw the disc effectively you need to have your lead arm and lead leg on the same side of your body (right or left), whereas I’m right-handed but left leg forward. I feel like I’ve dealt with the disappointment of never becoming a champion disc so I’m going to move on with my life.