Weeknotes 456
I did:
Unevenly distributed
The future is funny like that, but I like that I get to work on evening it out. Also this four-day week:
- Did some planning work for three pieces of slow moving work.
- Met our new engineering lead. She’s fantastic and I don’t envy her the task ahead.
- Discussed ways to assess features and functionality to help us understand where we might need to focus improvement work in the future.
- Validated some assumptions about team skill-sets.
- Listened to our product director talk about the Decision Stack, which was really interesting because I’ve done some previous thinking about it (here and here and here).
- Chatted to an interaction designer as I continue with my mission to meet everyone. We talked design systems and about whether interaction design will change if AI agents become more widely used.
- Talked about metaphors for product strategy, starting with Formula 1 teams making choices about tyres, suspension, gears, etc., to perform against competitors who are all in the same environment (race track) but have different resources and capabilities they have to make choices about. It also fits nicely because there are organisational choices in the R & D space about whether to invest in suspension or gears which affect the choices that can be made in the operational space (the team can’t leverage different gear ratios if the development didn’t focus on gear boxes).
I read:
Psychological Safety vs. High Standards: A Misunderstood Dynamic
This is a really interesting article about psychological safety, and presents a positive and helpful challenge to the argument that psychological safety is weakness. It shows how high psychological safety fits with high standards to create an environment that is constructively challenging.
Not product thinking
This is not product thinking. Product thinking is not about features and interfaces. I’ve seen a few of these perspectives recently. The “product vs service design” positioning is really unhelpful. It always tries to make one more important than the other, when really, both are essential perspectives for creating good products and services. Can’t we all just get along?
Agent-ready
I was thinking a few weeks ago about whether products teams are thinking about how to get their products ready for AI agents, and then Ben Whitfield-Heap gives me the answer.
It’s really good to see product people thinking about how agents will interact with their products because MCP is going to change things.
Systems loopiness
Doug Belshaw studied Systems Thinking at the Open University, and wrote and blog post about it, which was referenced in the Open University’s System Thinking community of practice. See? It’s all just one big looping system.
I thought:
Know what you bring
The role of a product manager is not standardisable or generalisable. It’s just too context-dependant for that. So, part of your job as a product manager is to do the intellectual and emotional work of figuring out how you best add value to your organisation. It should probably be a combination of what your organisation needs, what good industry practices you think can apply, and what your particular areas of interest and skills are. No two product managers are the same, and given the same product (in parallel universes), should develop it differently.
Open systems and feedback cycles
It’s good to see the discussion about the length of cycles continuing. Unfortunately, it seems to come down to what’s considered acceptable within an organisation rather than what would really work better.
Going deep, working in cycles is because we recognise that ambiguous product work exists in an open system. And one of the key characteristics of open systems, which makes them different to closed systems, is that they need feedback to achieve the goal. So we work in sprints to create a mechanism that brings that feedback into product development. If the product team can’t get any feedback, there’s very little point working in sprints (as they are working in a closed system). If they get feedback monthly or quarterly, then they should match the length of their sprints to that. Having two week sprints, because it seems like the done thing, but not getting feedback every two weeks creates a lot of admin overhead without much value.
It’s a similar problem for all product practices. Applying them in situations they weren’t designed for is wasteful. Understanding those practices deeply, why they are the way they are, what problems they are trying to solve, is essential for applying them well.
Why can there be only one?
Why do so many organisational structures have one person at the top? Companies, governments, militaries, etc., all have a single person to hold ultimate authority. Is that really the best way to run an organisation?
Nonprofit product
Got linked to from an MTP article.