Weeknotes 496

I did:

Setting the pace

Someone said to me that work progresses at the pace of the slowest part of the process, which is totally theory of constraints and absolutely right. I tried not to be the slowest part of these things:

• Worked with a junior product manager who presented at an operational team meeting and got loads of really useful feedback. Validating it and acting on it is next week’s job.
• Talked through the logic of an evaluation model I’m working on.
• One of our team had cause for celebration and I’m really proud of them.
• Chatted about user research and evaluative interviewing.
• Went to a prospects marketing presentation.
• Reviewed some discovery work on product KPI’s and really keen to see what prototype dashboards come out of it.
• Took part in a research interview about scaling AI in organisations. My main take is to treat it like email but for content generation. Sure, everyone uses email but the real value is in having a team that knows how to use email to communicate with users and drive valuable action.
• Said goodbye to a couple of colleagues.

The numbers

Tasks completed: 64

Minutes spent in meetings: 1290

Real-time interaction with: 47 people 146 times.

I read:

In praise of guessing

I love this. I’ve fallen into the same trap of thinking it’s wrong to guess.

The perfect rollup

As usual, John is surfacing and verbalising the things the rest of us know but can’t quite articulate convincingly.

I thought:

Misunderstanding DABL

I think it’s easy to mistake the Discovery, Alpha, Beta, Live product development process as a ‘big upfront design and then implement’ approach. Actually, it’s more of a ‘trying things, filtering, throwing out’ approach. What sometimes happens (but shouldn’t) is that Discovery and Alpha is seen as filling up the backlog of things to be built in the future, rather than the more critical job of finding out what not to build. If Discovery finds twenty problems, Alpha should prototype five and Beta should solve one.

Mixed methods

The difference between using a plan and using a roadmap to explain and predict the future is in what you believe about the world around you. If you believe you live in a predictable world, then you use a plan. If you believe the world is uncertain and ambiguous, you should use a roadmap. Problems arise when we mix the methods without understanding the worldviews. If we call it a roadmap, have columns called ‘Now’, ‘Next’ and ‘Later’, give those columns timeframes, such as quarters, plot work to fit in a timeframe with a defined end-date, describe work as delayed if it passes that date, then we are confusing our beliefs about the nature of reality.

My position is that product work is about changing user behaviour, which makes product management ontologically relativist and epistemologically constructionist. Whereas realists believe there’s one single, stable, measurable, knowable reality, us relativist product managers believe reality is constructed within the human mind, that one true reality does not exists, and instead, reality is relative according to how individuals experience it at any given time and place. We’re interested in how individuals experience their reality, what we can do to change that experience, and how we might not if we have. We believe meaning is created for our users through their interactions with the world, and we want to understand how people make sense of things when they interact with our products.

It’s not that one position is better or more right than another, it’s perfectly possible to take realist/objectivist position on product management, but my point is that if we aren’t clear with ourselves and our stakeholders then we risk mixing positions, creating roadmaps with dates, and confusing everyone about whether we’re predicting things in a stable world or adapting to things in an uncertain one.

Why AI will change product management

I’ve been pondering the narrative that AI won’t fundamentally change what product managers do, it’ll just mean they can prototype quicker. I see how that works in the short-term but in the long-term AI will bring a massive change to product management because it will bring a massive change to management theory and practice. One way will be in how management is conducted. Knights and Willmott’s forms of control tell us that managers can use direct control, bureaucratic control, control by performance and control by culture to get people to comply and conform. AI will enable a fifth form; control by algorithm. This will change business management and so change what product managers do. It is inevitable.

• Category: Weeknotes