Weeknotes 492

I did:

The Zeigarnik effect

The Zeigarnik effect is our tendency to remember unfinished or interrupted tasks better than completed ones. So, given it was a one day work week (why did no one think of this before!), I focused on new things rather than finishing things from last year. Go figure.

• Fed back on the product development section for our new delivery playbook.
• Did some research into the leaky bucket problem and a sense of belonging to help with a new product strategy. They are surprisingly connected concepts.
• Added a strategic hypothesis and future projections to a new business review dashboard.

2025 review

Wrote about things I’ve thought about and written in 2025, just like previous years.

Resource library

Started moving my product resources library to Notion. It’s not really the right tool but I use it for lots of other things so at least it’s easier for me to add new stuff to. Maybe one day I’ll actually do something with it. Maybe I’ll build a product that helps product managers learn about

I read:

Top 10 AI PM mistakes of 2025

What ~2k hours training and engaging ~1k PMs revealed about AI hype, bad product thinking, getting vibe-fired, and 2025’s biggest AIPM mistakes.

Head Up, Feet Moving. Complexity isn’t a spectator sport

Study complexity science. Learn the concepts, read the papers. But at some point, if you want to work effectively in complex systems, you have to engage with the system as it actually plays out.

Arrive. Pommel. Leave.

Really nice essay about being a specialist and focusing on your strengths. Of course, it’s not the only strategy to career progression, and you should always consider your context.

Imperfect, impermanent, and incomplete

Another nice essay from Steve Kamb, this time about, “finding beauty in the understanding that everything is imperfect, impermanent, and incomplete. To embrace Wabi Sabi requires the ability to reflect on the fact that change is the only constant, nothing lasts forever, and perfection is unattainable.”

I thought:

Reflections on line management

• It’s not like it used to be. Although we still use the term ‘line manager’, we don’t manage production lines anymore. Cross-functional teams and matrix organisational structures mean managers and managees are often not working on the same things. This means line-management can’t be directly about the work, and line-managers can’t get direct feedback about a managee’s performance. So line-management has to be approached differently.
• As a line-manager, my goal is to give the people I support the skills and experience to get a better job and leave the organisation, and create the kind of environment that makes them want to stay. That way, whatever they decide is a win for me.
• Mostly, line-management involves switching between coaching, mentoring, advising, instructing, training.
• Career development opportunities are often the hardest part of line-management because most organisations are set on having people doing their current job, not get a new job. My approach goes like this:
  • Ask the managee to find a job ad for a role they might like in five years time. This grounds the discussion in real life skills and experience and measurable distance to cover.
  • Find opp.ortunities that help the managee develop their skills and experience to, one day, match the job description.

Business objectives

Just as there are really only three user outcomes (easier, cheaper, faster), there are only five business objectives (and Dave McClure nailed them years ago):

• Attract new users (acquisition / growth)
• Get users using (activation / conversion)
• Keep users using (retention)
• Get users to pay (revenue)
• Get users to tell others (referral)

Roadmaps

One of my realisations from last year was that no single roadmap works for the entire product development process from idea to decommission. Format aside, and whether roadmaps should show dates because we all know the answer to that, the problem is there is no single unit of analysis that can represent all the different work that takes place across the product lifecycle. This is an interesting problem that must have a solution, which probably looks like a definition of how roadmaps should change across the product lifecycle.

MVP does not mean

You can’t call something an MVP just because it’s:

• Unfinished
• Untested
• Unproven
• Unsupported
• Unmeasured
• Unclear
• Unfocused
• Underwhelming

• Category: Weeknotes