Tag: weeknotes

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

Team stuff

Thinking about our team not as a basketball team, where everyone works together towards the same goal, but instead as a golf teams, where everyone works towards their individual goals, has definitely helped me focus my approach to managing the team. Our product management team are definitely golfers. It makes the management more complex, but I think it’s a better approach than trying to bring everyone together as I had previously thought. Also, regardless of whether the team are basketball players or golfers they are all playing the infinite game, which I think is a more fundamental context to grasp than

I’m recruiting another Product Manager to the team. I have eight interviews set up for next week and I’ve re-written the usual interview questions to be more suited to finding the kind of person we need. I think recruitment so hard to do well, and affects people’s lives so much. I wish I had more time or could approach it in a different way, but I’m pretty constrained from a number of directions. Given the big change in how we work that is coming soon, it makes recruiting the right person even more difficult as I only have the vaguest of ideas about what that person will be doing a year from now. However, I know we need to up-skill the whole team so I should look for someone who can bring in previous experience, but at the same time that person is going to be operating in a particular culture, so I’m not sure if my ‘recruit for weirdness not cultural fit’ stance might set up that person to have a harder time of it than someone who fits the status quo.

I’ve been working with the PM’s on achieving their objectives for this year, writing their career development plans, and identifying training needs. I’m going to arrange some product training for the entire team (14 of us) so that we can all start to get on the same level of understanding about how to be a product manager. The PM’s objectives are interesting. There are a few that are about increasing their influence and standing within the organisation, which I get the value of, but I’m not sure they have fully grasped how their role is going to change over the next few years and that they need to start getting themselves ready for it now. Selling a future that looks nothing like now is something I work on with them.

Data, data everywhere

I’m starting to understand the data structure behind Standards. It’s an essential part of how our current products work and what we want to build in the future. We’re pretty data heavy in how we ingest Standards data but not so much at the output end. It’s frustrating that we think of processing and providing data as a value-adding pipeline, and that is because we still think of a Standard as a commoditized object (a document), which of course makes no sense in the twenty-first century.

The other, and more immediate, issue with our data is it’s variety. I’ve previously thought that there are two options for dealing with the varieties of data quality and quantity: standardize it so that every Standard is raised to a certain level, or get good at handling the variations what data is available for a Standard. However, given our plans for the next few years, there might be a third way.

Standards have a weird supply and demand relationship that means of the hundreds of thousands of Standards that are produced only a few hundred are actually used by businesses. Given this, our approach to data could be to use what we have and focus on making it more valuable for customers. So, ignore the variety and the quality and quantity issues and set the bar low enough that we are able to provide the information our customers want in a way they want it. This turns around our focus to be more where it should be; on understanding and providing value to customers rather than starting with what we can or can’t do.

Pitching our products

I’ve been thinking about how we talk about the products we manage, what is the right way to communicate to our colleagues about them, how we would ‘sell’ them. I think it’s really important to be able to speak clearly and intelligently about why our products exist, what value they bring, and where they sit in the market.

The elevator pitch for the Shop that I first came up with was, “BSI Shop provides businesses of all sizes, all across the globe, with immediate access to the most up to date standards information for them to achieve compliance, meet regulations, and improve their business.”

It is focused on two key differentiators for the Shop, that it shows the most up to date version of the Standards at that point in time, and that it offers immediate access, no waiting to to set a subscription account, etc. But it isn’t a very inspiring statement.

So then I began thinking about how we could write elevator pitch-type statements using story arch’s like Joseph Campbell’s Hero’s journey :

• Who is the hero? How do we make the customer the hero of the journey, and how do we refer to them throughout the journey?
• What challenge do they face? What is the call to adventure that starts them on their journey?
• What triggers them to face it? What prompts them to start the journey, how do they feel about it?
• What lesson do they need to learn to overcome the challenge? What temptations and challenges might their be along the way?
• What does overcoming the challenge look like? What revelation do they need? What is success for our hero/customer?

I haven’t started writing this story for Shop yet, and this might be going a bit too far out for most of the people we’d talk to about our Products, but I think it’s an approach that could get us thinking more emotionally about our Products and focusing on what the customer gets out of using the product rather than what the product does.

Getting to that Aha moment

I’ve been doing a lot of work to bring the processes of the two teams to be more closely aligned, and getting everyone using Aha in a consistent way is a part of that. We’re almost set up and ready to present how we think we should be using it to the teams. Once we’re all agreed we’ll begin the harder task of actually getting everyone using Aha to record progress and create a shared knowledge-base about (I’d love to have the time to play with the Aha API and build a chatbot that can report on our work but I don’t think that’s likely).

A big driver for how we set up Aha is the reports we produce. Our way of reporting is a look back at the recent past. The reports are used to show progress via a notional run-rate, but really I think they are about justifying existence. They show outputs (work done) rather outcomes (customer value delivered), and I completely get why, but the reports provide questionable value themselves as I don’t think they help make decisions. I think reporting could be different. I think it could be a glimpse at the future (however uncertain) and that would be a far more useful report. If we could report on market trends, competitor and customer behaviour, and our responses, then we might be able to have better direction setting, faster course correction, and a forwards-looking mindset.

Ready player one

We’ve identified a changing need from a segment of our customers and with it an opportunity to play a larger part in an important market. There are a number of competitors, and we have a number of ways of providing an offering in the space, so our challenge is to come up with a strategy that doesn’t compete with ourselves, but can compete against more mature and more focused competitors.

This is a big deal for the product team. It’s exactly the kind of work we should be doing; identifying and responding to changing customer needs and markets, but I don’t think we’re in a strong enough position to do so effectively yet. So, we can either be bold and run the risk of a large public failure, be timid and do nothing knowing we will soon be forced out of the market, or we can be more political and use this to show what we could have done if we were properly resourced. The first step is deciding how to align internal and external strategy around this opportunity, and that is a huge challenge in itself.

All of this happened in the last half of Friday and turned a rather ordinary week into a complex bombshell that set my mind reeling and trying to figure out how to handle it.

Yes, I know I’m not funny

I thought of a joke: What do you call a colander that is good at hiding? Elu-sieve

But no one found it funny…

It’s been a another busy week of managing products, UAT testing, meeting stakeholders, coaching the team around future direction and on current OKR’s, coming up with a training package, and developing our process.

Over the few weeks I’ve been here I’ve been observing some patterns that suggested there was some uncertainty around the future of the product function and teams, and this week it was confirmed to me. I feel like this is an exciting time for the Product team. If any team should be able to embrace uncertainty, understand the problem to solve, and demonstrate the value, it should be a Product team. Whatever happens, there is no future where we’ll be working in the same way as we do now. So, I’ve been doing some coaching with the team on shifting their understanding and implementation of their role from facilitating the delivery of features on a product they are responsible for to understanding customer problems and how solving them adds value to the business.

It’s a leveling-up that they are going to resist to begin with, partly because I’m ‘the new guy coming in with all these new ideas that will never work here’, and partly because they are embedded in the current way of working. I’ve no doubt that they can change, and that they want to as they don’t enjoy the way they are currently working. They seem to feel that they is pressure on them to be busy and work the way they do but when I ask them where that pressure comes from they don’t have a coherent answer, which tells me that the pressure is implicit and can be shifted from being dragged along to leading the way.

There is no standard for Standards

I’ve had lots of chats about innovation and problems to solve across the organisation. One of the key issues around data consistency seems to be that there is no standard for Standards. Standards are written by different organisations, on different timescales, with different lifecycles, all of which makes it next to impossible to give customers a consistent experience. There are three ways we could approach dealing with this; 1) write a standard for Standards and gain consensus with all the authoring organisations, 2) get good at handling variation in data, or 3) choose to only use the Standards that meet the requirements we set.

This third approach will definitely be the simplest and quickest approach, and the one I’m going to explore first. It means understanding the data attributes that we hold for Standards, selecting those that are universally available for all the Standards and then being disciplined with ourselves that we’re only going to make available those Standards that meet those requirements. Currently we take the approach of surfacing all this complexity to our customers, complexity that they aren’t interested in. So, we need to move to delivering the value our customer want to extract from Standards rather than the Standard themselves.

How do you sell something no one wants?

We have an interesting, and uniquely not-for-profit I think, supply and demand problem. We create a vast number of Standards that no one wants to buy. It doesn’t mean there is no value in creating them, but it does mean it’s impossible to monetize the entire supply of Standards. This too takes our thinking more in the direction of delivering value to our customers rather than providing all of the Standards (or even all of the information in all of the Standards). It enables us to make better, more commercially focused, decisions about which Standards we offer to customers, and it helps us think more clearly about how to evolve towards being a platform business able to offer value at all sizes and scales rather than a pipeline business that essentially says to customers, ‘this is what we make, take it or leave it’.

Start small (businesses)

The majority of our customers are large business, those with people who’s role is specifically about ensuring they comply with Standards because of regulation and auditing. But 97% of businesses in the UK and small and micro businesses, those that could benefit from using Standards to improve how they work and utilize their use of Standards to generate more business.

This should also be a good opportunity to learn whether people pay for fragments of Standards, and interpretations of the Standards to enable us to monetize just the parts that are helpful to small businesses.

This seems like a good opportunity to work through our entire product process and see if we can identify a new market with a problem that we can fix. I’ve picked a small segment of the small and micro business market; builders, and now i need to understand if there is an appetite from them to be able to improve how they work, and demonstrate to their customers that they follow standards as a way of showing quality I their work, and so get more business.

Driving together

There seems to be some tension between product managers and project managers. Even though they work together almost every day, it seems like they don’t really understand each other, how each other works, or why they use the tools and techniques that they do. There is some work for me to do in the translation between product and project and I’ve been looking for metaphors and tools to foster some harmony between product, project, development, business analysis, testing, and infrastructure.

The metaphor I’ve been thinking about is that of driving a rally car. The car is the piece of work that we have to get from start to finish, the Product Manager is the navigator who is responsible for the direction the car goes in, the Project Manager is the driver and is responsible for the speed the work goes (and maybe the devs, testers, etc. are the mechanics but I don’t want labour the metaphor too much).

I also had a quick look at collaborative working tools like Microsoft Planner and Teams. If Planner had @ mentions so that people could be tagged in conversations that it would be the best option, but as it doesn’t I don’t think it’s going to help communicate expectations and improve visibility (from the reduced number of emails that people aren’t included on and don’t have time to read). Teams has good chat functionality, and could be organised by projects, but doesn’t have the Tasks and Dates functionality. Maybe I need to look at Trello again, or some other tools.

Modelling good behaviour

I’ve seen quite a few examples this week of negative behaviour, from snide comments to people not feeling like they could say no, to people feeling that they should work longer hours in response to some criticism. It has made me double my efforts to model good behaviour myself through being as inclusive in decision-making as I can, having a smile and being generally positive, telling jokes, and coaching people in ways to deal with the negativity of others. I’m not sure my efforts to create a nice atmosphere are going to change much but I’m certain that I don’t want to be part of the problem.