Weeknotes 409

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.

240529

Read about PuMP.

Keep thinking about the Drucker quote that says there are no results inside the building and what this means for OKRs when the work being done isn’t user facing work.

Thought about prioritisation, controlling work in progress, and roadmaps.

Then thought about the shuhari of roadmaps. Maybe Shu is the best practice Now, Next, Later roadmap with outcomes that no one takes any notice of. Ha breaks those rules and gives stakeholders a output-focused roadmap with dates. And Ri barely even bothers with the artefact and focuses on conversations and setting up the environment to work in a roadmap-driven way.

Did some work on our OKRs with the hope of streamlining them and aligning them with our roadmap.

Read a bit of The Flow System.

240527

Thought about writing a book about “Uncovering better ways… applying agile principles to leading, working and being in a team” or something like that. But figured I should probably finish the blog post about it first.

Worked on figuring how to explain the flow from goals & needs to work to value. Still very messy.

Hand-drawn diagram showing goals & needs flowing into work and into value.

Added some stuff to my improvement kata. It’s getting harder to know whether one problem is part of/caused by another problem, especially when they have overlapping solutions, but it’s still really useful to have somewhere to document problems and what we’re doing to solve them.

Finally got around to answering the question a colleague asked, “Which of my books would I recommend for product managers?”:

  • The practitioner’s guide, Strategize and the product book for a basic overview.
  • Empowered, Inspired and Escaping the build trap for the aspirational view of product management.
  • And most importantly, for getting better at understanding our users,  Jobs to be done, outcomes over outputs, user story mapping and what customers want.

Read Tom Dolan’s fortnote.