This week I did:

Contingency

If last week felt convergent, with things coming together as planned, this week has been a bit more contingent, with things going off plan. Which is fine, that’s how evolution happens. Anyway, some highlights from this week:

• Felt so impressed by the emotionally intelligent, highly-motivated people on the team. It’s times like this that truly make me believe that theory x management is so fundamentally wrong.
• Did a short showcase of what the team is working on. I wanted to use it to start making connections with other people and work across the org, and that’s what I got. I found out about three things that are relevant to our work. Hoping for more of this in the future.
• Talked about the four metrics for measuring the product development process. Which made me briefly have the stupid idea of a product playbook with things like this to be used as shortcuts, before I remembered that everything is contextual.
• Struggled to articulate how the four levers of change (people, processes, technology, product) fit together over the long-term. In my head, there is a big improvement kata (it could be a roadmap but I think it’s far too emergent to be expressed that way) but there isn’t an easy way to visualise how all the parts connect.
• Happy to be finding my rebellious streak again.

Uncovering better ways…

Those three words are, for me, the essence of agile. You’ll never convince me there is a more generalisable or first-principle-esque way to think about agile.

Impact mapping

I’m going to be on a webinar about impact mapping from CX Partners. I’ll admit I’m feeling apprehensive about it. Public speaking, even via the internet, is not a skill I have. But I’m really looking forward to doing something I’ve never done before.

The numbers

Wrote 14 pages of notes.

Had 23 hours of meetings.

I read:

From being agile to delivering value

This cool study from Prateek Singh tries to investigate the central claim of agility – that frequent delivery creates more value. He concludes, “You can pretty much ignore almost all other guidance from Agile frameworks. If you can create a stable system where WIP is controlled, Right Size your items, deliver as soon as an item is finished and learn from feedback, all other ‘framework’ structures can be removed. You do not need Sprints, PIs, estimation, prioritization etc. at least from an economic point of view.”

We killed the disco

And we did it in the name of efficiency.

Angela says, discovery is about answering ‘is there a problem to solve, can we solve it, should we solve it?’ Which sounds great. Spot on. Exactly the right questions to answer. But then she goes on to say that really, discovery is “to stop or reduce the number of large expensive projects that get spun up with a full team only to find out months or years down the line that it can’t be achieved”. Ah, not so great then. That noble idea of finding worthwhile problems to solve (hopefully on behalf of our users) starts to look more like bureaucracy. That’s how it always goes. Pure ideas always get polluted to tackle organisational problems. Doesn’t matter whether it’s discovery, OKR’s, roadmaps or whatever, they are always co-opted to reinforce existing power structures.

Maybe the disco light at the end of tunnel is the emergence of the framework-less, mixed-methods approach to work (see above from Prateek Singh). Have a discovery, which is really a feasibility study and business case analysis, if that ticks the boxes, and then go do the important work.

But anyway, thankfully disco changed the world.

Going beyond the visualisation

Most talk about roadmaps seems to go straight to format and layout, rather than the more important things like it’s underlying logic and decision-making. So it’s nice to see someone saying we should make roadmaps that do a job those reading them need them to do, which is usually deterministic plan rather than emergent experiment.

And I thought:

Us and them

Team and stakeholders, IT and business, management and workers. Maybe us and them thinking is the biggest barrier to great culture. There isn’t really an us and them, there’s only we. We’re all in it together. You know that venn diagram that shows product management at the intersection of business, technology and UX? That shows the us and them mindset of business and technology as two separate entities that rely on a single role to bring them together. That shows a belief in the old mindset. Don’t believe it, product managers. Break free!

This week I did:

Convergence

Quite a few things felt like they are starting to come together this week.

• Did quite a bit of work on socialising our new workflow process, especially talking through the problems we’re trying to tackle with it and how the different artefacts fit in. I know it’s a very product-y thing to focus on making sure we understand the problems before trying solutions, and although I sure what we’ve designed isn’t perfect, I can confidently connect each part of the process to a problem. That feels important rather than dropping in a standardised process that isn’t context aware.
• Had a few interesting discussions about user journeys, service boundaries, aligned measures of success and the analytics required to support understanding. It’s a big, joined-up piece of thinking with no easy answers.
• Started to understand some complicated supplier relationships.
• Welcomed a new team member who’ll be helping us change how we scope work to make it more collaborative.
• Thought about our long-term roadmap, how to visualise it, and what kind of thinking needs to go behind it so it doesn’t come across as a sequential timeline.
• And last minute question that came up on Friday – should we do some team sessions on agile to get everyone to the same understanding? I think team discussion is great, but when it’s about how people understand something vague like agile it can easily go nowhere. And training that tells people one person’s definition of agile doesn’t help them unlearn. Lots more thinking to be done.

The numbers

Completed 41 tasks.

Wrote 13 pages of notes.

Spoke to 33 people.

Had 16 hours of meetings.

I read:

Demanding predictable solutions for uncertain and complex problems

I nodded all the way through Audree’s post about the tension between the output-orientated worldview that tries to create predictability and the outcome-focused worldview that doesn’t accept things can be predicted.

Maybe it’s a chicken and egg problem. Those asking for outputs might not have confidence that those who are being asked are able to achieve outcomes. And those asking to be given the space to achieve outcomes have no way of demonstrating they can do it. There’s a lot of trust and understanding required, which doesn’t exist in the early stages of a new relationship, especially if those involved have mutually exclusive views. Something’s got to give.

Sociotechnical systems theory

I started learning about sociotechnical systems theory, an approach to complex organizational work design that recognizes the interaction between people and technology in workplaces. The interesting thing is that when it was introduced in the fifties, it was pioneering for its shift towards considering teams as the primary unit of analysis and not the individual. The theory says that the ability of individual team members to perform their function is not the only predictor of group effectiveness, and that team cohesion and leadership at the level of the team, referred to as “responsible autonomy” (Trist & Bamforth,1951) matters more. The idea of self-organising empowered teams has been around since 1951! Who knew?

Let it flow

I started reading John Knight’s doctoral dissertation about unifying agile and service design work. This is where the intellectual action is right now; figuring out how disciplines, principles and frameworks fit together, not in creating new frameworks.

Product management in one thread

Shreyas Doshi, well-respected thought leader, posted this definition of product management:

“Role: Define the product & coordinate actions across the org to enable its success. Success: User adoption, Business impact. Skills: Common sense, immense empathy, influential communication. Traits: Low ego, deep care, high agency. Simple, but not easy.”

I appreciate the posts I don’t agree with more than those I do because they make me think about my opinion. This definition isn’t exactly wrong, but it is completely uninspiring. I wonder if the context of this view is the backlash of Marty Cagan’s view of a product manager and trying to recognise the realities of many product roles in many companies. Anyway, I don’t believe there could be a single definition of the product management role, it’s still too new and changing with the digital times to know what it is yet.

And I thought about:

Measuring an uncertain world

I spent far too much time thinking about OKR’s and what environment they need to be effective (thanks, brain. Maybe try letting go a bit more). I realised that OKR’s can only be effective in a stochastic worldview where you are trying to achieve uncertain outcomes. If an organisation has a deterministic worldview with measurable targets to reach, OKR’s aren’t the right tool for understanding progress towards those goals. I feel some relief at resolving that particular brain itch. Might write about it one day.

Sprinting to infinity

To me, the point of sprints is to create fast feedback loops. Do a small piece of work and put it in front of a user to find out if it’s solving their problem before you invest more time in it. But increasingly I hear people talking about working in sprints as having value itself, even without the feedback loop. So, I wonder, what is that value? Is it in breaking the work down to bring it within the cognitive load of humans? Is it in appearing to be more agile? I genuinely interested in figuring out the value of practices like sprints.

This week I did:

Emerging and merging

The theme for this week has been how things affect each other and evolve together, emerge and merge. I did lots of stuff, including:

• Interviewed senior product managers.
• Joined an in-person team meeting. Still feels weird to be in an office, even if it doesn’t look like an office.
• Discussed prioritisation frameworks. Prioritisation by scoring is a rubbish idea (see below for a better way). Began setting up for a prioritisation session we’re doing soon.
• Talked about the deterministic approach to work and the move to understanding that modern knowledge work is probabilistic. This is the big, hard, deep stuff of digital transformation and the product-centric organisation. You can’t move from having an outputs focus to an outcomes focus unless you’re ready to allow outcomes to be unknown and emerge over time.
• Presented our vision to the team. I had two points to make; a vision is best used to create an identity for our product so others know what we do and why, and that it will be constantly evolving and changing (like any good identity).
• Thought a lot about the privilege people bring to shared working spaces.

The numbers

Completed 36 tasks.

Wrote 9 pages of notes.

Spoke to 36 people, 88 times.

Spent 22 hours in meetings.

I read:

Product principles

Scott has written three principles for creating a pragmatic foundation for organisations to become product-centric. I’ll be honest, when I first clicked the link I was sceptical, but it’s actually quite brilliant (and not just because Scott references the scientific method which I consider to be first principles thinking (no pun intended) for product managers).

Top 10 Ways to Foster Psychological Safety in the Workplace

Levelling power gradients is the number one thing to do to help create psychological safety within a team.

Using brain science to build better products

I bought Design for how people think. I haven’t read much yet but it seems really good and in line with my thing about product management being more about behaviour change than technology.

And I thought:

TBL prioritisation framework

One of the many problems with prioritisation is the idea that using a framework brings some kind of rationality and robustness, when often what goes into it is little more than a guess. As a product manager in a complex organisation, your role is less about making prioritisation decisions, and more about facilitating robust thinking and decision-making to help the team reach prioritisation decisions together. This is especially important when prioritising lots of different types of work that aren’t easily comparable using something like RICE.

Here’s my thoughts on prioritising in that kind of situation:

• Trust – Bring people together and trust their expertise.
• Value – Help your experts discuss the relative value of the things they want to achieve.
• Balance – Help your experts balance the type of work and try not to do too much of the same type at the same time. This is good for stakeholder management and value delivery.
• Limit your work in progress – Do fewer things, better and faster. It’s that simple. If you really want a “framework” for this, here’s one I just made up. Using the Fibonacci sequence, wherever the your team size falls, the next number down is your WIP limit. So, if you’ve 6 people on the team, that’s between 5 and 8, so you should have 3 things in progress. If your team expands to 9, your WIP limit is 5. This helps tackle the idea that team size and output scale linearly.

If you can get a bunch of people who all want different things to agree to let each other have a bit and not overwhelm your team, you’ll go far my son.

Frameworks vs. Concepts

If something is simple enough to be explained in a diagram, then it’s a framework. If it can’t be explained so easily, then it’s probably a concept. Frameworks exist to simplify complicated ideas, concepts just draw boundaries around complicated ideas.

Concepts can’t be explained in a diagram. They require deeper understanding, and no two people understand them in exactly the same way. Psychological safety is a concept, there’s no diagram to tell you how it works. Agile is a concept (I know agile gets referred to as a mindset but I disagree), scrum is a framework.

Why does it matter? Because frameworks are quick to understand and easy to implement but provide shallow, tangible value (which is to say that one framework to do something is just as good as any other). And concepts are difficult to grasp and hard to implement, but provide deep, often intangible, value. A mix of both is good.

Change

There are only four things an organisation can change: people, processes, technologies and products & services. For each of these there are different mechanisms of change, for example, in the people zone changes either who is in the org/team (hiring & firing in HR speak) or what those people know (learning & development).

A change in any zone almost always creates change in all the other zones. There are always ripples. If an org wants to create a new product it’s probably going to need some changes to it’s tech, processes and people.

But for creating certain types of change, the overlap between the zones has higher leverage. So, if you want to change culture, that’s in the overlap between people and processes. Because something like culture is intangible, it only occurs when tangible things interact.

Product thinking

If you want to improve your product thinking, learn about indeterminism.

This week I did:

Back in the swing of things

Good week, got back in the flow, feeling connected. Amongst other things, I:

• Joined a product demo for a system replacement project that should really be a user-centred project to help us tackle the real problem.
• Had a fantastic chat about impact mapping and have some homework to do on the challenges product managers face measuring impact.
• Chatted to our new tech lead. I’ve got big hopes for what we can do to improve some of the technologies we use, and even bigger hopes for knowledge-sharing and leadership.
• Had a quick chat about roadmaps, but I think my contribution was mostly unhelpful. I was trying to get us to be clear what problems we’re solving with a roadmap, who the audience is, what they need from roadmaps, and everyone else was talking about the format and look of the roadmap. Misread that and tried to challenge the wrong thing at the wrong time.
• Went to an interesting session on the ethics of how we’re using ML and AI.
• We redesigned our prioritisation, shaping and delivery process. As much as I stand by my stance that product management is about looking outwards, sometimes we have to product and delivery working together to figure out things like how work flows and what people do to make that happen, is really great.
• Started to get a more real sense of the amount of work we have to do to get the product through the introduction stage of the lifecycle and into scaling. We don’t visualise our work (yet) so it’s been a challenge to understand it all in it’s entirety.
• Was told I’m showing my age by using the word “funky”. It’s all rock n roll to me.

The numbers

• 45 tasks completed.
• 18 pages of notes written.
• 36 people spoken to.
• 23 hours in meetings.

Team objectives and fast feedback: a better way to improve individual performance

Ranted about why individual performance objectives are awful and how fast feedback within teams is better.

Improvement kata

I’ve been using an improvement kata to keep track of all the different things that I want to change. The basic logic is that for each problem I define the current state, define the perfect end state I want to get to, and then note things we do to try to improve the current state. And each month, I review those things and decide whether they are helping us towards the end state. If they are, we carry on and if not we stop. I really like improvement kata. It’s a pretty agnostic technique for improving anything.

I read:

A computational theory of the subjective experience of flow

I like getting in the flow. This research talks about the idea that flow comes from intrinsic interest, which emerges from mental associations between desired end states and means of attaining them. The more a means and end are associated the more interest the means evokes, and the easier it is to get into the flow. I think there’s something in that for my approach to task tracking which connects means and ends pretty well.

“The Business” is BS

Enough said, really.

And I thought:

The separation of concerns

The separation of concerns is a software idea of creating abstractions to help us understand things. But it doesn’t just apply to software. When we draw diagrams to simplify and explain things, we often separate the concerns (one box for this thing, another box for another thing). I wonder how useful it is for human stuff too. Thinking, talking, doing. Would we talk better if we’d already done the thinking separately, rather than trying to think and talk at the same time. Would our thinking be better if we weren’t trying to do the thing we’re thinking about at the same time. This occurs to me because I’ve been wondering about the percentage of time I spend thinking about things, talking to people, and doing stuff.

Better things to do with our time

I don’t get how Agile vs. Waterfall is still a discussion. Neither is perfect. Nobody has ever implemented either ‘properly’. We should stop wasting time even talking about it and spend our time figuring out the best way for our organisations to deliver value. (Maybe this is Ha rant)

The state of thought leadership

If you look around at all the product thought leadership you’d be forgiven for thinking that the role of the product manager is concerned with org design and internal process. Our one saving grace is Teresa Torres and helping product manager’s do better discovery, but where are the thought leaders on economics and market analysis, or psychology and behavioural science, or sociology, or all the other bodies of knowledge that product managers can use to understand the world outside their organisation? We need thought leaders showing product managers how to understand the world outside their organisation.

The imperfect analogy I’ve been thinking about is training to be a 100m sprinter (this is the product you create), but when you turn up (launch your product) to the race it’s desert ultra-marathon (the market you’re launching into). Product management is about finding where you’re going to be running.

This week I did:

Too much thinking, not enough doing

Felt like I didn’t get in the flow of things this week. Maybe due to a combination of bank holidays and days off, and definitely over-thinking a few things. But some of the stuff I did included:

• Analysed conversion rates and thought about metrics and measurement. Think I have some convincing to do so we can get some imperfect indicators that we’re progressing in the right direction sooner are better than waiting for perfectly reliable and verifiable results later.
• Started setting out what our OKRs might look like for the next quarter. One of the things I’m keen for by the time I get to six months is to be spending most of my time in the ‘Next’ space on our roadmap, but for the next few months I want to help get things in the ‘Now’ space working effectively.
• Finally installed Teams and Outlook on my phone. Not quite sure how I feel about it yet.
• Chatted about how to focus on the problem at hand and only fix the light bulb.
• Started thinking about how to review my first three months (I’ve been in my new role for two months and it’s flown by). It’ll definitely including sending a survey to the people I’ve worked with, looking at the personal strategy I set, and reviewing my productivity dashboard, but I wonder what else would be useful.
• I’m looking forward to getting feedback on all the work I’ve done on product vision and strategy, team mission, roadmap and delivery plan, and improvement kata.

unTalk

Had a nice chat with James Arthur Cattell. We talked about how product management and delivery management compliment each other, about being introverts, unconferences, social media and blog comments, and writing books.

Productivity

Completed 30 tasks, a perfect 10 a day over three days.

Wrote 19 pages of notes.

Spoke to 17 people 42 times.

I read:

Determinants of behavior and their efficacy as targets of behavioral change interventions: A meta-meta-analysis

Elina Halonen did a meta-meta-analysis of behaviour change techniques. Habits, access and social support are the most impactful levers for changing people’s behaviour. I feel like product management already knew some of that, especially about habit-forming and making access easy, but anyway, more product managers should read behaviour change literature.

21 methods of UX research: when to use which

This a pretty handy guide to UX research methods.

And I thought:

Project to product

Maybe one of the things that isn’t always clear in the move from project to product is the change in how work is “managed”. In a project there is almost always a role dedicated to managing the work, but in a product team everyone is responsible for managing their work as well as doing the work. This depends on the team being collaborative, otherwise there’s a gap. And sometimes the product manager is expected to fill the gap and act as a project manager, but this perpetuates the problem.

Why standardise

I wondered about the push to standardise things and make them consistent, and where the underlaying assumption that consistent equals good comes from. Sure, standardising bolt sizes makes sense, but what impact does standardising the ways teams work make sense? Maybe my aversion to standardisation is product teams is my longstanding belief that a big part of the point of digital is about being able to handle variability. Standardisation seems like it belongs in the old mechanical world.

No results in the building

Drucker said something along the lines of there are no results inside the building, which I take to mean we only get results from users achieving outcomes from the using the product. This has been on my mind a lot this week, especially for OKRs and about how so much of the work we’re doing isn’t of direct value to users. I haven’t done enough to bring an understanding of our users into our work yet.

This week I did:

Only three days?

I had two days off this week, and one of the days I was at work was spent at an event, so there was a lot to make progress on in a short period of time.

• Went to a Salesforce Education event. Two thoughts; lots of universities are using the same tech but each in completely unique ways, and how the big tech strategy of creating lock-in is being used in that space.
• Apologised for shutting down and talking over a colleague. I don’t know what I was thinking, but I don’t expect that kind of behaviour from anyone else so I don’t accept it from myself. I’ll do better.
• Wrote up the retro I ran last week. I like writing up retros more than I like running them. The process of synthesising the points people discussed into themes, building a mental model around using what the team is good at to overcome the challenges, and creating actions for people to own just fits how my brain works.
• Ran a session to come up with some prioritisation criteria and apply them to decide what we should work on next. Amazing what you can achieve in a 25 minute meeting when everyone is focused.
• Had a fascinating chat about measurement and reporting. It was only afterwards that I started to realise that we were coming at the conversation from different points-of-view, and it was thanks to a point Teresa Torres made on a podcast. She said something along the lines of continuous discovery and business research not needing the same degree of reliability and validity as academic research.
• Did some prep work for a service designer to join the team. I’m really looking forward to this and have high hopes for us bringing more user perspective and creating
• Pivoted my approach to creating our roadmap. I’ve given up on my analytical approach of connecting opportunities to objectives and obstacles to provide rationale and am creating a quicker version. I’ll still be able to talk through the rationale, but we need something sooner so progress is more important than perfection.

Am I an unProduct person?

Jukesie’s post about being an unProduct person got me thinking. There’s lots of interesting stuff so I wrote a post questioning whether I’m an unProduct person.

Shuhari for product managers

I wrote a few, mostly incomprehensible notes (it was late at night), on shuhari for product managers. Having thought about it a bit more, I’m wondering if shuhari complements capability frameworks. Capability frameworks are about the skills product managers need, they are defined, have clear(ish) boxes around them. Shuhari is about the practice; it’s fluid, undefined and intangible. Together, they are a bit more holistic. (And, not to get too inception-y, but weeknotes are part of a reflective practice.)

Racing

Went to Silverstone to watch a friend racing. Can’t quite figure out why people do it. When I used to run mountainboarding events, the competition was just an excuse to bring the community together. But in motorsports there doesn’t seem to be any community. People turn up, do their thing, and go home. So why turn up at all?

I read:

The flow system

I started reading The Flow System. I’m of the opinion that the next step in the knowledge base of product management isn’t more frameworks and models, it’s in ways to make the existing frameworks and models fit together. I hope this book helps with that.

How to Be Kinder Sooner

This is a nice post by Kody Fintak and Tara Scott. It doesn’t really go anywhere other than the obvious, but I’m glad to see kindness showing up in software development circles.

The Behaviour Change Technique Ontology

This is amazing work on developing a Behaviour Change Technique Ontology. Behaviour change is so overlooked in product management but it’s so important for outcome-focused work where we define an outcome as a change in user behaviour. It always baffles me that the question of whether product managers should be technical or not comes up again and again, but no one seems to ask if product managers should understand psychology.

And I thought:

Why simplify

Simple things have greater explanatory power than complicated things. So, if we want people to understand more, we have to make things simple. But that definitely doesn’t mean taking things away, hiding or ignoring complexity, or reducing things. That doesn’t make them simpler, it just makes them less.

Philosophically, a simple thing has elegance – only has the parts it needs, and parsimony – all the parts are of the same type. So, when I try to make things simple, e.g. a roadmap (head, meet wall), I have to make sure it ticks those boxes and I don’t try to add stuff that breaks the elegance and parsimony.

Make things, develop people, make things happen

Thought more about Monozukuri, Hitozukuri and Kotozukuri as part of a theme around simplicity. Along with my three-word definitions, and breaking more rules as my practice goes through shuhari, I wondered if rather than specific frameworks and thinking tools, we should start work and teams with the three simplest things of a way to make things, a way to develop people, and a way to make things happen. And do it using plain English, which is another bee I’ve got in my bonnet at the moment.

Will it make the boat go faster?

In my ongoing attempts to help our team focus on the things that matter, I’ve been trying to come up with our own, “will it make the boat go faster” question. The closest I’ve come so far is, “Will it help students succeed?”. I need to test it our with people as at the moment, I know it won’t resonate as we aren’t user focused enough yet. But we’ll change that.

Thought leaders and inaccessibility

LinkedIn’s algorithm seems to amplify posts with images. So, if you’re someone trying to build an audience around your thought-leadership, you might be tempted to create images with text to widen the reach of what you’re putting out. But this isn’t very accessible. I don’t even consider myself disabled, but I use LinkedIn on my phone and have to do a lot of pinch zooming to read the text. It must be a lot harder for others. If you’re a leader that doesn’t care about accessibility, I don’t much care about your thoughts.

This week I did:

Elucubrating

Some of the things I did at work:

• Wrote up a quick primer on simple product strategies with three elements; a worthwhile problem to solve, a hypothesis about how to solve it, and a way know if the problem has been solved. I might turn it into a blog post one day.
• Ran a team retro. I used the sailboat method to help the team clarify where they want to get to (the desert island), what’s dragging them back (the anchors) and what pushes them forward (the wind). I felt really proud of how the team owned the solutions they came up with to use what they’re good at (the wind) to overcome the things that make it hard for them (the anchors).
• Spent some time trying to figure out the optimum meeting schedule so that everyone has enough understanding of the work and enough time to do the work. The scheduling I mapped would have a person spending 40% of their time in meetings, which is probably too much, even when the meetings are the work.
• Met our marketing director and chatted about ambition and vision. I really appreciated the clarity around the team’s mission, and its scale and pace.
• Chatted about how hard it is to find a fixed point to anchor a roadmap to and give the team some certainty when so much is in flux.
• Presented our OKR’s. And got some feedback about ours being different to everyone else’s which I’m choosing to take as a positive.
• Had an interesting discussion about whether understanding the language used in agile and user-centred design is a sign of digital maturity. My opinion is that there is nothing that can’t be explained in plain English that is better explained by jargon. Jargon isn’t a signal of maturity, it’s exclusionary, and we don’t have to leave anyone behind. I might be in the minority, but Einstein agrees. He said, “If you can’t explain it simply, you don’t understand it well enough.”

I sometimes don’t quite believe I get paid to do all this cool stuff, tackle complex problems and make things better for people.

Productivity

Completed 50 tasks.

Wrote 31 pages of notes.

Spoke to 37 people 83 times.

One of my annual goals is to speak to more people, and it’s going well. More by accident than design, but I don’t mind that. Looking forward to more chats with interesting people outside of work over the next few weeks.

The timeline of digital work

I’ve been adding influential management thinkers and their books to the timeline. It’s a bit annoying that I can’t find full dates for when the books were published so I have to set the dates as 1 Jan whatever the year. Obvious I guess for this kind of thing, but the hardest part is deciding what things to add from the past couple of years as we don’t know what affect they’ll have on modern work.

I read/listened/watched

Understanding continuous discovery

I’ve been listening to a few podcasts with Teresa Torres about continuous discovery, including this one from Aug 2021. More discovery to help product managers understanding worthwhile problems and get out of the project/delivery space is definitely on my mind for stuff we need to be doing so I want to start figuring out how it might work in our context sooner rather than later.

The microfoundations of lean leadership

This beautiful paper investigates the microfoundations of lean leadership using the Japanese philosophical concepts of Monozukuri (making things), Hitozukuri (developing people), and Kotozukuri (making things happen). It provides empirical evidence that lean should be seen as a human learning system and reinforces the Toyota perspective of ‘we make people before we make cars’. More of this type of leadership please.

Plan less, more often

“Planning, i.e. determining what to do, is useful – but this should be done with a strict focus on what is the simplest, useful thing that we could do next; or, what is the absolute minimum we should do next?”

How to show the ROI of your product work

And I thought:

Impact mapping

Thought a lot about impact mapping and measuring this week. Just happened to be wandering around Watford at midnight so could let my mind wander like in the good ol’ days. My thoughts went from systems thinking, fox and rabbits, measuring impact via indirect signals (e.g., an increase in the rabbit population might show a decrease in the fox population), to littering and how Keep Britain Tidy had to affect numerous systems (legal to make it against the law to drop litter, local authorities to get litter bins installed, social pressures and public perception to make it unacceptable to drop litter, etc.), to how system-shifting product managers might show impact as a contribution to big changes in society. Maybe one day this will all make sense.

Intelligent waiting

One of the hardest management lessons I had to learn (again and again) was not jumping in to provide answers. Before acting, pause to think about what you want to achieve, how you might best achieve it, what could go wrong, what’s the bigger picture, then act, or in many cases, don’t. It gets easier (and by that I mean more comfortable) with practice and by reminding myself that I’ve only learned the lessons I’ve learned because others didn’t jump in and give me the answers.

The purist and the pragmatist

Had a few conversations this week about tools and methods (OKRs, problem/solution tree, impact mapping) that have a purist perspective about how they should best be used, and a pragmatist perspective on how well they can actually be adopted. There’s a value equation there where getting a method adopted in a pragmatic way gives enough value without too much investment, and the extra investment to get to the purist state probably isn’t worth it. Product manager-y thing to say, I know, but it’s important to stay focused on what problem the method or tool is solving for you.

Weeknotes 406

This week I did:

Connections

It felt like another high-energy week of understanding how things connect and creating new connections.

I’ve been preparing for a retro next week where I’m using the sailboat. It’s prompted me to think about my own sun, wind, rocks, anchors and the island I’m trying to get to.

Talked about:

• Architectural Decision Records and how knowing why decisions were made is as important as knowing what decision was made.
• Asynchronous working.
• How work flows from goals to roadmap to delivery plan to backlog, getting more specific with each step, and then how it flows to users.
• Finding the right cadence for feedback loops for helping people unblock their work. Shorter loops are better but it means having lots of them to deal with at the same time.
• The opportunity cost of not focusing on the most impactful work because admin and other people’s deadlines get in the way.

Productivity

Completed 46 tasks, averaging 11.5 a day (four day week).

Wrote 22 pages of notes.

Spoke to 32 people.

I read:

How to communicate the value of your work to the right people

This wonderful, thoughtful article by Nia Campbell on how communicate your work shares reflections like asking people from across your organisation, who have valuable insights about stakeholders, to suggest ways of making communications work well.

Lectures on Lean-Agile Product Management

Jez Humble’s Lectures on Lean-Agile Product Management are a great video course for product managers. And I am in no way jealous that he has a .pm domain when mine was taken off me, not in the slightest.

Courage I aspire to

Ann’s weeknotes are so open and honest, they are an inspiration.

Designing culture

The eat sleep work repeat podcast has an interesting episode on using a product design approach to design culture. I mean, it’s wrong, but it’s interesting to think about why it’s wrong. Maybe it’s about agency and choices to engage. The user of a product has no choice, they have to use the product as it was designed. A team member can choose what parts of team culture they want to engage with, and they can create their own culture, and multiple cultures can co-exist, and they affect each other, and unintentional change emerges. You can’t design culture.

The Post-Individual

I found this fascinating. I’ve thought for a long time that our concept of the individual is one of the biggest factors for explaining the state of our society. Another, even deeper one, I’ve been pondering is what affect us being the only human species. What difference would there being multiple human species have made to the development of our society? Would we have screwed up the planet if weren’t so certain of our unique superiority… or so alone…

And I thought about:

Pretty sure Maya Angelou said this

“I’ve learned that people will forget what you said in meetings, people will forget what you did in meetings, but people will never forget how you made them feel in meetings.”

What we turn to for certainty

Books, documentation, resource repositories, storing everything in one place, roadmaps, backlogs, writing weeknotes… false certainty, I tell you!

It’s a dogs life

Snuffling is good for dog’s mental health. Watch them. They get completely absorbed by what they’re doing. This is good life lesson – do more of what absorbs you.

This week I did:

Roadmappin’

I’ve been roadmappin’ (you have to say that as if you’re singing this song, it’s the law). I’m using the four O’s of objectives (what we’re trying to achieve), obstacles (the things that get in our way, from technical constraints to policy changes), opportunities (things we could do that achieve the objectives by tackling or avoiding the obstacles, and which go into delivery planning), and outcomes (where we measure changes in user behaviour to help us understand if we picked the right opportunities). Once I’ve got it set up and making sense I’ll share it with others and check the logic behind how it works before we fill it in.

Other things that happened this week:

• I learned that we have over 2 million unique user journeys.
• We did a Team Onion exercise which is going to help us clarify our mental model of who’s involved and how without having everyone listed in a RACI.
• Learned a bit about the AI work we’re doing.
• I’ve been invited to run a retro for a team. I feel quite touched that they asked me. I hope I do a good job for them.

Productivity

I completed 58 tasks, an average of 11.6 a day.

Wrote 27 pages of notes.

Spoke to 34 people.

Product leaders chat

You know that saying that if you’re the smartest in the room, you’re in the wrong room? Well, this week I found myself the least smartest, least experienced person in a room when I joined Herd’s product leaders chat. We talked about programmes and products (actually they talked, I listened). It left me with a lot of think about. What is programme thinking? How does it compare to product thinking? But mostly, why is it that so much product talk is really about organisational design and dynamics?

All my books

I’ve been meaning to catalogue all my books for a while now, but this week I finally started. I’m up to 58 so far with quite a few more to add.

I read:

Investigating the Central Claim of Agility — Does Frequent Delivery Create More Value?

This article concludes that the combination learning and working on right-sizing items is 13–14 times better at producing value than a system with Large Items.

How to Right-Size Your Stories for Better Predictability

Interesting post about predicting when work will be delivered by right-sizing the work.

Magpie metrics

The WB-40 podcast talks to Richard Clarke about the role that happiness has in high-performing teams.

I call it magpie metrics. One sorrow, two for joy. Where are you on the scale?

A leader’s job

This quote was shared with me.

A leader’s job is to manage energy… first in themselves and then in the rest of their organisation.

Professor Emeritus Jim Clawson

And I thought:

Good meetings

Most of the stuff you read about making meetings better says clear agendas are the answer. That’s not what I think. The best meetings I’ve been to have three things in common; good flow, good facilitation and good follow-up. A sense of flow helps people get absorbed in meeting. A good facilitator doesn’t stick to pre-fixed agenda, they help everyone get what they need from the meeting. And good follow-up scales the impact of the meeting by spreading knowledge and ensuring action.

S-shaped people

T-shaped people are great but really we need S-shaped people. T-shaped people have a broad range of shallow skills along with a deep specialist skill. That’s fine, but we need people who aren’t defined and constrained by their fixed skill sets. We need people who are curious, who explore new things, develop new skills. We need people who meander through knowledge, who snake their way into interesting ideas and connect them with other things.

Product managers are scientists not detectives

Someone said product managers are like detectives. They shouldn’t be. Detectives find out things someone else already knows. Scientists discover things no one knows yet. Product managers are scientists.

This week I did:

Embracing uncertainty

If there’s a theme to these weeknotes then it’s probably something about embracing uncertainty and vagueness. Had a few chats about how we can’t wait for certainty but have to take steps into ambiguity and find our way as we go. I don’t think things will ever be as stable as they are today, so rather than making stability a prerequisite for progress

Among other things, I…

• Began working on a roadmap (using my four O’s) to help us explore opportunities in different ways.
• Attended another great team retro where we used problem trees to dig into some of the things we identified in our previous retro.
• Dug into some architecture review work to try to understand how things work.
• Lots of one-to-ones to get to know more people.
• Couple of supportive leadership chats.

Productivity

I completed 53 tasks, averaging 10.6 a day.

I had 23 hours of meetings.

I wrote 27 pages of notes.

I talked to 28 people.

Since starting tracking (three weeks ago) 38% of my tasks have been delivery related, 24% were about leading the team, and 15% were admin tasks.

I read:

How to think about Bets, Success Metrics, and Roadmapping

Read John Cutler’s book. To continue with a theme, John says in the introduction, “Words like “problem”, “solution”, “opportunity”, “project”, “epic”, “MVP”, “MLP”, and “story” fail to capture the nuance and complexity of product work.”

Making User Stories Work for You

This article comes from the perspective of user stories as placeholders for conversation, as a means to defer the detailed analysis of the work until right before it’s needed, which is the point in time when you know the most. So, a user story written upfront by one person and passed to another is really just requirements, however it’s formatted. The best user stories are written together and grow over time, answering questions as they come up.

Question Bank

Maze Design’s product research question bank.

Tacit knowledge

I’ve often said that information is only useful when it becomes knowledge, that people have to internalise informational artefacts (like user journeys and roadmaps). The SECI model of knowledge dimensions is the theory that explains what I mean.

And I thought:

Timeboxing versus flow

I’ve been questioning the use and benefits of sprints, especially if they don’t have fast feedback loops built in. For some types of work in some teams, more a focus on flow and being able to get absorbed in a particular problem seems better. Get the process out of the way of progress.

Definitions

It’s tempting to try to define things in an attempt to make them simpler and clearer. Instead we should recognise the vagaries of human understanding. Maybe this temptation is a bit about our search for certainty, and we hope that definitions will give us that. I think a certain amount of vagueness is useful, it allows for different interpretations from different perspectives to all be equally right.

Managing domain redirects over time

Wouldn’t it be great if owning a domain during a certain period of time gave you control over redirects from links created during that time. Then, even if you stopped owning the domain, you can choose to either redirect links somewhere else or hand them over to the new owner.

Three word definition: delivery management

Came up for my first draft for a three word definition for delivery management: “Enabling team harmony”.