Weeknotes 403

This week I did:

Connecting things

It’s the second week in my new role and lots of things are starting to connect. This is mostly because of how generous people have been with their time and how open they’ve been, especially our team’s fantastic delivery manager. If, as I believe, a product is organisational resources packaged in a coherent and scalable way so user’s can get value from them, then a product manager’s job is to connect things in a way that creates coherence. This includes user experience, technology and data, and it includes people’s knowledge, organisational processes, etc., etc. One of the connecting things I caught myself thinking about was how the work we do on the product can provide development opportunities for people, which is probably a bit weird as I’m not their line manager. And I started developing a product strategy to help others understand how things connect.

Productivity

Completed 52 tasks.

Wrote 41 pages of notes.

Spoke to 31 people. Including 12 intro chats with people I hadn’t met yet. The highlight of which was two high energy chats with service designers. That’s the way to end a week!

I read/watched:

Team Topologies

Started reading Team Topologies. I really don’t want to get into org-design stuff but it might be useful for figuring out some team stuff over the next few weeks.

More Marty

I’m still trying to understand Marty’s position on product management and the product operating model, so I watched some videos. I think, his premise is that for a small number of a certain type of organisation, the way he talks about doing product management creates a competitive advantage by decreasing ‘time to value’, and that advantage requires the product operating model of empowered teams doing continuous discovery, etc. So, the backlash of product managers against that definition of the product operating model misses the point. Achieving competitive advantage is what is important, and if you can do it without the modern product practices, then fine, but you’re more likely to achieve it if you use them. Perhaps the reason the product management community is so focused on the practices rather than the outcome is because we’re too focused on internal process.

Innovation isn’t disruptive

Ever since reading Schumpeter and realising that his opinions on innovation ideas like first-mover advantage were mostly a result of him trying to deal with the Great Depression, I’ve been very sceptical of that whole lineage of innovation thinking. So, it’s pretty satisfying to find out that Christensen’s ideas about disruptive innovation were mostly made up and not at all scientific. Jill Lapore reads her brilliant essay about disruptive innovation from 2014 on The Last Archive podcast.

And I thought about:

Write user stories together

I’ve written before about how user stories are boundary objects, and so the best user stories create understanding across different knowledge domains. So it follows that the best way to create user stories than span different domains of knowledge is for people with different knowledge to create them together. And the best way to do that is for those people to talk and write together.

My four O’s of simple strategy

  1. Objectives – What do we want to achieve?
  2. Obstacles – What gets in the way of us achieving it?
  3. Opportunities – What could we do to remove the obstacles?
  4. Outcomes – How will we know when we’ve achieved what we want to?

The long-term side effects of AI

I often wonder what the long-term side effects of AI might be on society. It could be things like a new paradigm for the field of statistics. And maybe, if we’re lucky, organisations investing in AI will realise they need to stop treating the humans like machines and invest in them as people.