Roger Swannell

Author: roger (page 1 of 145)

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.

UX in publishing meetup

The ‘UX in publishing’ meetup put on by OpenAthens, the academic single sign-on service with the goal of creating a seamless end-user journey for people accessing password protected e-resources across all platforms and publications.

We talked about:

  • RA21 – the publishing and medical industry’s initiative to improve the user experience of people accessing academic articles whilst ensuring that only those entitled to access get it. They recently published their ‘Recommended Practices for Improved Access to Institutionally-Provided Information Resources’. It’s slightly ironic that their website doesn’t have great UX, but it’s interesting that they are working to make it easier for people to get access, or that they are tightening their grip on controlling access, depending on your point of view.
  • Publishers using ‘impact factor’ as a metric for understanding how successful an article is, and how that is made up of things like how many times the article has been cited. I think the idea behind a single metric like this is to provide librarians with a guide for purchasing and customers a guide . I wondered if there was any use for a similar approach with Standards that uses socially-driven measures from other customers to help potential customers make purchasing decisions, something like ‘x number of business have used this standard’. This relates to how publishing as a concept communicates it’s value proposition when the purchaser doesn’t know if they are going to get value from what they read until they’ve read it, but they have to pay up front in order to read it. It’s a commercial model weighted in favour of the supplier and using a traditional optimised-for-production approach. I wonder what publishing (books, articles, standards, or any communication of ideas) might look like if it took a more modern optimised-for-consumption approach.
  • Chest Agreements, which are negotiated preferential licence agreements for software and online resources for the academic sector. The business model here is that universities are judged by how much money they save rather than how much they spend, and so an organisation that negotiates with the likes of Adobe to agree bulk purchase prices on behalf of academic institutions can corner that market. Then, they become the default place to go for purchasing access to software and other digital products such as books published by the American Psychological Association. They serve as an intermediary and aggregater, and are attempting the tackle the issues around access control of digital content and software products.
  • Sci-hub, the pirate website “that provides free access to millions of research papers otherwise locked behind paywalls. Widespread dissatisfaction with scholarly communications has led many to overlook or dismiss concerns over the site’s legality, praising its disruptive technology and seeing justification in the free access it affords people all over the world.

So, clearly there is a theme running through all of this that is about controlling access to content, on individual and institutional levels. There is some thinking around shifting away from the commodity approach of accessing individual articles, standards, etc., towards accessing the service that provides those things. I wonder how much research has been done on how accepting the market is of that shift (although I probably wouldn’t be able to access it even if there was research about it).

I also read Open Source Beyond The Market, DHH’s Keynote on open source software, markets, debts, purpose from RailsConf 2019. He reflects a similar line of thinking; that selling digital products is often based on the unit economics of our traditional commodity commerce where each individual thing produced had a cost, and so the selling price had to be based on that, but that with software and access to digital content, there is no unit production cost, and so the old way of thinking breakdown. As he’s talking about open source software he’s talking about allowing free access rather than developing different different pricing models, but he presents some really interesting thoughts on the context of it all.

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.

Week notes #153

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…

Week notes #152

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.

My busy calendar
My calendar for this week

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.

Week notes #151

Focus and freedom

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

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

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

Who is responsible for the solution?

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

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

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

Using the process to design the process

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

Figuring out how to match our new process to Aha

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

When do you do your homework?

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

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

Tweet of the week

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

Hustle
Olderposts

Copyright © 2019 Roger Swannell

Up ↑