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.
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.
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.
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 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.
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.
Running around, getting things done, staying on top of your to do list, too busy to stop and think about how we work not just what work we do. Sounds familiar.
Taking time to stop and think about taking a more deliberate approach to our practice of being product managers is time well spent.
Calling it a practice is important. It implies that we approach it in a considered and consistent way in an attempt to get better.
I’ve written previously about being more reflective in our practice, and I think being reflective is part of a good practice, but there is a lot more to it.
Good practices are effectiveness multipliers. They provide a frame for approaching work, start conversations, offer a fallback in times of uncertainty, and justify the professionalism of product management.
There are things to learn from other endeavors such as sports and music where practice literally means focused repetition of the things you want to improve on, and art where an artist’s practice involves them developing their own ways of working.
So what might a good product management practice look like? Given my definition of a Product Manager being a balancer of risk and opportunity, I think any definition of a practice needs to have balance in it. Rather than a hard line of ‘this but not that’ it should create space around things for individual PM’s to evolve a practice that suits them (like an artist) but it needs enough definition and clarity to enable the deliberate practice of the things that make up the practice.
It might include:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A few years ago, if an organisation wanted to present a piece of information to their customers they might go through a process something like: decide what to write, write it, publish it on their website, tell customers where to go to read it. This is a pipeline approach. The value flows from step to step in a linear fashion from the organisation through a single interface to the customer.
Nowadays, if an organisation that uses platform-thinking wants to present some information to customers, they’d take a different approach. They’d consider what words to use to make it as easy to understand as possible, what languages it could be translated into so more people can read it. They’d store the content in a system and format that enables quick and reliable access. Then the same content could be accessed via internal FAQ’s, customer service agents on the phone, automated chatbot, and the website. This platform approach multiplies the value of the content.
Pipeline-thinking comes from industrial production where an item was produced for a single use. Platform-thinking is of the internet age where data can be quickly reformatted and reused. Organisations that move their thinking from pipeline to platform can leverage their assets to maximize value. Organisations that maintain pipeline approaches won’t stand much of a chance against those that don’t.
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.
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.
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:
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.
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.
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: