Tag: BSI

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.

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.

Focus and freedom

Team focus for this week has been about figuring out how to take away work they shouldn’t be doing so they have the space to do the work they should. They struggle with focus, feeling that they are responsible for everything that happens with their product and I need to help them become leaders who guide the business. The two areas of work I’m going to tackle first are support queries from customers and delivery management. These are things that are somewhat within our team’s control so they are quicker wins for freeing up time for the PM’s.

I had a good chat with one of the team about shifting roles to be more of a Delivery Manager. She said yes, as long as I could tell her what to do and when to do it. I replied that we could certainly agree on what she should be trying to achieve but that I would never tell her exactly what to do as I think we should be shaping roles to fit people, not the other way round. I want her to be able to use her strengths to achieve things rather than feeling like she’ll always be struggling against ways of working that don’t recognise her as an individual. Communicating can be done in lots of ways. If your a people-person (whatever that means) you might do it by talking to people, and if your an accurate-detail-oriented person then you might do it by providing information in a spreadsheet. Neither is wrong and both can achieve the same thing.

Next week I’m putting together a training budget to get my team to conferences and on training courses. This is part our ambition to show the Product team as experts and leaders in the business rather than order-takers for features. I still want to see if I can arrange a visit to the HMRC Product Team, and I’ve also been thinking about how we might be able to get knowledge and insight from the BSI Sector Teams in order to help us understand the wider market of Standards. I also want us to arrange customer visits soon. I know it’s a scary concept for some of the PM’s, and they’ve hinted at this with comments like, “but my customers are internal people who request changes to the product”. No, those are your stakeholders, your customers are the people that use your product to achieve something they value, and you need to understand what they want and why.

Who is responsible for the solution?

I spent some time thinking about how and why work is sized. There seems to be a weird organisational thing where if a piece of work is sized as small or medium it is considered not complex enough to need a Business Analyst to work on it, but if it’s sized large or extra large then it’s regarded as complex enough to need the support of a BA. The really weird thing is that Product has to pay IT for using their BA’s, even though IT do the sizing and we don’t get to decide whether a BA is required. This led me to thinking that if we sliced all of our work small enough it would never need BA support, we’d save money and deliver more more quickly. But that led me to uncovering the gap in how products are built and maintained which I think explains why it’s so hard to get anything done right; there is no solution design.

Solution design is implied, I think, but it’s never explicit. For small and medium work the assumption is that the solution design has previously been done before the work request was submitted. And for large and extra large work the assumption is that it will be done during the business analysis process, although again, those assumptions are never made explicit and the work of designing the solution to achieve the outcomes for the customer and not adversely affect current business is never done.

We have work request documents, high level business requirements documents and user acceptance documents, all of which describe the end state (often in different ways) but we have nothing to describe what is going to be built. Without a shared understanding of what to build and how it is going to impact other business processes, it’s no wonder things get delayed, built wrong, and increase the burden on UAT to reveal all those misunderstandings. The question I’m left with is who is responsible for solution design? It fits into the Development phase of our product management process, which is in the solution (rather than the problem) space, but I’m concerned that the PM’s will be the only ones with enough cross-functional nous to do it effectively, but really they should be focused in the problem space.

Using the process to design the process

Had a really good workshop with two of the team to decide how we want to set up Aha to reflect and support the new practices we’re going to be using. It was interesting to see the understanding of the how we want to change our practices grow during that two hours but most importantly we made decisions. That seems like it’s often a difficult thing to do. That needs to change. Product Managers might not be responsible for making decisions but they should be responsible for the pace of decision making.

As for making the change, we’re getting clearer about what it’ll look like. We’re using the Discover, Define, Develop, Deliver process discover, define, develop and deliver our Discover, Define, Develop, Deliver process. Part of that is about how a piece of work moves through those steps in Aha from being an Idea in the Discovery phase, being promoted to a Feature for the Definition phase, the Feature being prioritised on the Backlog for the Development phase, and then added to a Release for the Deliver phase. The other part is showing the team the tools, techniques, outputs and metrics from using the process and using Aha. There are lots of tightly held assumptions that ‘this is how we work’, that we’re going to unravel and challenge the PM’s to shift their focus from the development and delivery of features to the discovery and definition of opportunities. They are going to need to think bigger, and I’m going to need to put the things in place that let them do that.

When do you do your homework?

We’ve been doing user acceptance testing on the latest round of work. It has been haphazard at best, precisely the opposite of what good testing should be. We test based on our understanding of what we were expecting the results to be because of our familiarity and knowledge. Not a good way to test. All of the PM’s left their testing until the last day. This is behaviour that tells me that a) they don’t prioritise testing over other work, and b) they don’t really want to be testing. It’s like leaving your homework till Sunday night.

It’s another area of work I think we should take away from the PM’s but its going to be a bigger shift than removing support queries and delivery management, so it’s going to take a lot longer. And it’s not just a case of telling the QA team that they are now solely responsible for testing as the quality isn’t there yet. So, part of the shift needs to be building up the QA team to be able to test with more rigor and contextual understanding, and the even bigger part is nailing the solution design so that testing can be against the impact of the work not just does it technically do as expected.

Tweet of the week

My favourite tweet of the week was from Ben Holliday, Chief Design Officer at FutureGov. I’m a big believer in hustle and creative problem solving over blindly following procedures. I know the PM’s in my team do work this way sometimes, but it’s definitely a skill I want them to improve upon. I’d rather they were figuring things out by talking to people, scrawling on postit notes and trying new things than sitting on their own typing things into a spreadsheet.

It’s my second week at BSI and I feel like my rate of learning has increased since last week and I’m getting a clearer picture of how things work and what things need to change. I don’t think my thinking is quite big enough yet but I’m happy to focus on fixing foundational things over the next few months.

The conceptualization I developed last week to describe the three areas of work is holding true. People, Process, and Product are still my priorities and I’m getting a clearer idea of what needs to be done with each

Process: learning by doing

I’ve been increasing my understanding of how the current product development and management process should and actually does work.

There are lots of smaller parts to the process that need drastic improvement, such as how we prioritise work for development without 3 and a half working hours spent force ranking a list of features into priorities based on knowledge only one person holds. We need to think about how to formalise the prioritisation as ‘seizing opportunities and avoiding risks’ so that ultimately the work can be perpetually prioritised in Aha and the IT Project Managers can access it any time they want, but that’s some time away yet.

But before we get into those smaller optimizations we need to get the overall process in place. We going to experiment our way towards the best process but we’ll start by using the double diamond to give us four broad phases: Discovery, Definition, Development and Delivery. To make it clearer for everyone I think we need to map the diamonds to functionality in Aha, some tools to use, and the expected outputs.

Discover

This is the ‘why’ of the entire process. It’s where we should ask bigger questions about whether this is an idea worth exploring, whether it seems to fit with our strategy, and what outcome we think we might be able to achieve for the customer.

We use ‘Ideas’ in Aha for this, which is where we record the outputs from our discovery work which might include market research, customer interviews, internal infrastructure investigations, etc. This stage is meant to be expansion and all about collecting everything we need to understand the problem but we shouldn’t be coming up with solutions yet. Once we’ve done enough discovery work we’re score the idea on it’s desirability, viability, feasibility and strategic alignment to decide whether the progress with the idea.

Define

This gives us the ‘what’ that we’ll be working on. It’s where we take the expansiveness of the ideas that we’ve agreed to progress and tighten it down until we converge on a solution. Some to the tools for doing this might be a cross-functional team workshop and writing user stories.

In Aha the Idea gets promoted to a Feature and this is where we’ll continue to record all the work we do to ensure that we don’t lose any useful information or insight. When we’re ready, we’ll push the user stories from Aha into Azure DevOps for the IT team to see what they’ll be working on (although they’ll already know as they were involved in the discovery stage).

Develop

This section gives us the ‘how’. It’s the part of the product process where the developers work on the user stories that we wrote in the Define stage.

In Aha the Feature will be prioritised in the Backlog, which will replace the need for prioritisation meetings with IT Project Managers as they’ll be able to see a perpetually prioritised list of things to work on.

Deliver

And this part is the ‘when’. It tells us when the work will be released into the production environment.

In Aha the Feature is added to a Release that matches the release schedule that the IT team will be working to.

Discovery and Definition cover the problem space and is where we should be spending most of our time, and Development and Delivery are in the solution space.

In the medium term we’ll working towards turning ideas into opportunities rather than thinking about each idea leading to a single feature in isolation. Then, opportunities should lead to outcomes for customers, so for example an idea to change the content delivery network would be part of the opportunity to improve the infrastructure of our products, which adds to the customer’s outcome of using secure, reliable and scalable products.

Experimenting with our processes

Next week we’re going to start our first experiment.

• Why: Inspect & adapt to improve. Safe-to-fail space to try different things. Evolve towards a process that is easier for us, more fit-for-purpose and achieves for the business, and delivers more value to our customers faster.
• How: Pick a problem area within our process, understand the problem (discovery phase), agree what change we’d like to happen and how we’re going to measure it (definition phase), think of lots of ways to solve the problem and pick one to try (develop phase), make the change we decided upon and see what effect it has (deliver phase). So, we’ll use a product development process to experiment with and improve our product development process whilst learning how to evolve the process.
• When: Every two weeks, starting 17th June. We’ll try meeting on Monday morning to pick the problem and experiment with the solution over the following two weeks.
• What: We’ll spend a bit if time choosing our problem-to-solve for our first experiment. I’d suggest that we start with parts of the process that are within our control, e.g. creating a shared knowledge bank by working in the open and keeping Aha Feature cards up to date with the progress on that Feature so that over time.

Challenging myself to not go rogue

In previous roles ownership/accountability so I could go off on my own to get things done. I have to keep holding myself in check in this role to prevent myself from doing that. Now I need to take a more responsible for direction/leading role and temper bringing people with me with understanding where they want to go and helping them get there.

Working in the open is definitely not part of the culture. I even had comments about my wall (a rogue behaviour I’m not keen to lose) being wiped clean because of the risk I might share business secrets. That tells me it’s a problem-to-solve and one we’re going to work on as a team.

People: changing the space the Product Managers work in

I’ve been looking into which stage in our current process for developing a feature the PM’s spend most of their time, and it looks like it’s at the development end where they seem to fall into multiple roles of doing a bit of admin work, bit of project management, bit of business analysis work, bit of delivery management, and then spending a bit more time fire-fighting issues and liaising between IT to make sure work is delivered. This really isn’t where they should be spending their time, but I think I’m beginning to understand some of the reasons why. There’s a bit of the PM’s not having a clear perception of what their work should be, and a bit of a lack of trust in others. Whereas other organisations might have delivery managers to oversee that part, here the product managers feel like it’s their responsibility.

There are two parts to changing that; one around removing that work from them to give them the space to do the things they should be doing, and another around changing their aspirations and skills so they know what to do and how to do it.

I’ve started looking into the production support process, which isn’t very clearly defined, to try to remove the first line support from the PM’s role (and perhaps moving it to a Customer Success role in the future). And I need to spend some time with the Product and Project Managers to try to help them get clearer ideas around how is responsible for what during the development phase.

I had an idea that if I could find a similar organisation with a more mature product function perhaps I could arrange a visit so we can see how their product managers work. I thought of a few different sectors to look at but like the idea of visiting the HMRC product team. There seems to be just enough similarities in that both organisations provide information services to businesses without being too similar that we fail into the trap of trying to copy what they do. We somewhere aspirational not instructional. So next week I need to work on making it happen.

I have to keep reminding myself that process can change far more quickly than people are likely to so I have to keep sense-checking myself that all these things are on the right trajectories so that they can meet at the right point in the not to distant future.

More broadly than within the team, I spent a bit of time thinking about the stakeholders for the products I’m involved in and what their motivations are. It’s clear (if a little frustrating) that most people just want to do their job without having any interest in their industry or sector, and are motivated by an external locus of control. This makes it a little easier to understand their hopes and fears in the short term but it makes it much more difficult to encourage improvement over the longer term. People that live and breathe their industry generally want to get better at doing what they do. Anyway, understanding people’s motivations behind the decisions they make is something I want to develop over time.

Product: breaking the cycle

I started a new piece of work and progress a couple of others. I’m conscious of the need to keep the pipeline of work full because that is the expectation at the moment, but I haven’t yet got much of an understanding of the capacity of the pipeline or how we can optimise it. I also learned a bit about how the financing works and have some ideas about how we can change it to be no longer on a feature by feature basis but fund a set run rate for development work and then optimise our pipeline to match.

Some of the feedback I’ve heard is that the right people aren’t always involved at the right stages of developing a feature. The idea of ‘starting together’ seems like a good experiment to try in to improve on this. Every time we want to do something we get all the relevant stakeholders together (either in person or virtually) and we Brain Dump (copyright Suky Semhbi) everything we can think that might affect the work we’re considering. It can become one of our Discovery phase ‘tools’. I’d hope that doing this kind of thing won’t only align the right people early on but that it will also build better relationships between the teams.

The bigger challenge I’ve picked up on this week is a chicken & egg situation of where a team can’t invest in providing data services for products without a clear justification and benefit, and the product team can’t build things that deliver value without the data services from the other team. I think the way forward is for both teams to step back, stop thinking of it on a feature level and come up with more direction for data and products together.