Roger Swannell

Tag: weeknotes (page 1 of 13)

Week notes #163

Safe space

I had some positive and empathetic conversations with each of the PM’s about how we create a supportive team environment. We’re all aware of the difficult atmosphere that we have to work in and that there isn’t anything we can do to change it. So I think the best we can do is to do more to make sure we all know that we’re there to support each other.

My development plan

I’ve been using OKR’s for my life and career development plan this year and it’s definitely helped me focus on what I want to achieve. My three objectives this year have been around career (I got a new job), education (I started an MSc in eBusiness & Innovation), and health (I eat breakfast every day, drink less Diet Coke than I used to, and eat more fruit).

We also use OKR’s at work (although not quite as effectively yet) so one of my thoughts this week was whether I could find a way to align my two sets of OKR’s. There are a few commonalities mostly around education/learning, but perhaps the best way for me to approach it is via my development plan. One of the KR’s for my team is for everyone to have a development plan in place, and so one of the pieces of work I need to do/am working on is to create a skills inventory for Product Management so that we can all measure ourselves, pick the things we want to improve to become better T-shaped product managers. It should not only help me decide which competencies I want to improve upon but will also help to create a picture of the skills we have across the team.

Knock-on effects

We had another code release last weekend, our fifth of 2019, and there were some issues that caused lots of panic and a few hours delay. Luckily the IT team were able fix the issues and proceed with the release. S.O.P. in these kinds of situations is for everyone to criticise and blame everyone else, so to counter this I spent some time thanking those involved and trying to show them that I appreciate what they achieved in difficult circumstances.

I’ve come to realise that with increasing complexity in the products comes an increase in the likelihood that every piece of work we ship will have unforeseen consequences and causes unexpected issues. We’ll then find and fix the issues and hope that the fix doesn’t cause even more issues. It’s not a particularly good way of working but at least it’s becoming more known to me so I feel more confident in my response.

Searching for the answer

I spent an afternoon working through what we want the search functionality to achieve in our new product, how it should work and what data processes we need to drive it.

Search functionality that solves customer problems

Search is really important in our products. The vast majority of site visitors use search as the primary means of getting to the content they are looking for. We need to figure out how to connect different content types in the search results that we provide so that we are solving the customer’s problems rather than just showing links to pages that we think match their search intention. It’s going to be a complicated thing to get right but I think we’re increasing our understanding of the problem in the right direction.

The D word

Joe Freeman wrote an article on Charity Connect called ‘I’m so bored of hearing about digital‘, about charities using and stopping using the word ‘digital’ because it puts work into a box. Although I agree with many of his points, and think that things like not calling marketing ‘digital marketing’ because digital is just another channel, there is also the argument that not every charity is at the same point in the adoption life cycle of digital and that using the word ‘digital’ in a job title helps to justify the investment and differentiate the skillset. I think of the word ‘digital’ as a tool. If using that tool helps you get the job done then use it.

It also reminded me that Digital Transformation (of charity, business, society, whatever) is going to take centuries and that we’re only forty five years in. The industrial revolution lasted over a 100 years and took place in a fairly predictable world of the Enlightenment and its emphasis on the scientific method and reductionism. Compared to meta-modern thinking and the complexity and uncertainty of things like artificial intelligence and augmented human beings in a world facing unprecedented climate change, industrialisation was a crossword puzzle.

Week notes #162

Team health and renewing energy

A big focus for my thinking this week has been around team health, and how it is affected by the culture and atmosphere they work in. There isn’t much of a team, we’re individuals working on separate products, each facing our own difficulties alone. Given that there is no future for the way we work now, and that they are going to have to learn how to pull together as a cohesive team to deliver our new product, and that this will only happen if we can improve the team health, then we have a challenge ahead of us.

My hope is that us working together on our new product can be the vehicle for creating a healthier team made up of diverse individuals who appreciate each other’s differences (as a counter to the conformity pressures) and have a broad range of skills that enable them complement each other in to doing good work that focuses on delivering value for our clients and the organisation. This takes me back to my previous conception of what I need to achieve with the Product Managers, that rather than building a team that works together in the usual/cross-functional ‘product’ way, instead they are a team that takes their skills out into other departments of the organisation in a almost ‘consultative’ model. It’s about creating a space of safety and good practice that they ‘come home to’ in order to recharge before going out again to deal with challenging situations. I also think the stability of a sense of ‘team home’ will help them with leveling up the work they do on our new product as it will involve a lot of going out of their comfort zone.

From market research to machine interpretable

We reviewed the initial finding of some recently undertaken research to help us understand customer needs and whether they want us to fix them. One of the key insights was to ‘What customer do with Standards. It seems than none of the customer’s surveyed use the Standards as they are published, all go through a process of interpreting and adapting the contents of the Standard to fit their needs.

This leads to questions about whether we should be trying to understand how our customers. Some customers want to do that for themselves as they have experts that have built a career around their knowledge and ability to interpret Standards for their business. Some people at BSI believe that customer use cases for Standards are so unique and bespoke that it isn’t possible to do this

The research identified two broad use cases of interpreting and adapting for two different types of Standards. Technical standards were used to create test methods, and quality management Standards were used to create training. Both cases use the Standard as a measured threshold to answer definitively whether a test is a pass of fail or whether

So I wondered how we might go about creating a system that could interpret and adapt a Standard for a particular use case, in this example to create a training course. I picked ‘BS ISO 56002 – Innovation Management’ because its something I’m interested in. The document is written by humans to be read by humans, but I noticed was how structured it was. The document has lots of titles, short paragraphs, and lists. This structuring lends itself to a schema that can be overlaid in much the same way as machine learning can interpret voice for Alexa, Google Home, etc.

There is an avenue of thinking at BSI about this interpreting and adapting which we could call the ‘Verb approach’ where we describe each clause in terms of an action it requests of the user, e.g. monitoring, reviewing or determining. If a computer can read a sentence of text, look for those verbs, and then tag that sentence, it can begin to develop an ‘understanding’ of the intent of that sentence.

Standards intents

Intents include:

  • Amend – Make minor changes to reflect changing circumstances. (Synonyms: revise, alter, change, modify, qualify, adapt, adjust; edit, rewrite.)
  • Analyse – Perform a methodical and detailed examination. (Synonyms: examine, inspect, survey, scan, study, scrutinize, peruse; search, investigate, explore, probe, research.)
  • Determine – Cause something to occur in a particular way. (Synonyms: control, decide, regulate, direct, rule, dictate, govern, condition, form, shape.)
  • Monitor – Observe and check the progress or quality of (something) over a period of time. (Synonyms: observe, watch, check, scan, examine, study, record, note, oversee, supervise.)
  • Review – A formal assessment of something with the intention of instituting change if necessary. (Synonyms: analysis, evaluation, assessment, appraisal, examination, investigation, scrutiny, inquiry, exploration, probe, inspection, study, audit.)

In addition to “Intent”, conversational interpretation also includes the concepts of “Entities” such as organisations, partners, shareholders, “Contexts” such as leadership and responsibility, and “Events” which are triggers from outside the Standard we’re dealing with, which for us could be an update to a normatively referenced Standard.

As and when I get time I’m going to continue to explore how I could map a Standard using this conversational machine learning framework so that a Standard can be interpreted. Then the next step will be thinking about how to understand the contexts organisations want to use that interpreted Standard in so that an adapted output can be produced.

Go-to tools

I’ve been doing some work on roadmaps which has helped concrete my thinking a little about what roadmaps are for, how to structure them, how to make them useful for the team, and how to use them to communicate various things about our work.

I used to go in search of the one perfect roadmap that would mean everything to everyone. It could be used by directors to see the themes and directions, by sales to drive go-to-market strategies, and by developers to know what customer problems we’re trying to solve and so what to build next.

I realise now the idealistic naivety I had around roadmaps. They aren’t the guiding light for teams I was hoping for. They are a tool to do a job. And if you have more than one job to do it’s likely you’ll need different roadmaps (or different views of what is essentially the same roadmap) to accomplish those jobs. Roadmaps are a tool, and the tool needs to fit the job. Perfectly beautiful roadmaps that serve all needs at all levels don’t exist.

Puzzle pieces

This week the Product team spent some time together working on how each of the puzzle pieces (AKA features) that we are working on individually fit together to create a single cohesive picture.

For the new product we’re building we started with the PM’s creating a list of features as that is easily within their comfort zone, but now we’re beginning to group the features into capabilities, have each PM take ownership of some capabilities and figure out how to make all those features work together. I’ve also been working on hypothesizing our personas for this product and modelling the account subscriptions.

Building a new product in this kind of conceptual way is really interesting but we struggle with pace and focus because we’re so distracted by all the other ‘day job’ work that we have to do. I’m not sure there is anything I can do about that other than keep looking for opportunities to work on the new product.

Week notes #161

Building bridges not walls

It’s been a week of interesting conversations about some of the challenges we face as a team in our organisational culture. I feel like I’m at a point where I understand why things are the way they are and know that I can’t change or prevent the difficult situations that the Product Managers have to face in their work.

I have some thoughts about what I can do to help create a positive environment that gives the Product Managers something supportive to come back to when they have to face those difficult situations. We’ve talked about being ourselves in our role as a Product Manager and not succumbing to the pressures to be ‘a certain kind of Product Manager’, about how the behaviour we model becomes expectations for others, that team diversity is a good thing and that we should appreciate our differences.

There is a lot more I intend to do over time to improve team health as I think it’s really important for people to feel positively about their work and workplace. No one should have to dread going to work or be worried about it being a negative environment.

Measuring skills

I did some work on my ‘Skills inventory for product managers’. Essentially it’s a list of ten broad skills that PM’s need, that can be measured on a scale of 1 to 10. Normally I wouldn’t think of ‘skills’ in such a narrow way but this has a very particular aim, so it seems like the right tool for the job. I want to help them understand where they are now and where we want them to get to in order to deliver on the new value proposition that we are developing, and develop them further into strong ‘T’ shaped Product Managers that a broad spread of skills across the team.

Something else I’ve been thinking about is the ‘hard and soft skills’ dichotomy, which I don’t thinks makes much sense. Maybe it mirrors an objective vs subjective dichotomy that separates the skills and says we can define and measure the hard/objective skills but that we can’t define the soft/subjective skills because they are subjective and so open to opinion and varied interpretations. If I had to go with hard and soft, just because it’s a bit more known for people, then perhaps I’d frame it as the hard skills are ‘what’ we need to do, and the soft skills are ‘how’ we do it.

I’d prefer to think more about situational skills that demonstrate responses to obvious, complicated and complex situations. It seems much harder to understand progress and more vague to talk about, but if I can find ways to do so then I think it might be more useful.

Seeing work

We set up a wall of the office to use to show some of the things we’re working on. It seems to have had some positive feedback from the project managers and stakeholders who realise that visualising some of our work in this way is a good thing. I think it gives the higher-ups a bit of confidence that we have some control over of process for getting work from an idea to being implemented.

Discover, define, develop, deliver

The best thing about it is the discussions it drives about how we define things. One of those discussions was around whether a project should be considered done or not because the work that project was supposed to do was consumed into a different project, so the work was done but the project wasn’t. Listening to conversations like that gives me hope that people are open to questioning and improving our processes.

Team of the future

Marty Cagan (if you don’t know the name, he’s kind of a big deal in Product) posted an article calling out the difference between what he calls Feature Teams and Empowered Product Teams. It’s interesting for us as an example ‘what good looks like’ and where we want to get to in the future with us working as an empowered product team, focused on and measured by outcomes not outputs, and taking our responsibility for value and viability seriously so that we deliver the best for our customers.

Product of our future

Progress on the new product we’re working on has slowed recently, so I clarified the next few steps for the Product Managers working on it. There are various aspects of work going on at the same time, some more obvious and explicit than others. The obvious work is in defining the capabilities of the product, researching customer personas, wireframing pages, etc. The less obvious work is in changing the way we work, and more so in communicating the change.

We talked about how we shift the thinking of our stakeholders to accept our new ways of working and get away from fantasy artifacts like ‘strategies’ and ‘plans’. We need to increase working with stakeholders in positive ways because they are intelligent experienced human beings and their involvement will make the product better, and make landing it within the organisation easier.

Week note #160

One yes or one no

All it takes is one ‘no’ to stop an idea. What if all took was one ‘yes’ to start an idea?

I listened to a talk between Simon Sinek and Tony Hsieh, Zappos CEO, and one of the things they mentioned was about how permission for work happens. Where work requires permission it usually also requires consensus, which means everyone has to say ‘yes’ and one ‘no’ can stop the work. This is the risk averse approach. It’s slow and careful and shares responsibility among all the people who say yes.

Shifting to one ‘yes’ to start the work is undoubtedly faster, but it relies on lots of new and different things like decentralised leadership, and comes with an increased risk of lots more things failing, which isn’t a bad thing if the organisational culture is one that accepts that.

The reason this is interesting to me is because an organisation’s approach to decision-making is one of those overlooked underlying aspects of digital and/or agile transformation. I think the reason so much organisational change and transformation fails is because it tries to use the same old approach to things like leadership and decision-making and only change superficial things like the technology an organisation uses. As we’re going through a change of our value proposition that involves building a new product using new methods but underpinned by all the same old leadership thinking, decision-making, HR, finance, etc., I wonder what chance we have of succeeding.

Team of the future

My awareness of the culture of conformity and consensus reached a new depths as I was given direction to prioritise highly visible work over the highest value work, reporting and project management over strategic thinking, creativity and flexibility, and politiking over commercial acumen.

I’ve restarted working on my ideas about what a modern agile product “team of the future” could and should be; multi-disciplinary generalists focused on problems and taking responsibility for it’s own recruitment, finance, etc. But maybe, given the culture of actively avoiding things like team diversity, this isn’t the best place to build that team.

Hyper-specific Context Standards Ontologies

I’ve been thinking about the disconnect between supply and demand in our Standards business. Standards are written in an unbiased, context-free way, which gives them a certain amount of independence and authority, but it makes the application of what is written in the standard much harder to implement. We think this application of the info in a Standard is the biggest problem our customers face. They need to understand how to apply that info to their unique business, but we aren’t able to meet that demand because we supply fixed documents that we have no control over.

Standards Ontology

So, in attempting to solve that problem perhaps we can find another way to meet the demand. In its simplest form my idea is that the client business provides the information about their specific context which is fed into an ontology system that matches the relationship between the business’ unique context and the information in whichever standard(s) apply. Ontologies are also great for tackling the problem of interoperability between standards from different publishers, so it becomes possible to create a standard for Standards and use it to support businesses in a way that more closely matches the customer’s demand.

What is Product Ops?

There was an interesting discussion on Twitter about Product Ops. Some said there is no such thing, that it is just part of product management, whilst others associated things like handling support queries, reporting, tool admin, responding to technical incidents, etc. as Product Ops (basically, all the human interactions that keep a product going).

It makes sense to me that Product Ops is a different but connected thing to Product Management. And it raises the ownership questions. Should Product Ops be separate from Product Management, or should it be managed by a separate role, perhaps the Product Owner, or should the concept of Product Ops be owned across various teams and departments?

It seems connected to the question: What’s the difference between a Product Manager and a Product Owner? If the ‘product’ is the interface between the organisation and customer, then perhaps the two roles intersect through that interface. So, perhaps the Product Manager passes value through the interface from the customer side into the organisation and the Product Owner passes value from the organisation side to the customer. This gives them a ‘external/internal’ split, which might be useful in .

There’s lots to think about around how to structure Product teams in ways that work effectively for their particular context.

Process improvement experiments

I’m starting to raise the profile of the ‘discover, define, develop, deliver’ process to help create greater balance in our product work. We’ve used them as headings for our new not-really-kanban wall, and I’ve been adding to our playbook to help provide guidance on how to know if a piece of work has reached the definition of done for . Visualising the work in this way is a step in the right direction but we’re still a long way from using other kanban concepts like limiting work in progress and pulling the work rather than pushing it through.

This wall, along with our Planner board, are experiments in improving the ways we work. Each tool/technique used in an experiment comes with benefits and challenges, not least of which is adoption, but if both of these are about communicating that we want to experiment with ways to improve our working, then that alone is a good thing. The greatest challenge with these kinds of things is always that in order to work effectively there needs to be a mindset shift from people, not just a toolset shift. That is the difficult thing. It would be difficult anywhere, but I think it’ll definitely be difficult here.

Week notes #159

A lines in the sand

I’ve been working on three new pieces of work for the Shop product this week. They were all requested by stakeholders and the expectation based on previous experience is for the Product Manager to write up the request in a Work Request document and submit it to IT for them to undertake some investigation and come up with an estimate. This way often resulted in other parts of the organisation not being involved when they should be and work being undertaken that was of low value, so I don’t do it that way.

My way focuses on value. I use a broad framework of discovery, definition, development and delivery to guide the work. Discovery is the first step, but there isn’t an assumption that any piece of work will progress past that phase. The work has to earn it. It’s important that the success metrics for a piece of discovery work is defined at the beginning. This isn’t only to ensure that the project will have sufficient value, but to know whether we’ve reached that line in the sand before proceed to the definition stage. For example, one of the pieces of work is about a sever upgrade so the lines in the sand are about security and performance. If the discovery work doesn’t show that the upgrade will improve security and performance then there isn’t sufficient value in doing the work and my recommendation will say so.

It was interesting to explain to stakeholders the benefits of this work and show them that by clearly understanding the value up front, and setting a line in the sand that tells us whether there is value in continuing with the work, we can prioritise to achieve the most for our efforts.

Product Team Playbook

I spent some time thinking about how to help the PM’s shift away from the usual approach to work that is to ‘get on with the obvious thing in front of me’ to a more thoughtful, questioning approach that encourages the Product Managers to have more robustness in their practice that produces more reliable results. This robustness will come from adopting an open and flexible framework such as the Discover, Define, Develop, Deliver double-diamond model that I’m working on.

This model is in response to the issues I see of PM’s spending too much time working in the development and delivery space, which has greater complexity than it should because the PM’s haven’t spent enough time doing the discovery and definition work earlier. I’m aware that I need to provide more concreteness about how to do discovery work to understand the value that can be created and captured, so I decided to write a playbook. It might be that it only serves as a way for me to structure my thoughts, or it might evolve into a tool the team can use.

The purpose of all this is to help PM’s understand that their job is to convert ambiguity into certainty for the organisation, and how to do that job better. A playbook is a step along the way in them internalising that thinking so that they don’t need a playbook and are relentlessly focused on value.

Creating a picture

As we work on the new product we’re developing more and more we’re gradually creating a clearer and clearer picture of what it’ll look like and how it’ll work. We’ve been working:

  • Capabilities & Features – Capabilities are groups of features, and the features define a specific piece of functionality. Defining all the features tells us how the product will work, what data we need to provide, and what priority we need to apply when we start building.
  • User story mapping – The user story maps we’re creating describe the steps a user goes through in order to accomplish a task. We are associating the features that are required for each step to the map so that we can check that we’re building the correct functionality to enable that journey to happen.
  • Wireframes – We started with lo-fi mobile designs to spark conversations about what should and shouldn’t be on a webpage. Mobile first is important because, well, its the twenty-first century, and because it makes us be more considered and disciplined about what we put on a page and how we structure it.
  • Persona – The personas are created on axes of experience/seniority and size of organisation. This enables us to create content that meets the differing needs of a junior user at a large organisation, an expert user at a medium-sized company or the CEO of a small business. We’ll also map the content into influencer journeys so that nothing exists in isolation and every piece of content leads on to another.
Personas

Next week we’re beginning to share this work with stakeholders to get feedback and more importantly to communicate some of our thinking around the product strategy and design which is quite a departure from our current approach.

Idea of the week

I ‘presented’ (ok, I chatted about) the idea that in order to support machine interpret-able standards we need to change the way standards are written. Currently, standards are written through a long process of committees of experts producing a document, and if we wanted to make the contents of the document machine interpret-able we would need to understand the context of use and apply a taxonomy for the data, but that the problem with this is that we aren’t able to know the context or what taxonomy and data our customers might need in the future.

So, the solution to this is to create standards in a different way. Stop writing documents and start writing just the data that is machine interpret-able. We still won’t know what context and taxonomy apply but we’ll be able to iterate so quickly on create the standard that we’ll be able to start with any taxonomy, put it in front of customers and quickly develop towards the create taxonomy for any hyper-specific context.

Scared penguins

The question is, who are we in the video? It’s one of those ‘open to interpretation that reveals how you think’ questions. The usual answer seems to be that the penguins all worked together to defeat the orca, so we’re the penguins. My interpretation of the video is that the penguins aren’t working as a team, they are acting as individuals each motivated by fear. The fact that they are all driven by the same fear creates the illusion of alignment and teamwork.

Later that day, someone for HR came over to me and said in a bit of a whisper that there was something I had to do because someone had ‘escalated’ it. I took from the look on her face and the tone of her voice that I was supposed to be scared by this. I did the thing I needed to do, it wasn’t a big thing, just one of the many things I hadn’t gotten around to yet, but it left me feeling a little baffled. I’ve haven’t encountered that kind of penguin fear so blatantly before, although I’ve seen plenty of under currents.

If we’re supposed to be the penguins, it raise the question of who is the the orca? Is the orca the one who seizes the opportunity, takes control, initiates? Is the orca the senior person that was escalated to, are they the ones that represent the fear? Or is the orca anything and everything that scares us to all exhibit the same behaviour?

If you’re going to be a penguin, be one of these penguins:

Week notes #158

This week seemed like a large ramp up in the number of things I’m working on. My planner board went from 124 things to 182, approximately half again in just a week. Most of the new work is around the new product we’re working on and people stuff so it seems like the right things for me to be working on but it’s still a considerable increase.

The director of product mentioned that it seemed like I’d been at BSI for longer than I actually have because I’ve done a good job of hitting the ground running. Getting up to speed as quickly as I can has been an aim of mine but perhaps the consequence of that is that more work comes to me than I know how to handle effectively. I’ll continue to prioritise and focus as I usually do, balancing between getting stuff done in the short, setting things up for medium term, and thinking for the longer term.

Why do we have a product function?

I’m still questioning our entire existence. Why does the product function exist at any organisation, and why does BSI have a product function? These questions aren’t meant to suggest that we shouldn’t have a product function but instead to guide it’s future direction.

One conversation I had about this yielded the insight: “We dont monetise the product, we utilise the product to monetise our assests” This makes sense to me and reinforces that we are definitely not a platform business. So, perhaps the question is, “Is it necessary to be a platform business in order to have/need an effective product function?” Or to turn it around, “Is an effective product function a necessary prerequisite in order to create a platform business?”

Resilient interconnected platform

I introduced some of the project team to Microsoft Planner and explained how we are going to use it to coordinate all of the people that get involved with our project work but who don’t usually have any sight of what we’re doing. I know it’s quite a shift from the usual way, and its going to require a lot of discipline from people to keep it up to date but I think making the work visible (at least a bit) will help to encourage the right behaviour.

We’re trialling one project to start with, which is probably a safer bet, but the real value will only come when all of the projects are on there and we get a picture of who has too much to do, who isn’t meeting deadlines, how much there is to do, and how all of the work is interconnected.

I feel like I’ve spent sufficient time understanding the current processes and it’s time to make some improvements. Using a planner board is a change I’m fairly confident about yielding positive results in a short space of time and increase in value the more we use it.

This is just one small step in a theme of making the product function more resilient. The current culture/approach is for one person to be responsible for particular things and have fixed lines that prevent anyone else from taking any responsibility. It creates lots of bottlenecks and dependencies (something I hope the Planner board will help to show) because of its pipeline nature. I want us to aim for a more interconnected approach in the future that will support more of a platform operating model.

Progress measures

OKR’s continue to play on my mind but I’m beginning to develop a plan for how to shift the team’s usual way of using measures (or not) and how OKR’s can be used towards some middle ground. My hope is that we can get to the point where we are reviewing the key results monthly and either continuing with them or resetting them based on feedback loops for the next month so that they can drive the right behaviours. This feels like a truer and more effective use of key results as they become direction-setters and progress-measures.

I also need to set my objectives soon and decide on the best key results to measure my progress. Setting them in isolation is easy as I’ve always been clear about what I want to achieve, but fitting them in with the rest of the team’s is going to take a bit more thinking.

If snails did recruitment and nobody did onboarding

Recruiting a new Product Manager is taking so much longer than it should. I know that’s mostly my fault and I need to find time to progress it, but I’m also feeling uncertain about how the role will work. We’re essentially trying to recruit someone with a detail-oriented approach to focus internally on delivery for a year or so and to switch around and think strategically about the external bigger picture. Its a massive expectation to put on someone (newly recruited or not). I guess that’s the nature of drastic change.

I’ve also been reflecting on my onboarding experience from the past two months, including getting my pay wrong, not being told simple things about the building, not creating accounts in all the systems I need, and not giving me a great deal of info about anything much. I want to make our new PM’s onboarding experience better, so I’ve set up a Planner board which will help to guide them through joining and teach them a bit about how we work.

Mapping unintended consequences

I’ve been thinking about how to map the unintended consequences of a certain state. Kind of a “A” because of “B” because of “C” because of “D thing. It came from trying to understand how OKR’s, PDR’s and delivery measures fit together and I could see how the three things being so separate drove particular dysfunctional behaviour, so creating a simple this-is-caused-by-that list helped me understand why the behaviour was happening. It’s a useful tool and exercise. I’d like to do more of it before I get too settled in and lose sight of this kind of thing but I doubt I’ll have time.

Idea of the week

I submitted this week’s innovative idea. It was essentially ‘black box for small businesses’. It’s a service that helps small business owners to track that their employees are following best practices, e.g. coshh in a cleaning company, and reports to the business’s insurance company to demonstrate how safe they are in return for lower insurance premiums.

Tweet of the week

Tweet of the week goes to Bob Marshal.

Digital transformation tweet by Bob Marshall

Although it’s an obvious thing that I don’t think anyone would disagree with its interesting to think about the implications of using technology to drive changes in behaviour, culture, mindset, etc. In a way its what technology is good at; driving changes in behaviour. Its something we see all around us but it occurs in an unthought-out way. I wonder if it’s possible to drive the digital transformation of an organisation without needing to use technology as a catalyst.

Week notes #157

Why do we have a product management function?

I had intended to have a few conversations this week to understand why people in other teams think we have a product function, but I didn’t get the opportunity (for that, read I didn’t make the opportunities).

My answer is: “The role of product management is to balance risk mitigation with exploring and exploiting opportunities to create and capture value for the organisation and it’s customers.”

I think there are six interesting elements in that statement. Breaking it down a bit:

  • Risk – the biggest is building the wrong thing for the wrong market at the wrong time. Product Managers mitigate this risk through market and customer research, testing and validation, etc.
  • Opportunity – there are always other problems to solve, other markets to enter, other customer segments. Product Managers explore these looking for
  • Customer – creating value for people through solving their problems.
  • Organisation – capturing value in return for solving customer problems.
  • Balance – change is constant, so the balancing is an ongoing effort to achieve product/market fit.
  • Value – is the outcome. The sweet spot of maximum value is the optimum outcome.

I think the parts most people would struggle with are the risk and opportunity. I think they’re likely to misunderstand what risks there are to a business that a product function could have any affect on, until perhaps we say that one of the biggest risks to an organisation is not capturing value from its customers. That very quickly leads to no organisation.

Finding the right balance of mitigating risks and exploring opportunities leads to the sweet spot of maximum value creation. A PM that is too risk averse and waits for 100% certainty before making a move or doesn’t explore opportunities to move into new customer segments won’t find the sweet spot of maximum value. Similarly, a PM that is too focused on exploring new opportunities and doesn’t spend enough time on risk avoidance activities such as market research is also unlikely to achieve maximum value. The balancing of mitigating risk and exploring opportunity is at the core of what a Product Manager does, and as no other department does this, is why we need a product management function.

Measures and motivations

I spent some time with one of the Product Managers from a different team working through our understanding of why our performance measures don’t work as well as we’d like in driving the right kinds of behaviours.

We agreed that in a fast moving competitive marketplace its impossible to set meaningful goals in January and still have them be the right goals any time after that. That means, we need a performance measurement process that allows/encourages/forces regular course correction through feedback loops. An OKR-type system could do this but part of the problem is that our PDR system has fixed annually-set goals and as this is the system that drives bonuses it’ll alwats be the measures that people default to.

The only way I can see of using two systems effectively is to have them solve two separate problems. PDR’s can be a measure of personal performance over the year, and OKR’s can be used to measure and drive the products we manage. It’s twice as much work to administer (even more if we get the feedback loops and course corrections working properly) but arguably they are two jobs that need to be done.

The fire control problem

Also known as ‘How to hit a moving target’, this is about how to approach solving complex problems in dynamic situations, where the goal you want to reach keeps moving. It underpins the OKR vs. PDR thing above because we recognise that it’s impossible to set static goals far ahead of time and expect to reach them (which is the PDR approach), and so we need a different approach to actually and truly measure our progress.

This approach requires accepting that we can broadly agree what we want to achieve but that the definition of that goal will only become clearer the closer we get, that the goal is very likely to move whilst we are chasing it, and that there may never be an end point where we can say we have achieved it because it just keeps moving.

Working on this way requires a realistic assessment of the situation, and keeping that assessment up to date as the situation changes. It requires regular measurement of your progress, feedback loops, and course correcting activities to keep you pointing at the target.

The metaphor I use when talking about this is firing a missile at an aeroplane. If you fire your missile in a straight line at where the plane is now you’ll miss because it will have moved by the time to missile gets there (this is building something without paying attention to market and means you never get product / market fit because competitors got there first, for example). If you try to predict where the aeroplane will be at some point in the future you can fire your missile at that point and have a slim chance of hitting it, depending on how good you are at predicting the future (this is the big upfront planning approach, the waterfall approach that agile reacts against). If instead, you fire your missile in the general direction of the aeroplane and when it reaches a certain point you check where the aeroplane is now and change direction towards it, fly on for a bit and then do the same, and keep repeating this until you hit the plane and blow it up. I’ve been searching for a nicer metaphor but I can’t find one that fits as well.

The funniest conversation I had about this was with someone who said that the market we are in doesn’t move very fast. I asked how they were measuring change in the market and pointed out that just because you aren’t aware of it doesn’t mean it isn’t happening.

This week’s product ideas

I had two ideas for products this week:

Horizon scanner – A tool for senior managers to keep up to date with how things happening in adjacent industries might affect their industry.

Policy generator – A tool for small businesses to submit information about their organisation which is used to generate policies (health and safety, cyber security, etc.) that conform to best practice, current legislation and regulation, and of course the current standard.

I’ve set myself the challenge of coming up with and submitting to our labs team one idea a week. I’m not sure how long I’ll be able to keep it up but I’m already working on a couple of ideas around hyper-specificity and access control for next couple of weeks.

These ideas serve a few purposes; they help me to learn about how the organisation works as new ideas always challenge the status quo (part of that perimeter testing I’ve been thinking about), and they build towards my understanding of how to innovate every part of the standards development and commercialization process, which ultimately is about how to move from a pipeline business model to a platform (although it’s nothing to do with my role it’s an interesting problem to solve conceptually).

Duplication of work

The whole team is working on a new product. Some feature definition work has previously been done and recorded in one system. But we didn’t know that. So, more recently we started from scratch and began defining features in a different system. Soon we’ll have to do a copy-and-paste exercise between the two systems to get to a single source for our feature definitions. I think it might be easy to regard doing this as a waste of time, but I don’t it is. I think its an editing opportunity, a chance to check our understanding and add any knew knowledge.

In a complex product you have to keep going back over the same things from different points of view to help integrate new knowledge.

Next week I’m looking forward to…

A meeting with project managers about project managers.

I think we all recognise that managing all the projects in the way that we do isn’t working very well and that we need to try to improve it. There is a lack of visibility, which seems to be due to all communication being funneled through the project managers and them tracking project status on a spreadsheet, which results in no one really knowing what’s happening, people not being involved, and things being missed. The only communication tools we have is two status update meetings a week and occasional emails.

We put the project managers in a difficult position of being this funnel, where on one side they have people demanding answers to questions they can’t answer, and on the other side they have people providing answers they can’t communicate. We don’t give them the authority to manage budgets or the availability of the offshore development team, and yet we expect them to be able to give reliable schedules for multiple complex projects that other teams can use to plan their work. It’s like some weird sit-com about how not to manage projects in a modern world.

So I’m going to suggest that we decentralise communication to remove the pinch point of relying on the projects managers, and shift the project managers focus from being about coordinating the flow of information on each project to helping everyone see the big picture of all the projects together. We need to elevate their role, take it up a level (see above), reduce the need for administrative effort and give them greater responsibility for coordinating how the projects run. Their objective shouldn’t be the usual project manage stuff about ‘on time, on budget, in scope’ because they aren’t given control over any of those things.

Week notes #156

Testing perimeters

I’ve been thinking a lot about the idea of perimeters this week. In this context, a perimeter is the farthest allowable reach within a team, department, directorate, organisation, industry or society. It’s the limit for things like which opportunities you are able to explore. It’s what is considered acceptable, by yourself and others, given the point you are currently standing at. It’s the line you aren’t allowed to cross.

So, I’ve been asking myself, “What perimeters exist for teams and individuals? Where are the perimeters of my influence? How far out does my influence extend? What things can I affect? How can I extend my perimeters? What if I extend too far, am I likely to lose focus on the nearer things?What areas of the business can I watch but not influence?”.

And I tried a few experiments to help me test my perimeters:

  • I presented at a Labs scoring session to suggest my idea to take the BSI’s approach to developing a best practice into a consumer market. There are lots of parallel propositions and offerings around this but essentially its about providing “How to guides’ for anything where there is a clear process for how to do. Moving from being a B2B aggregator business to a B2C business that publishes it’s own intellectual property is a considerable shift outside an organisational perimeter and my professional perimeter as coming up with ideas like this is outside the perimeter of my role.
  • I went to a Release Retrospective. We all wrote postit notes to say what we thought went well, what didn’t go well, and what we could do better next time. There was some discussion, but when I asked what was going to happen to all our feedback the answer was that it will be put into a document. I asked how we were going to improve on things for next time, but it was clear that wasn’t the purpose of this retro. I decided to push out of the perimeter that says I’m not allowed to question how other teams work and suggest that for testing of the next release we could have everyone in the same room for half a day so that we could get answers to questions quickly and discuss the tests we were running. There were lots of excuses about why we couldn’t do this. Clearly I crossed the line with my radical suggestion.

Some perimeters are quite explicit whilst others are very implicit, but I think it is how we conceptualise these perimeters that creates the dreaded silos, and that organisational structure isn’t entirely to blame (or, at least, it is but only because it is a bunch of perimeters itself, it isn’t the underlying problem). It’s what we think and do that reinforces or crosses these perimeters. It’s a ‘culture eats strategy for breakfast’ thing. A strategic goal might be to work more collaboratively but the culture of perimeters wins and prevents achieving it. I wonder if there is a way to map it.

This train of thought is still full of ambiguity for me, but one thing I’m certain of is that there is risk in staying within your perimeter (risk of complacency, slow or no progress) and risk from going beyond your perimeter (not achieving your set objectives or getting fired). How do you go far enough but not too far?

Low tolerance for failure

One of the impacts of close and inflexible perimeters is that they create a low tolerance for failure. Everyone knows that repercussions await anyone who crosses the line. The retro is a good example. The meeting was held because someone was told to hold it. Tick done. I bet the retros weren’t suggested by someone on the implementation team who wanted to improve how they work. And no one takes any action to make improvements following the retro. No improvement. No growth mindset. No learning. And partly/mostly because (I think) of perimeters that don’t allow people to fail in a safe way, which means the only way to be safe is to stick to the plan, do everything by the book, don’t deviate, and then if something goes wrong it wasn’t your fault.

So, the question for me is, “How do we ensure rigor and robustness in what we do (which in a traditional command-and-control style organisation would be through strict adherence to quality-controlled process) whilst giving product managers (and everyone else) the creative space (wider perimeters) to explore and develop their practice with 21st Century thinking around distributed and decentralised leadership, embracing uncertainty and variability, and optimising-for-consumption to deliver maximum value.

OKR’s and interoperability

There are three teams within the Product department, who all work on different things in different ways. So, starting with the assumption that we want to show the rest of the organisation that a Product function has value for the organisation, that Product is a cohesive team, and that the work we do as individuals is good work, then a) all of those things need to be true, and b) there needs to be a certain amount of interoperability between the teams.

For teams to have interoperability there needs to be common understanding about what each other does, shared vocabulary so terms always mean the same thing, and shared goals that everyone contributes to achieving. For OKR’s to be the right mechanism for aligning the teams around achieving shared objectives, I think it makes a big difference how there are arranged.

Structure for Objectives and Key Results

Given the mindset of different teams, it seems easy to organise the OKR’s around asking each team to set their own Objectives and the individuals to set Key Results that are concerned with their team’s work. But this means that the first point at which there is shared commonality of what we’re trying to achieve is at the Strategic Goal level. Which means the three product teams are no more aligned than three teams for three completely different departments.

Perhaps a better way would be for there to be department level objectives that each individual, regardless of team, sets Key Results to show how they are going to contribute to the shared Objective. This aligns what the teams are trying to achieve at the earliest point of convergence. Either we achieve together or we all fail.

What measures we use, and how we measure, incentivises behaviour. At the moment there is a disconnect between the things we say we measure (using OKR’s) and the PM’s experience of being measured by other people they work with, who judge them on delivery. Delivery is important but it isn’t a fair measure for the PM’s as it is so reliant on lots of things and other people, and yet it’s the main incentiviser of behaviour. So, how do we change that? How do we make it so that PM’s have greater control, autonomy, and power over the direction their work goes?

There are so many ways round to consider the whole team measurement piece.

Connected to the OKR’s discussion, is an ongoing discussion about which tools we use to work in the open and share knowledge, and track and report on our work. The options include the usual Microsoft Planner, Aha, and Trello. One of the downsides of Trello is a lack of reporting capability so I built a quick bot that uses the Trello API to pull information from a board. I used my Life Roadmap board as a kind of proof of concept to see what kind of information I might be able get and how I might use it. ‘Roger’s Trello Reporting Bot’ just lists the names of lists and the cards on those lists, but it could be expanded to look at different boards, display the cards, count cards and labels, and report on the activity of the board. I wonder if there’s an opportunity for a product there.

Being induced

I spent a day with lots of other new starters at the Milton Keynes office for induction training.

The organisation’s strategic imperatives were described to us as a mesh with our business offerings (Knowledge Solution, Consultancy, Accreditation) on one axis and key sectors (Food, Healthcare, Aerospace) on the other axis. The value exchange occurs at the intersection of offer and sector. I get how this works for a hard-to-scale business model like consultancy where focus on being sector specialists is a big part of what sells the service into that sector, but I wonder how it works in a more scalable model such as Knowledge Solutions where aggregating information and providing it to clients requires being sector agnostic in order to get scale.

An insight I found interesting was that 85% of our clients don’t cross-purchase from us. If they bought training, they might buy more training, buy they’re unlikely to buy consultancy or use one of our products. Of course we recognise that up-selling is always easier that cross-selling, but other than that it makes complete sense to me that the majority of organisations only buy a single offering. If all of the offerings from the BSI ultimately solve the same problem (business improvement through standardisation) then why would an organisation buy two things to do the same job?

I was listening to a podcast on my way back and the phrase, “The magic of innovation happens at the intersection of different things” was used. It reminded me of how part of the genius of someone like Steve Jobs is that they are really good at synthesizing lots of other influences into a coherent and distinct new thing. They aren’t starting from scratch and creating something completely new (postmodernism pretty much destroyed that myth of the hero-artist-originator but perhaps it still exists a bit in innovation), they are finding intersection points between multiple things . It also fits what we’d been talking about earlier in the day, as to me it asks, “How can we innovate at each of those sections (and who would be allowed to do that (perimeters again))”, and “How do we innovate into sectors that aren’t a focus”.

There’s more thinking to be done about the ‘broad offer vs. specific solution’ in our product strategy.

Thought of the week

I wonder if “the culture of consensus” is an excuse for not taking responsibility and making decisions.

It came to me when someone was telling me yet again why one of the Product Managers couldn’t do something without getting permission from lots of stakeholders. I challenged them as to whether getting consensus applied at all levels including the lowest level of deciding to make a small change in their work, and whether if consensus was achieved at a higher goal level did that mean that people could then get one with doing what they need to do to achieve the goal. Of course there were no answers, as you’d expect from a culture things like that, but maybe the question is enough without an answer.

Question of the week for next week

The question I’m going to ask people next week is, “Why do we have a product function at BSI?”. I’m pretty sure people don’t do a lot of ‘challenging why’ thinking so I’m not expecting any profound or deep answers but I have my own view so if the question becomes a discussion I have my stance on why product functions exist in any organisation, so it would be good to see what others think of this.

Week notes #155

Release the hounds

Saturday was release day. That means we released the past three months of work into the live environment. The infrastructure team did most of the work, I was just there for testing. It wasn’t perfect, there were some issues, but sometimes accepting issues to not be a blocker is more important than achieving perfection, especially in all or nothing situations.

Agile humans

This tweet from Ron Jeffries about Agile being about people resonated with me.

It gave me a different perspective on the Agile values:

  • Individuals and interactions over processes and tools – As the first value this basically says, “Put people first”, and put more effort into how people work together than you do following processes and procedures.
  • Working software over comprehensive documentation – I think this value points to what intelligent creative people should be spending their time doing in order to experience autonomy, mastery and purpose. And it isn’t writing pages and pages of documentation that no one will ever read.
  • Customer collaboration over contract negotiation – Getting close to customer, seeing what problems they have and building solutions gives meaning and purpose to the work. It makes makes all that effort feel more worthwhile. Establishing relationships with people is so much more fulfilling than communication being through a proxy of a binding agreement.
  • Responding to change over following a plan – Life is a dynamic situations, things change, get used to it. Forcing people into situations where they have to stick to a plan causes frustration, demotivation, and stress to get the plan as close to right in the first place.

Access control

I went to a ‘UX in Publishing’ meetup, and chatted about market trends in the publishing industry. The main trend we discussed was how publishing organisations are controlling access to documents. It’s interesting to know a bit about what’s going on in the wider publishing market as we’re moving in a similar direction, away from purchasing documents and towards accessing a service. I wrote more about it.

Ill Communication

In one day I received just seven emails. Some people might consider that a good thing. I think it’s indicative of the lack of communication. It isn’t that we are communicating using other channels, we just aren’t communicating.

And when we do communicate, we don’t communicate well. Emails are typically sent to offer some awareness, perhaps of an issue and usually only go as far as saying, ‘we found this issue, we’ll deal with it tomorrow’, or to request so information or action, in which case they never offer any background or context. I’m guilty of this, telling myself that they don’t need to know the context because I only need an answer to my question and then I’ll figure out where it fits in the wider context. But of course, they have a wider context that I’m not aware of.

There are some parts of our Golf Team culture that I don’t think we can change but it seems to me that challenging the culture of not openly communicating, sharing things or contributing to shared learning is worth trying.Change happens at different levels, from processes to philosophy, and each is more profound and meaningful than the layer above, so:

Practices > Processes

Principles > Practices

Philosopy > Principles

So, we could try to fix the communication problems at the ‘processes’ level by introducing another process, but it’s much harder to make that stick unless the underpinning Practices, Principles and Philosophies are also changed. And of course, the deeper you go the harder is it to change something. Implicitly accepting a philosophical standpoint that humans are social creatures and so have an innate need to communicate creates the right kind of thinking to be more explicit about the principles of good communication and then the practices of how to communicate well. I don’t really know where I’m going with this, other than taking small steps, trying stuff, and communicating more thoughtfully.

Whether or not I can do anything about our communication problems, I feel satisfied that I finally got a Beastie Boys reference into my week notes.

Roadmappin’ across the universe

I’ve been trying to create a roadmap for our product suite. It needs to distil our strategy for each product onto a single document that shows our intentions for the things we want to achieve and allows other teams to align with us without it becoming a commitment or a timeline.

That is difficult because some of the other teams expect us to be able to tell them when we’ll be doing some piece of work. I think that what they would really like is a project plan rather than a roadmap. That’s a different thing and something else we’re not great at doing.

How do we represent the lifecycle of a product, show when we’re expecting to retire a product, how that affects our investment decisions? How can we show a shift in focus towards building new products? Over what time period? Should it show from now, or show history, even back to the launch? Should it even have time as a element?

I think effective roadmapping is possible the hardest part of Product Management. Everyone means something different, no one agrees on its purpose, and no one uses it after that one meeting to discuss it. Maybe the answer is no more roadmaps.

Feature definition workshop

We had our first Feature Definition Workshop for a new product we’re going to develop. It went really well. We had some really good discussions about product strategy and agreed the core set of capabilities that we need to work on.

The really good thing about the workshop was getting the team in the same place at the same time and working together on the same thing. It’s the first time its happened since I’ve been there.

Aside from that I’ve been thinking a lot about the team and how they work. I’m pretty clear that trying to make them into a team isn’t going to work, so I need to help them develop a really strong product practice to take out into the business.

Other random stuff

I interviewed again for our Product Manager vacancy and have another interview next week. I still feel unsure about what I need to achieve (other than the obvious of filling the position), but I think its one of those things that will just happen even if I’m not entirely leading it in the way I’d like.

I had a funny meeting with a team who produce approximately one CD-ROM a year and felt that we should build an automated service to zip files to replace their manual process. A few questions to help identify the cost/benefit difference and they’ve decided to find an alternative solution.

I learned a bit more about how our data publishing systems work and where the team that manage all that are aiming to get it to. I think they are struggling to get investment to take it to the next level and so need closer alignment with the Product teams to demonstrate the commercial benefits of their work.

Week notes #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.

Olderposts

Copyright © 2019 Roger Swannell

Up ↑