Author: Roger

This week I did:

Drawing boxes

A lot of stuff this week seemed to be about drawing mental boxes to put things in or out of. Kind of a conceptual tidy up, which among other things included…

• Wrote an audit report for how we’ve been using OKRs. That was fun.
• Our product director presented a shorter version of his talk about decision stacks. It’s an interesting concept for helping product managers frame their remit, but like so many frameworks it says nothing about the environment necessary to make it a success.
• Ran a workshop with some of the product managers to discuss what we do but shouldn’t and what we don’t do but should. My aim is that together we figure out what we’ll need to change about the environment we’re operating in and start same safe-to-fail experiments that help others understand what product managers do and why it’s important.
• Chatted about the vision for campaigns on our communications automation platform. It helped me think more deeply about that aspect of the product and how it might affect user outcomes. One of the challenges we’re trying to figure out is how users have a coherent experience of communications when every user journey is unique, and I think the vision for campaigns helps with this.
• Started conversations about how we achieve data maturity as our product scales. Without the data we can’t do anything and I’m not comfortable waiting to see what goes wrong, I’d rather we start improving things now.
• Mapped out two version of the same ‘thing’, one as a product (long-lived, cross-functional team, empowered to meet user needs and responsible for outcomes) and other as (hierarchical, functional team, centred around technology, briefed to meet stakeholder needs and responsible for outputs). It helped me think more about how to define what a product is.

North Star Workshop

I joined John Cutler’s North Star Workshop, which was full of thought-provoking advice as you’d expect. He talked about thinking of north star metrics as a constellation of connected metrics where “Great thing… is a function of… what the different teams input” and how the north star metric is a leading indicator of sustainable success (because revenue is always a lagging indicator). North star metrics very much fits the positivist ontology, which I’m still not entirely sure I agree with. I think the ‘product’ bit of ‘product metrics’ is fundamentally constructivist as it’s about user’s, their behaviour and how they construct their reality around the product. One day I hope to have the time to properly explore this.

Continuous learning

Signed up for all of Teresa Torres’ email courses. Now I just need to find time to read them and see what I might want to apply.

And I read/watched:

Beyond Team Topologies towards Continuous Stewardship

Sketches of future digital services in government

This is very cool. This is what blogging was made for. And Steve mentions our own Kate Ivey-Williams, which is nice too.

The Service Organisation

Started reading Kate Tarling’s The Service Organisation. I haven’t got very far yet but it sparked a thought about the units of analysis that are available for this kind of organisation transformation work (individuals, teams, organisations, products, services).

And I thought about:

pics or it didn’t happen

Documentation is great, but it’s only useful if people keep going back to it. And we know that most knowledge is tacit and can’t be documented explicitly anyway. Talking about the same things again and again keeps them alive.

Risk analysis

Thought about a different way to analyse risk. Rather than the traditional seriousness and likelihood, I wondered if we could use ‘time-to-fix’ as the risk measure. So, for a financial risk, how long will it take us to replace the money we spent if it turns out to be a waste? And for reputational risk, how long will it take to gain user’s trust if we get something wrong? Knowing how likely a risk is might be useful, but it doesn’t really help us decide if the risk is worth taking. Making the consequences of risks tangible might help us make better decisions about which risks we accept.

Homonyms, huh?

I remember being in a show and tell once where the question, “what is service design?” was asked. As the conversation progressed, an IT colleague said that IT had been using the concept of service for a long time. The conversation ground to a halt because it was clear that although they were using the same word, they were using very different meanings. This is the problem with words like service, product, etc.; they have multiple meanings, none of which are wrong, but which no one can agree on. That doesn’t mean we should stop discussing them, but we have to accept and make clear to everyone that to have useful conversations, we have to accept that there isn’t a single definition to be reached. And as always, we should start with understanding what we’re trying to achieve anyway. If a definition of ‘product’ is the solution, what’s the problem…?

I did:

Later

Most of my work this week has been over there in the Later space, a bit for what’s Next, and only checking in on the Now work as the team don’t need me there, which is great. Among others things, that meant I…

• Started trying to understand the Service Standard and map our work to it. Getting advice from the product leaders chat group was really helpful for thinking through how it works in practice.
• Did an ‘Intro to OKRs’ presentation for the marketing team. I really enjoyed it. Sometimes I hate presenting and sometimes I love it and get a lot of energy from it. Perhaps I need to think about what makes situations different and change the energy sucking ones.
• Had a chat about responsibility, accountability and other vague terms. My thoughts are you can’t say someone is responsible for something unless you also say, “what do we need to provide for that person to be successful in being responsible”.
• Designed a workshop for product managers to analyse their day-to-day activities and understand whether they should be doing them and whether there are things they should be doing but aren’t. I’ll be delivery it next week so we’ll see how far we get towards our goal of narrowing the gap between how things are and how the team want them to be.
• Had some thinking time on what success looks like for an organisation-wide capability product that is never finished. My first thoughts are a balancing of user outcomes & OKRs to show we’re working on the right things, delivery status to show how much is done, service standard assessment to show the quality, and financials to show ROI.
• Had one of those last-thing-on-a-Friday-afternoon meetings where lots of things click into place and become clearer. It’s going to be on my mind for a while.

User-centred prioritisation

Went to Product Leader’s discussion on prioritisation where the main theme was around helping people have good conversations because prioritisation is really just negotiation. It’s interesting how we use things like prioritisation frameworks to distance ourselves from those conversations, to make things seem objective and ‘fair’.

I read:

Scoping and Shaping For Success

John Cutler’s mini-book is a collection of thought experiments, mental models, reflection questions, and actionable activities. And it doesn’t contain the word “briefing” once.

Succeeding with OKRs

Read a bit of Allan Kelly’s, Succeeding with OKRs after I’d done my presentation to try to validate how I think OKRs might be best used.

Agile Time Machine

I love stuff like this Overview of the pivotal moments and momentous ideas worth spreading again, and a general feeling of the original essence [of agile].

Better decision making

Top insight for product managers is when Annie is talking about parenting. “Nevertheless…” is a better response than “No”.

I thought:

Some problems aren’t worth solving

In an ideal world we’d be able to make everything perfect, but over here in the real world we have to accept that is never the case. This is where, I think, we sometimes get confused when we talk about prioritisation. There’s a big difference between choosing which problems are worth solving and which order we’ll work on the solutions. If we mapped problems on an Impact/Effort grid rather than solutions, I think we’d see that lots of problems fall into the low impact/high effort (which, in my experience, no solution ever does because people are already invested in it).

Messy maps

Carrying on the theme of imperfection, I like the idea of imperfect, incomplete, messy roadmaps that are closer to the reality of our understanding, rather than the perfectly polished, everything-fits-neatly-into-quarters roadmap. Not sure anyone else would agree.

Better questions

That thing about leadership being about asking questions rather than telling people what to do was on my mind this week. But asking good questions is a real skill. Questions can do so many things; lead people to reach their own conclusions, draw out information, make sense of things. And bad questions do a lot too, they can create confusion if they are vague, out of context or badly timed. Asking better questions is number two on my list of leadership behaviours (after having more conversations with people below their pay grade).