Weeknotes 448
I did:
Thinking about things
A lot of my job is thinking about things. Even though I track all my tasks and meetings and can report on which of my objectives they contribute to, these outputs don’t really show where my time and energy goes or what it achieves. I might be fooling myself, but I like to think of my work as dialectical, moving ideas forward to reach a logical conclusion. This week, that included:
- Presented to a few senior leaders about delivery management.
- Delivered a workshop to design monitoring solutions across our tech stack.
- Planned a workshop to figure out team responsibilities and structures. Thinking about the end-state, how we get there, how it matches up with the roadmap, etc.
- Chatted about strategy choices using Martin’s ‘where to play and how win’ and Porter’s generic strategy model. Martin seems to fit better for established products navigating market changes and Porter is more for useful for entering new markets, so both are useful at the moment.
- Started talking about new opportunities in the B2B space and further up our onboarding funnel.
- Wrote an overview doc for future piece of work. It’s nice to actually create an output sometimes.
- Thought about our roadmap, how we use it, what needs it meets, and how it can be more useful.
- Our AI team won an award.
The numbers
Tasks completed: 35
Minutes in meetings: 825
ProductCon
I went to ProductCon London 2025 last week. It’s been ages since I’ve been to a big conference like this but it’s always interesting to hear about other products in other organisations. My three takeaways were that product management is becoming more responsible for revenue and not just tech, AI is starting to find it’s place in organisational workflow rather than in user interfaces, and keeping pace with technology change is a challenge everywhere.
I read and thought about:
Engineering Our Wicked Problems
Wicked problems come about when hard, soft and messy problems come together. It’s an interesting way to break down and understand wicked problems that I’ve never seen before.
Six questions for managing any project
Answering questions to make choices explicit is a great way to bring some clarity to a project. And starting with user needs is always good. I also like the explanation of which methodology to use based on the evolution of the thing being developed. Agile works well in the experimentation space, but it’s too costly to use when optimising and makes no sense when optimising or standardising. Lean is good when optimising. Six Sigma is good for standardisation.
Rethinking funding and development
Whilst I generally agree that funding distinct systems leads to dysfunctional organisational behaviours, it doesn’t necessarily follow that funding some other ‘thing’ resolves the problems. It’s easy to fund systems because they have a cost (software licenses, people’s time, etc.), but you can’t fund meeting a user need because you can’t say how much a user need costs, and our whole concept of accounting is based on balancing cost/investment and value/return. So, as we can’t fund meeting user needs, instead we fund proxies, i.e., teams that meet user needs. But creates a whole new problem because teams are expensive, so it doesn’t make sense to have one team per system or capability. It isn’t clear to me how an alternative funding model would actually work.
(Also, I don’t agree that product development is building tech – product is not tech – but that’s a different point).
Drag factors
John Cutler posted some steps to get teams looking at metrics. It immediately made me think about the drag factors something like this might face; things like, we don’t have the data, we can’t agree on definitions, who ‘owns’ this, what about that other priority, etc., etc. I think about these kinds of things as drag rather than blockers because they are hard to point to as a distinct problem to be solved, they are just the molasses all us gold fish are swimming in.