Category: Weeknotes

This week I did:

Obstreperous

This week has been a lesson in influencing in emergent environments. Like the butterfly flapping it’s wings and causing a hurricane, you never know what your conversations are going to lead to. Be the butterfly.

• Kicked off four new pieces of work and handed over delivery. The team made a lot of progress in a week.
• Chatted about how the way we the define product management swings between the tech delivery focused product owner idea of a product manager and the business risk focused product manager idea, which can be confusing but also useful if you know how to leverage both roles.
• Talked about team health metrics and when they are and aren’t useful. Working with some great analysts on other things has changed my thinking on what’s usefully and reliably measurable.
• Pondered how to tackle one of those messy socio-technical problems that is an unclear mix of people, process, and technology.
• Started thinking about my personal objectives. You know how I feel about personal objectives, but sometimes you just gotta do what you gotta do.
• Realised I haven’t done a very good job of explaining what I do or how I do it as a product manager. I think a few people expect me work like a scrum product owner and spend my time on the backlog of features, when actually I’m more interested in uncovering and tackling the problems that will prevent us from scaling. So, I started playing with a few diagrams to try to help me explain.

I read:

Weeknoters

Benji Stanton – kinda on the theme of why being a generalist is a good thing.

Frankie Roberto – on the product metrics and dashboard questions.

Giles Turnbull – interesting to think about the role of translation in communication.

John Fitzgerald – good to see AI is still in the digital mix for charities.

Matt Ballantine – love the point about user needs of inanimate objects.

Oliver Hannan – I remember those pressures to get work lined up for developers. Agile, right?

Owen J – makes an interesting point about how the few can be at the leading edge of new knowledge whilst the majority still have old knowledge.

I thought about:

Ontology

I was wandering through the woods thinking about ontology and epistemology, as you do, and had a couple of realisations. First, I think user research uses a constructivist ontology, so rather than trying to reveal an objective reality, it seeks to show how people create and interpret their own reality. But I’ve never heard user researchers talk about this (except this guy) or cover an ontological position in a research report. Second, product attribution models usually take a positivist ontological stance, assuming there is a single objective truth to be revealed and show how this feature lead to that increase in metrics. But, given that product work is about affecting user behaviour, and an outcome is a change in user behaviour, wouldn’t a constructivist ontology make more sense?

FUVV

The question was posed of how our day-to-day work fits into tackling the four big risks of feasibility, usability, viability and value. It’s an interesting question. How should I go about answering it? Probably need a framework or at least a rational approach, right, after all I am a product manager. I could use an inductive reasoning approach and categorise all my daily tasks by the four big risks (luckily for me I’ve tracked all my tasks since day one) and see what percentage of activities I do for each risk. Or I could apply deductive reasoning to break down the four big risks into the kinds of things that fit and then put my daily tasks into those smaller buckets. As usual, figuring out the why and the how is most interesting than actually doing the thing. Maybe that’s the product-y insight.

Quit or continue

Thought a bit about how ‘quit or continue’ thresholds might be useful for OKR’s. On their own, Key Results only tell us what’s happening, not what to do about it. If x measure is increasing from y to z, should we continue to work on that objective or is that increase enough for us to stop, or has the increase been too slow? Maybe the Key Result needs to be something like, If x measure increases from y to z in 4 weeks continue, otherwise quit.

I did:

Back in the saddle

I’very been doing some delivery work week, which has slowed the product work but that’s why we prioritise, right.

• Ran six kick-off workshops. And enjoyed them more than I thought I would. It’s been a while since I’ve done that kind of facilitation but I kept one eye on the short-term goal of starting this work together and the other on the long-term goal of demonstrating the benefits of adopting modern working practices like starting together.
• Set up a Planner board for the next seven weeks of focused work. I know it’s weird, but I really like Planner and I’m glad to be using it again.
• Wrote a one-pager for a new piece of work, partly as an exercise for myself to see if I can explain the work succinctly, but also to help with some stakeholder discussions coming up.
• Had some interesting chats about how people know what to work on, what expectations are for them and the work, and how they check they’re aligned, etc. Basically, ‘what does self-organising actually look like’ -type conversations. I definitely lean towards more trust and freedom, and supporting people to talk to each other rather than (enforced) proxy coordination via software.
• Had another interesting chat about the mindsets and assumptions people bring from one work context and apply to another (not always fully aware of how different they are). Maybe context sense is more useful than product sense.
• Chatted about the difference between being a line manager when you’re involved in the work and when you’re not. And how they require different approaches and skills. With the former, you can give more direct feedback, whereas the latter requires more of a coaching approach.
• Got told off for not including someone in an email and resisted the urge to include them in every email I ever send. I hope you’re impressed with my maturity.

I read:

Escaping the snail

Andrew Greenaway writes about the need for universities to get on with their digital transformation. I agree, the need is immediate. My hypothesis is that the mean time to transform correlates with an organisation’s natural staff turnover rate. Bringing new people in, with different skills and experience is great, but it isn’t equal in power to the drag factor of incumbent mindsets, assumptions and ways of doing things. We have to accept it. Transformation rushed is transformation failed.

Mental models

Thought provoking piece by Clare Reucroft and Nia Campbell about whether we should design something to fit someone’s mental model or design to change it. Often there are constraining reasons for why things work the way they do but that doesn’t always mean they’ve been designed to help people understand how they work. I’ve been wondering about ‘anticipation’ in user journeys, how one step sets people up for the next, how they know what to expect. And mental models are a part of the answer.

Working in the open is good for you

I’m a believer. Hidden work is risky. Working in the open is a great way to reduce risk and make things better. But… it requires an enabling environment that knows what to do with it, it needs people to understand why a team might want to be open in this way, it needs agreement about how to respond, it needs the assumption of best intentions. Working in the open without doing the hard work of making easy for those reading isn’t really any different than than broadcast comms into the wind. It’s doing not achieving. It’s output not outcome. So, working in the open… in enabling environments… is good for you.

Evolving and re-shaping delivery management at Greenwich

Really nice piece from Beth Mindham on delivery management as a solution to the coordination problem. She says, delivery management needs to move from an “emphasis on technology change and delivering products” to “large scale service transformation and organisational change with a focus on delivering ‘value’.” I agree.

And I agree about not having hard and fast boundaries between roles and responsibilities. In my experience, it creates gaps for things to fall down, so it’s better to have lots of overlap.

North Star Playbook

Quickly re-read Amplitude’s North Star Playbook just in case it comes in handy over the next few weeks.

I thought about:

Now, next, later

I know lots of product manager’s get drawn into delivering the work in the Now column on their roadmap. I get it. Responsibility, and all that (see above). But generally, I think product manager’s should be putting most of their focus into what’s in the Later section of their roadmaps (when I say roadmap, I use that term really loosely and only because I don’t think we have a tool that does what I’m suggesting). The more time a product manager spends in Now and involved in feature development, the less time they have to be thinking strategically and long-term about the business model for their product and how it drives value for users and the organisation.

Embrace the mess

Work is messy. It doesn’t fit in neat little boxes. Embrace the mess.

Insight of the week

When it comes to defining things (like what is a product or a services), who defines it matters more than the definition, because power.

This week I did:

Let down

This week’s overall feeling is of letting people down. I should have done a better job of supporting some team members. I need to really think through where I got things wrong and what I can do differently. But there were positives too:

• I’m enjoying working with another product manager on a business case. It’s great to have someone that gets what I mean when I talk about switching direction because we learned something from data analysis that we didn’t know before.
• Talked through prioritising some upcoming work with team leads and encouraged them to influence others about the priorities. I’m really keen that work gets prioritised by the team and not by me.
• Set up artefacts and routines for the new work we’re starting next week. I’m not confident about it as I haven’t had time to properly talk to people about it enough, and I think there’s a direct correlation between socialisation and adoption.
• Started outlining a training session on OKR’s. In true Jeff Gothelf fashion, I’m using delivering the training as an example of an OKR.
• Got into some IT processes, which has been fascinating. Maybe there’s some version of Conway’s Law that explains the industry around documentation within IT organisations. And at the opposite end of the spectrum, saw a nice example of a team solving an alignment problem with a checklist (which is a solution pattern that shows up in the safety literature for aeroplanes and operating rooms).

I read:

Why Cynics Are Less Likely to Succeed

One of my three word definition I think about for leadership is ‘bring the energy’. Or maybe another version of that is ‘set the vibe’. Either way, I’m trying to express how the main job of leaders is to create a sense positivity. If cynics are less likely to succeed, I wonder if the opposite is true and those that bring positivity to their work are more likely to succeed, and so become leaders.

Understanding team effectiveness

Someone (sorry I forget who) shared on LinkedIn the old Google research which found that what really matters for teams to succeed is how they work together. It says the factors that most affect a team’s success are psychological safety, dependability, structure and clarity, meaning and impact.

WTF is delivery management

Watched this video of Jonny Williams talking about delivery management.

And I thought about:

How delivery management works

Inspired by Jonny’s video above, I mapped out a presentation about delivery management, just to get the thoughts out of my head. It starts with sociotechnical theory and says that the aspect of the organisation Delivery Managers affects in ‘people’, then uses impact mapping to figure out what activities the DM does to achieve the outcomes (using Josh Seiden’s definition of outcome as a change in human behaviour that creates business results) we want. Maybe one day I’ll type it up as a blog post.

Am I doing product management?

Someone asked me this question. Guess the answer depends what you mean by product management. If you mean managing a backlog of tasks for others to do, then no I’m not, but I don’t want to be doing that kind of product management anyway. If you mean finding worthwhile problems to solve, including understanding barriers users face, helping others to do good work and grow, helping the team learn modern ways of working and experimenting with new ideas, developing approaches to stakeholder engagement and communication that will scale in near future, unpicking infrastructure constraints, etc., etc., then yes, and that’s exactly the kind of product management I want to be doing.

This week I did:

I felt like I had more thinking time this week, mostly due to quite a few of the people I work closely with being on leave. It created a natural experiment for keeping WIP levels consistent and moving bigger things on, which included:

• Reviewed some work from one of our BA’s who’s working on transforming how we create a shared understanding about new work. It’s an interesting challenge with a nice balanced metric. If we reach a shallow “understanding” too quickly, we’ll see misalignment issues later in the work. If we reach a deep enough understanding but we take too long, we’ll see work go too slowly. So the balance is in getting to a deep enough understanding quickly enough.
• Couple of conversations about levelling up, thinking more strategically, having more impact. There’s so much opportunity for our people to do bigger and better things.
• Worked with our new senior product manager to get ready for a new piece of work. And we had an interesting chat with insights and data science people on the analysis for supporting the business case.
• Started bringing together a few different threads on how our team communicates with stakeholders. I want us to be clearer about why we’re communicating and what we hope to achieve before we spend lots of time “communicating” for the sake of it.
• Cool chat about product strategy and that deckchair work doesn’t shift the needle but can provide learning for innovative, business model shifting product work (which made me think about Guy Kawasaki’s point about jumping curves).

I read:

Working with leadership teams, outside and in

Cara Bermingham’s post on leadership teams has been doing the rounds this week. What’s particularly refreshing about it is how it shows that leadership teams often aren’t teams at all and have lots of challenges in figuring out how to lead together. It’s easy for others in organisations to look at leaders and think they should have all the answers, so if things aren’t going well it must be their fault. In fact, it’s always more complicated than that, and it’s always a system problem.

Digital Playbooks

Amy Lin wrote about government digital playbooks and how they’re an underrated tool for user researchers. I like any resource that helps teams stand on the shoulders of giants, but I think where these kinds of playbooks could be even more useful is if they contained more contextual information about how they were created, where the playbook is and isn’t applicable.

Weeknoters

• Aasha Cowey
• Andy Callow
• Ann Kempster
• Coco Chan
• Frankie Roberto
• Franklin Sayre
• James Green
• John Fitzgerald
• Luis Montanha
• Martha Edwards
• Matt Ballantine
• Matt Jukes
• Olu Niyi-Awosusi
• Steve Messer

Thought about:

Meetings

There’s lots of stuff about how to make meetings more effective by always having an agenda or that most meetings are a waste of time. I have a different perspective. I think the meetings are the work. Because before you can do the work work, you need to do the work of getting to know people, creating trust, figure out how to work together. Meetings are the vehicle for doing that. So, if you’re making meetings all about the work work, treating people like robots who have to follow instructions to the letter, then I can see why your meetings aren’t very effective. Probably rethink how the true purpose of meetings is to create social space and time for people to develop a sense of belonging and go from there.

Economics of product

Been thinking a lot recently about the economics of product, stuff like how to reduce opportunity cost and ways to understand return on investment. It’s one of the few internal things about product management that I’m actually interested in (I’m always a bit meh about stuff like stakeholder management). I guess because having the numbers to back up the assumptions fits nicely with my idea that product management is about finding worthwhile problems.

Looking to the future

More and more, I think that an important part of a product manager’s job is to think about the future, well multiple possible futures really. If they are solely focused on the present, which usually means being focused on delivery, then they aren’t giving themselves the best opportunities to lead their product. More thinking about future possibilities and lot’s more talking about them to get others thinking.

Atychiphobia

How much does the fear of failure stop us from doing things, especially new and uncertain things? And do we try to cover up that fear by finding reasons not to do things?

This week I:

Ponds and pebbles

Interesting week of lots of little things having wider ripples. It’s really good to see. It’s the signals in the noise about where change is happening. Among other things, I:

• Chatted about content design, testing and user research, and realised it’s all the same work; it’s all about creating ‘enabling environments’.
• Our team leads group practiced communicating work updates.
• Presented our OKR’s for the quarter. There’s a lot more we could do with OKR’s but there’s a lot of things to get in sync before they become really useful for us.
• Started writing a stakeholder engagement and communication plan. How we make our comms effective for other’s and efficient for us is a big piece of work on my personal roadmap, and it started to look like it was taking on a random life of it’s own so I want to bring back under our control before the wrong things happen for the wrong reasons.
• Worked on the business case for a new piece of work. I still believe product management is about discovering worthwhile problems, but maybe 99% of that is convincing others it’s a worthwhile problem to solve.
• Was asked to do a talk about OKR’s to a team looking to adopt them. Wondering if I might make it a bit interactive and get people writing some objectives and key results, how purist to be, what takeaways will most help adoption, etc. Luckily, I’ve got my community of co-conspirators to help me with early feedback.

Study time

Well, not quite yet, but I applied for an MBA starting in November. I really enjoyed all the focused studying for my MSc so I’m looking forward to having something to get my mental teeth back into.

Higher education product

Had a fantastic chat with Scott Colfer about product in higher education. We talked about some of the common challenges universities face, including the tension between the academic and digital, the need for middle management/leadership, how there’s not much point having a product manager in a tech replacement project. There’s definitely lots of opportunity for product in higher education, but there is a huge drag factor too.

The first rule is…

I joined James Cattell’s blogclub (he should blog about it) and spent the time writing these weeknotes. It was nice to have the pressure of seeing how much I could write in twenty minute blocks. I had to leave for a call but I’d like to explore the idea of co-writing and working together in virtual spaces more.

I read/listened to:

Knowledge loss

Handoffs create waste in the form of knowledge loss. Working together to create a shared understanding reduces that waste, and has the added benefit of people having better relationships, is much better.

Wiring the Winning Organisation

Gene Kim describes how DevOps research shows that excellent socio-technical leadership is critical to team success and failure. He explains how technical leaders can dramatically increase team effectiveness by improving the organisational architecture and wiring to support independence of action, rapid feedback and simplification while maintaining stability and security.

And I thought about:

Figuring out the what and the how

As a team moves from an output-focused mindset to an outcomes-focused mindset, they change the way they work too. There’s a move away from how work is done, whether it uses an efficient, defined, standardised process, to what that work achieves and what it’s end-state looks like. It’s a move from a ‘predetermined defined upfront’ view of the way work is done, to an ‘emergent, find out the best way to do the work along the way’ approach. It’s a tough change for teams that have been used to a fixed working process. Not only do they have to figure out what the work is as they go, because that’s no longer defined upfront, but they also have to figure out the best way to do that work, because you can’t know any fixed process will be effective if you don’t know what the work is.

It makes me think of the statement that scrum is training wheels for agile teams. And how there’s a argument about whether training wheels or balance bikes are the best way to help a child learn to ride a bike. Really, the best way is to try something, see how it works, listen to the child, adapt with them, try something else, always with the end goal of them being able to ride a bike in mind.

Quote of the week

It isn’t the mountains ahead to climb that wear you out; it’s the pebble in your shoe.

Muhammad Ali

This week I did:

Show, don’t tell

Few things this week under the umbrella of creating change by showing the change rather than telling people to change.

• Worked on a case for investment to expand the team’s remit. If we’re successful, it’ll be a good step towards us being responsible for an entire outcome.
• Started preparing for some new work. It’s a good opportunity to work differently to how we usually work and I’m keen to make the most of it.
• Discussed a workshop for helping everyone understand what it means to be an empowered team.
• Had a good coaching conversation about setting boundaries for product work.
• Set our OKR’s for this quarter and chatted about them with the other product managers.
• Chatted about continuous discovery and whether user researchers or product managers should be responsible for it.
• Welcomed a new product manager to the team.

Read:

Economics of agile

This is an interesting article about agile, especially given the current trend of articles claiming the failure of agile. What fascinates me is that it talks about the economics of an organisation. It suggests the goal of agile is to drive down the ‘cost of change’. If an organisation can change it’s software (and other things that go with it) more cheaply than another organisation, then it has a competitive advantage. This fits Porter’s point that competitive advantage comes from lower cost or differentiation, and differentiation can’t be an advantage for software because customers don’t care how software is developed.

It makes me wonder about the organisational economics of product management. Might it be about driving down the cost of opportunity? The cheaper it is for an organisation to discover the worthwhile problems, the more competitive they can be.

Depicting The Revolutionary Changes In 21st Century Management

This article talks about how “the fastest growing firms are no longer preoccupied with inert methods and processes, hierarchical control, outputs, and profits”, instead it’s all about “dynamic mindsets that lead to value creation, empowerment, collaborative networks and process-enabled outcomes”. Every manager should read this and think deeply about it.

What the article misses is how this shift in management is also good for people, society and planet, not just for organisational success. It really is revolutionary.

I need to dig into these mindsets, goals, business models, values, and culture and add them to the timeline of modern work.

Thought about:

Enabling environments

Whatever the ‘thing’ is, the environment it exists in is even more important. When talking about measurement, for example, it’s easy to jump to metric and not consider all the stuff that needs to happen around it to make measurement successful. So, before creating the ‘thing’, come up with a plan for creating the right environment for the ‘thing’.

Explorers, villagers, and town planners

Ages ago, when I started a new role, I looked at the team as archetypal explorers, villagers, or town planners. It helped show that the majority of people were explorer types, people who want to do new things, be innovative and change things. Great when you’re building new products and services, but a risk when it comes to operational operationalising and maintaining them. I think that’s probably true of most digital/product/design types are more often explorers.

There are two ways to look at this. It creates a risk for organisations as they’ll constantly be hiring people who want to change things, and at some point they’ll need people who are happy to work with the status quo. Or, it creates an opportunities for organisations to be constantly changing and reinventing themselves. I know which one I think will be more successful.

Did:

Was off work this week so didn’t do much.

Read:

Just enough research

I’m a big believer in balance and ‘just enough/in-time’ -type thinking. Tom Kerwins’ article and diagram is really helpful for setting the context for decisions about doing research. He says, “… we accept that we can’t predict the future, but that we can make better decisions. And we learn to make better decisions by creating tighter feedback loops: hours and days, instead of weeks, months or even years.”

How to Create More Belonging for Yourself and Others

“The way we treat each other can help us feel like we belong—or not. Belonging is the sense that we’re part of a larger group that accepts and values us for who we are, to which we can contribute.” This research shows how little things make a big difference.

Humble Enquiry

I meant to buy Edgar Schein’s Humble Enquiry a while ago but I forgot. It seems like one of those books/ideas that is fundamental to a good delivery management practice (not my area but very much adjacent).

I have enough books to read at the moment, so this psychsafety article is a good introduction to Schein’s idea. “The humility Schein is advocating for isn’t a permanent change to our status or a call for greater deference in general – it’s what he calls here-and-now humility – a recognition that in that moment the person we are talking to has some knowledge, insight or understanding that we don’t. Having here-and-now humility is at the heart of genuine interest in and curiosity about the other person, and it acknowledges our dependence on them, and therefore our vulnerability. It also empowers them, to help (or hinder) us. This kind of exchange is key to building a positive relationship with them.”

Thought about:

Resistance

The obstacle is the path. Resistance to change also. Focus where the things are stickiest and slowest. Reveal the resistance, wade into it, make a path through it.

Downstream impact

Trying to find a way to understand work that you expect to enable other work. How different is it to the user-facing, value-driving work? What makes it different, and is it an imaginary difference like project/BAU? How can you compare it to more upstream work?

Community of Co-conspiritors

Community of practice, yes. Community of interest, sure. But build a community of co-conspiritors too. Bring together people who share the same vision for change and agree about how to make it happen. Stand up for each other. Swap ideas. Co-conspire.

This week I did:

Balance

Most product decisions are trade-offs, they’re about trying to get the balance right, and almost always failing. That was definitely a theme for this week. But lots of other stuff happened too:

• So many good chats about working collaboratively. Everyone wants it. No one knows what makes it so hard.
• Did some work on our objectives for the year and how our work relates to them. I think it’s finally starting to click, although still a bit too vague without a logic model and dashboard to show which metrics we’re affecting.
• Had an interesting conversation about continuous improvement and making it part of everyone’s role. It feels like a part of what it means to be an empowered team, you don’t just do the work, you make the way you do the work better.
• Added my roadmap to my dashboard so I can see how much work I have in progress and how much I’m thinking about the future. The answers are, too much and not enough.
• Started planning for a new team member joining us. It’ll be the fourth I’ve onboarded and I’m keen to do a better job than before.
• Reflected on a mistake I made a couple of months ago where I went against my better judgement and did things the way they were expected. And wondering how I fix it.
• Might set myself the goal of trying to go for a whole week without causing trouble. Nah, who am I kidding?

The numbers

Over four days I:

• Completed 33 tasks (although I’m sure I missed recording some).
• Wrote 10 pages of notes.
• Talked to 30 people 73 times.

Predictable vs. Emergent

I tried to get my thoughts in order about how modern tools and techniques just don’t work (or at least don’t work well) in organisation with a deterministic worldview. I’m not sure I’m explaining it very well, but worldviews are difficult things to grasp.

I read:

The small ‘a’

Started reading The agile manager by Rob England and Dr. Cherry Vu. Looks really good.

Cognitive Load Theory: Does it apply in software delivery?

Fantastic thoughtful post from Sorrell Harriet about cognitive load theory for software teams. She says, “the universal wisdom underlying Sweller’s CLT and Team Topologies which tells us that, to enable individuals and teams to do their best work, we must strive to remove unnecessary barriers to learning. This means giving our attention to the mechanisms by which people learn and the conditions in which they are operating.” The lesson here is, rather than arguing about whether a theory is correct or applicable, get to essence of what your were using the theory for in the first place.

Digital geography

I loved reading this. Mostly because my art is kind of about how physical and digital worlds interact, but also it reminded me of conversation I had a few years ago about abstraction and embodiment, and how we use familiar things to understand new things.

I thought about:

What it means to be a manager

There was a time when being a manager meant being a line-manager. Managing the (production) line meant telling people what to do and making sure they did it. The more people you line-managed, the more important you were. And there’s a lot of that left over, but nowadays being a manager means (or at least, I think should mean) something quite different.

It’s completely possible to be a manager without line-managing people. Managing work requires very different skills from doing work. It requires a very different mindset too, one that considers wider, deeper, longer-term impact.

So, to me, progression up the career ladder as a manager should be about increasing impact along those three dimensions.

Give blood

Booked an appointment to give blood, then had a phone call asking me to book an appointment. The app hasn’t improved since I wrote this. If I could product manage anything, it would be Give Blood.

This week I did:

We’re gonna need a bigger boat

This week was an unusual one with three days away from normal work. Still, it felt as busy as usual:

• Realised that as a team responsible for an outcome (not just for a piece of tech), we have a big dependency that is outside our control. Question is, what to do about it.
• Went to a workshop about goals, metrics and measures, which helped me understand how product metrics align to institutional metrics. We talked about the concept of a ‘hierarchy of metrics’ so I need to figure out if product metrics fit or if a network model might work better.
• Went to a brilliant collaborative session with the team starting to figure out how to tackle an interesting problem. I left buzzing. This is how to work as a team.
• Ran an async retro, analysed the results and wrote up the report. I think analyse is the most important part of retros.
• Talked about ‘the path and the plan’. To avoid jumping into work that may or may not give you the result you want, figure out the path the work is going to follow and what the plan is for staying on the path.
• Watched a ‘My first 100 days’ session one of our new directors did, which made me think about what I’d say. Maybe my message would be; we’re all in the same boat, if you someone falls overboard pull them back in, and we’re gonna need a bigger boat.
• Went to a playback session on some work we have coming up.
• Chatted about OKR’s and recognising the emergent nature of modern product development.
• Found other problems, and probably got more excited about it than I should have. I love this complex adaptive system and looking for ways to intervene in it.

UKEduCamp

Went to my first UKEduCamp. It was brilliant! I got overwhelmed and didn’t feel able to talk much but, I’m so thankful that people volunteer their time to make things like this happen. Nice stickers too.

Simple strategies

Version 0.2 of my thoughts on creating simple product strategies. Two additions; thinking about strategies rather than strategy, so lots of small strategies rather than one big one, and making the capability to deliver the strategy part of it (thanks, Ian). This is an interesting one as my usual thinking is that delivery should be separate from the strategy so you can pull different levers, ramp up and ramp down, without changing the strategy. But embedding capability in the strategy creates a feasibility test which is very helpful.

I read:

What is Chaorder?

A colleague mentioned the term, ‘chaordic’, which I think I’ve heard before but hadn’t paid much attention to. Chaorder is the delicate balance between chaos and order, which seems like a better way to think about change. Rather than thinking about whether things are changing or fixed, like lots of change methodologies do, it suggests asking whether the balance between chaos and order is just right, and responding to maintain the balance.

Explode on impact

Toby Lowe makes the case for moving from funding for “demonstrable” impact (because this — paradoxically makes real impact harder to achieve) to funding for collaborative learning and adaptation. This may or may not be a good idea, but he’s the expert, not me. What I am interested in is his points about the effectiveness of logic models. I think there’s a big difference between demonstrating impact through some kind of logic model, and making big decisions about future solely from the one perspective provided by the logic model. The problem is in how the decisions are made, not in how impact is recorded and reported. The answer then, as Toby says, is to not use impact for accountability/governance/performance management purposes. What to use then?

Plain English

Anyone who writes anything should read Iain Broome’s brilliant Plain English Club.

And I thought about:

Ways to prioritise

Thought about what a shuhari-esque practice might look like. Maybe for prioritisation it looks like this; product managers prioritise, senior product managers collaborate with the team to prioritise, lead managers coach the team to prioritise without them.

Defining products

Someone mentioned defining what a product is at UKEduCamp. My usual response is that if it was doable it would have been done by now, and that usually it’s unhelpful as the point of a definition is to stop conversation. But, if I had to, I mean really had to, define a product, I’d probably do it like this. I like the maths definition of product as ‘the result of multiplying things together’. It tells us that a product is all the things an organisation brings together, things like knowledge and expertise, processes, technology, marketing activities, etc., and packages up in a way that reaches an answer to a user’s sum. Maybe that’s stretching the maths thing a bit, but the point is that a product isn’t just a piece of tech, it’s what you get when you mix things together in a organised way.

Pyramid

For ages I’ve thought that a lot of product management thought leadership isn’t really about product at all, it’s about organisational dynamics, which I found disappointing. But I’m starting to think there’s a pyramid with user outcomes at the top, and if you want to achieve that you need the next layer down, which is great products. But to get that you need the next layer down, which is a great team. And you only get a great team if you have a great organisation. And so maybe product managers get pulled into doing organisation level work because without it they can’t do the product level work.

This week I did:

Clouds and clocks

I’ve been trying to think about my work using Popper’s clouds and clocks metaphor. It suggests all problems are clouds or clocks. A cloud is a dynamic system that can’t be taken apart, only understood in a holistic way. A clock can be taken to pieces to analyse the parts and work out how it works. My conclusion is that nothing is either/or. Everything is a cloud and a clock depending on how you choose to define the system you’re looking at. And I did a few other things too:

• Talked about ‘leaders at every level’ and how we might create the affordances that make leading the easy, default thing to do.
• Took part in a couple of journey mapping workshops.
• Interviewed a senior delivery manager. I think there should be only one question, “Who is Jonny Williams?” If they don’t know, they don’t get the job.
• Did some product strategy work to figure out the four factors that affect our success, and realised that we’re not in control of one of them.
• Lined up some future work for the team that brings together a few things we’re working on now. I like it when that happens. I think product managers should be looking to the future so it’s good to know the stuff we’re working on now it the right stuff.
• Tried to grasp how I’ve become the people person for the team. Me?!? The least people person I know.

The numbers

• Completed 39 tasks.
• Spoke to 29 people, 76 times.
• Only 18 hours of meetings this week.

Impact webinar

I took part in a webinar. It was fun. Scary but fun. I froze a bit and couldn’t keep the question in my head to form any kind of coherent response. Luckily, Nicola is brilliant and answered all the questions properly.

How product managers and service designers work together

Following a conversation with a colleague, I wrote some thoughts on how product managers and service designers work together. The TLDR is; talk to each other.

Simple product strategy

Wrote a short post about how a simple product strategy has three parts: A worthwhile problem to solve, a hypothesis about how to solve the problem, and a way to know if the problem has been solved.

I read/watched:

The what not the how of service design

Sarah Drummond wrote about commoditising service design, making it all about following the process and using the methods.

I know it’s a very product-y perspective, but when people say things like, we need a journey map or a daily stand-ups, or a process, I always ask (mostly in my head so I’m not too annoying), if a journey map is the solution, what’s the problem we’re trying to solve? If daily stand-ups are the solution, what’s the problem we’re trying to solve? If a process is the solution, what’s the problem we’re trying to solve?

When we face uncertainty we turn to tangible outputs. Maybe the answer is to practice embracing uncertainty and the discomfort that comes with it. Resist rushing towards easy answers.

What it means to be a team

Tim’s definition of a team is a “multi-person shared headspace where all the participants are actively pursuing at least one common goal they intend to achieve together as a unit.” If they never share any work items, have separate areas of responsibility, and avoid communicating with each other, they aren’t a team.

Searching through my website for something else, I found this post from almost a year ago. It’s an observation from watching a football game where the same three phases were used by a team, which made me think about Tim’s point about how important communication is for effective team work. Obviously organisations are far more complex than a football game, but team’s developing a shared language is a good thing.

The resource utilisation trap

And I thought about:

Leading indicator of culture change

I think the number of people leaders talk to is a leading indicator of culture change in an organisation. If leaders only talk to peers and direct reports, culture change will be slow. If leaders talk to lots of different people all across the organisation, culture change will be quicker.

Everyone wants to lead the transformation

Agile transformation, product-led transformation, service-led transformation, content-led transformation. Everyone wants to lead the transformation. I’ll let you into a little secret, if you’re centering power on one group and giving those that don’t ‘fit’ less power, you aren’t transforming anything, you’re reinforcing existing power structures.

Imperfections everywhere

Every problem is a combination of upstream and downstream problems.