My three favourite phrases
1. I don’t know.
2. I’ve changed my mind.
3. I’m sorry.
1. I don’t know.
2. I’ve changed my mind.
3. I’m sorry.
Detectives find out things someone else already knows. Scientists discover things no one knows yet. Product managers are scientists.
This week I did:
If there’s a theme to these weeknotes then it’s probably something about embracing uncertainty and vagueness. Had a few chats about how we can’t wait for certainty but have to take steps into ambiguity and find our way as we go. I don’t think things will ever be as stable as they are today, so rather than making stability a prerequisite for progress
Among other things, I…
I completed 53 tasks, averaging 10.6 a day.
I had 23 hours of meetings.
I wrote 27 pages of notes.
I talked to 28 people.
Since starting tracking (three weeks ago) 38% of my tasks have been delivery related, 24% were about leading the team, and 15% were admin tasks.
I read:
Read John Cutler’s book. To continue with a theme, John says in the introduction, “Words like “problem”, “solution”, “opportunity”, “project”, “epic”, “MVP”, “MLP”, and “story” fail to capture the nuance and complexity of product work.”
This article comes from the perspective of user stories as placeholders for conversation, as a means to defer the detailed analysis of the work until right before it’s needed, which is the point in time when you know the most. So, a user story written upfront by one person and passed to another is really just requirements, however it’s formatted. The best user stories are written together and grow over time, answering questions as they come up.
Maze Design’s product research question bank.
I’ve often said that information is only useful when it becomes knowledge, that people have to internalise informational artefacts (like user journeys and roadmaps). The SECI model of knowledge dimensions is the theory that explains what I mean.
And I thought:
I’ve been questioning the use and benefits of sprints, especially if they don’t have fast feedback loops built in. For some types of work in some teams, more a focus on flow and being able to get absorbed in a particular problem seems better. Get the process out of the way of progress.
It’s tempting to try to define things in an attempt to make them simpler and clearer. Instead we should recognise the vagaries of human understanding. Maybe this temptation is a bit about our search for certainty, and we hope that definitions will give us that. I think a certain amount of vagueness is useful, it allows for different interpretations from different perspectives to all be equally right.
Wouldn’t it be great if owning a domain during a certain period of time gave you control over redirects from links created during that time. Then, even if you stopped owning the domain, you can choose to either redirect links somewhere else or hand them over to the new owner.
Came up for my first draft for a three word definition for delivery management: “Enabling team harmony”.