Weeknotes 533
I did:
Mental models
How we individually understand how things work so we can change them is a constant fascination and theme to my work. It always seems to come back to whether enough people understand something in a sufficiently common way to do something with it. Some examples from this week:
- Finished some idea analysis. It was a idea good but not for our team.
- Got our platform product managers together to work on our long-term roadmap.
- Planned a workshop for introducing a new delivery playbook.
- Chatted about operationalising data-driven decision-making and what the whole loop looks like.
- Facilitated a workshop to categorise products.
- Worked on an evaluation model for split tests.
- Thought about how a product strategy co-writing session might work.
I read:
The return of the feature factory
John Cutler reflects on his feature factory post; the one that coined the term, divided the factions, led to notoriety. We need terms like this to group our understanding around and prompt discussion, and move our practice forward. But John makes the point about the problems with x vs y narratives. I guess, as his post shows, we never know where the narrative might go.
Online learning developments in UK higher education
Neil Mosley’s quarterly reviews are always interesting, with this one reflecting a number of shifts in UK higher education including school leavers choosing to study online and AI courses. Higher education trends often seem like lagging indicators for societal change. The strategic challenge for universities is which societal change to lean into.
Start Before Product
Scott Colfer talks about the product work outside the product in complex service organisations, and getting oriented before starting, which means understanding where you’re working, understanding the change you’re trying to make, understanding who needs to be involved. All good advice.
I thought:
Merge
Most product development processes are linear. I don’t blame Cooper but he has a lot to answer for. It looks nice in diagrams but it’s not the reality.
I have recently come to the realisation that product development processes are really about merging things, or maybe merging the right things at the right time.
When is the right time to bring together technology and use cases? When should compliance and data architecture come together? When does it make sense to bring evaluation in with user experience design?
A merge approach avoids artificial phases and allows for lots of adaptation depending on the product, teams, etc.
WIP x CIP
The calculation for organisational complexity is work-in-progress multiplied by change-in-progress. Work-in-progress is all the work going on, and I mean all the work, not just the stuff on the roadmap but all the side projects, new ideas people took initiative on, leftovers that never really got finished. Change-in-progress is all the change going on, stuff like people leaving and joining, new organising logic, management methods, and all those reorgs and transformations that never completely changed what they were meant to but leftover things that didn’t get fully replaced when the next change came along. Those two multiplied is how complex an organisation is.
Visioning
A vision isn’t just a statement of what the world looks like if your vision becomes a reality. That’s part of it, but a really good vision provides a sharply refined description of all the aspects of that future world. It gives you a sense of what the market might look like, what size and shape the team needs to be.
Four stages to get to a product vision:
- Setting the boundaries. You need to know what you’re going to try to change and what you aren’t.
- Diverging on lots of things within the boundaries. User research, new technologies, market trends, operational processes, architecture, budget, teams, etc., etc., gives a sense of all the changeable things.
- Converging on the things that matter. Narrow in on all those things until you understand which you would have to change to create your new world.
- Asking what would have to be true. If you want to have any chance of turning the vision into reality you have to be able to articulate the changes you need to make for each thing you converged on. If your vision demands a different architecture, whole bunch of data you don’t collect and partners who don’t even know you exist, you should be fully aware of that before you commit to a vision.
A product vision isn’t just a statement, it’s a mental model. The visioning work is to make that a shared mental model.
Effort-to-value
Effort doesn’t tell you how long the work will take, it tells you if the work is worth doing. It’s a return on investment calculation that helps you understand opportunity cost because if the time spent working on this can’t be spent on that. It’s different to time-to-value because it doesn’t include wait time, it’s the total time everyone will spend/spent on this work to get it to the point where it is returning the required value.