Weeknotes 398

This week I did:

Handover

The main thing I’ve been doing this week is writing handover notes. It’s been interesting looking back all the different things I’ve worked on over the last couple of years. I have thirty-five different things so far, and more still to add. Working on so many different things is one of the things I’ve loved about working in charities. I’ve been lucky to learn so much so quickly. Of course, the downside is that not all the work gets finished. If I had time I’d plot the work from most to least impactful and reflect on what it was about work that made it effective. But I doubt I’ll have the time.

Daynotes

Tried to give my daynotes more focus but only managed one and a half days. I researched a few different templates, and will keep experimenting as I think it’s a really useful to reflect on a short time span like one day. The challenge is it not becoming just documentation of what I did but something actually useful for reflection.

Product community

One of my objectives this year is to connect with more people, so I joined the Product-led Alliance Slack group and I’ve booked a chat with someone I’ve never met before. Not quite sure what I’m trying to achieve but I’ve gotten so much from speaking to more people within the org that I want to see if it also works outside.

I watched/read:

Unphased: Reimaging Public Sector Digital Delivery

Brave presentation from Ben Whitfield-Heap. He talks about moving away from DABL phases for product development, which is obviously a good idea. But I can’t help thinking that this phased process exists to meet the needs of those outside of the project team, not the project team or the users. Been there, done that. But anyway, yeah continuous everything!

Transformed

The product thought leaders (Jason Yip, Dan Olsen, etc.) have been having their say about what Marty Cagan said on Lenny’s podcast about his new book. I’m not sure I understand why it’s gotten such a reaction given it’s a pretty well-established point-of-view. Maybe it’s just a chance to have something to say.

Value stream mapping

The value stream is the product.

And I thought about:

Project methodology argument

Saw a few different discussions going on about the differences between predictive project methodology (AKA waterfall) and an adaptive methodology (AKA agile). The funny thing about this is how the perspective is as if those are the only two options. It completely ignores all the “projects” that don’t follow any methodology. I’ve tried to think of a term to describe this and the best I’ve come up with so far is ‘constructive’, as in constructing the methodology as the project progresses or making it up as you go along. I want to try to figure out the right criteria for defining each but it’ll be a spectrum rather than a boundary.

Outcomes over outputs is unhelpful

Anything that sets up one thing in opposition to another is generally unhelpful for creating change. Outcomes over outputs is one of those things. It creates anxieties about the outputs; we still need them delivered so who is going to do that if product managers have their head in the clouds thinking about outcomes? Actually, product managers need to be concerned with impact, outcomes, outputs, activities and inputs. And they need to join them up coherently so that the inputs invested are right for achieving the impact. Might write a blog post about this one day.

Tyre fitting

I chatted to the workshop manager at a car garage about how he manages the flow of work. They fit an average of 30 tyres a day but have done as many as 50 in a day. The two biggest causes of delay are the warehouse sending the wrong items and the mechanics finding more things that need to be fixed on a car. Whatever they do to plan and predict work gets disrupted if these things happen. Then, other work scheduled gets delayed and they have to work faster to get back on schedule. Both delays are stressful for the workshop manager, but are very different to the company as the first costs them and the second makes them money.