Weeknotes 449
I did:
Timing
So much of success is down to timing. Too early and there isn’t enough impetus or incentive, too late and the opportunity is missed. Timing doesn’t get talked about enough in product management, and now, next, later doesn’t cut it. Other stuff this week:
- Planned a workshop for exploring responsibilities in and across teams.
- Updated our roadmap, by which I mean the data we use to analyse opportunities, not just how we visualise things.
- Talked about the difference between revenue-generating product work and revenue-protecting work, and how new revenue-generating work has to be marketable, it has to change the offer, making it more attractive to potential customers.
- Went to strategy workshop to explore communication systems and where we want to get them to. It helped me think about internal and external coherence.
- Met some colleagues from the B2B side of the org to talk about exploring new opportunities.
- Wrote up some future work that connects existing users with potential future users to create an advocacy loop.
- Chatted to another product person. I’m going to have to go on to product-adjacent people soon.
- Talked about my objectives and the kind of product work I want to focus on this year.
What’s happening in AI
Started working on a kind of AI horizon scanner for product managers working in the UK public, higher education and charity sectors. It’s very basic and manual at the moment (and still quite empty), and there must be a better way of doing it, but for now I want to see what trends I can understand from what’s going on. My hypothesis is that AI isn’t going to generate the expected economic benefits for many years to come.
I read/listened to:
To Change or Not To Change: That is Not The Question
I found this article really interesting. Even if kind of states the obvious – that organisations need to balance responding to change and gaining quick wins with developing a long-term advantage – it’s good to see it thought through like that.
I’ve been thinking about strategy playbooks recently, and the kind of strategic questions that would have to be answered to decide on the play. Is this a throwaway quick win or an enduring investment seem like important questions, particularly with my thing about ‘experiment, optimise, standardise’ and picking the right evolution for a product, i.e., don’t bother standardising something you know to be temporary.
Citation as pilgrimage
“Do you owe other people your knowledge? I think my answer is yes. We do owe each other. Why? Because my mind was built with other people’s knowledge… It puts me on the map, it puts me on other people’s maps.”
As I think more about dialectic practice in product management, the idea of citing our sources to give our ideas providence and those who informed us their due, matters more and more.
Stories
Story-telling is one of those product skills that often gets talked about but is hard to put into practice. This podcast, part one and part two, have some interesting insights into why and how stories work in our brains and our culture.
Not about technology
Completely agree with this. Whether it’s 21st century government, higher education, charity or business, a wholesale change is required to exist and be effective in a permacrisis world. That isn’t just about funding delivery in a different way; it’s about different ways of thinking, changing who has power, relationships between organisations, network-based business and operating logics and models. But this change will take hundreds of years to play out.
I thought about:
Three evolutions
The three evolutions for a product are experimentation, optimisation, and standardisation.
Experiments are great for learning how to tackle new, ambiguous problems but they are costly with almost no financial return. Agile is a good approach here, with cross-functional teams able to learn quickly how to affect the problem they’re tackling. But cross-functional teams and multiple experiments can be expensive so aren’t the right mode for managing a product over the long-term.
Optimisations are about doubling down on the experiments that worked. Lean is a good methodology in this evolution with it’s focus on continuous improvement, but that has diminishing returns which means we can’t optimise forever and which leads to the next evolution.
Standardisation is the final evolution. It’s about building efficiency in having figured out how to be effective in earlier evolutions. Six Sigma is the right kind of approach here as it’s about reducing variation. This phase establishes good practice and policy to achieve consistency.
The main point is that, given the financial constraints every organisation is facing, they can’t apply the same mindset and methodology to every problem, situation or opportunity. Organisations trying to introduce agile as a single methodology for dealing with every situation will find it expensive and ineffective if the product actually requires standardisation.
Dialectical product practice
Whenever anyone talks about the skills product managers need it’s usually not product skills but organisational navigation skills, things like communicating, aligning, influencing. I think it matters how product managers do this kind of work, and I think a dialectic approach fits best.
Dialectic is “a form of reasoning based on arguments and counter-arguments, advocating propositions (theses) and counter-propositions (antitheses). The outcome of such a dialectic might be the refutation of a relevant proposition, or a synthesis, a combination of the opposing assertions.” It’s about allowing people to hold different points of view and help them arrive at the truth through reasoned argument. Whenever we talk about data-driven decision-making, evidence, critical thinking, etc., we’re talking about being dialectic.
If we stray into making emotional arguments to convince others of our position, we lose the robustness and validity that a dialectic approach brings, and I think, undermine something special about product management.
Outcomes-based roadmaps
Products don’t achieve user’s outcomes, products change user’s behaviour and it’s that change that achieves outcomes.
This is important to understand when thinking about outcomes-based roadmaps that connect and communicate how a product changes over time to changes in user behaviour in ways that achieves business results (Seiden, 2019).
The product management problem is to figure out which behaviours lead to the intended outcomes, and then what changes can be made in the product to make those behaviours more likely.
Outcomes-based roadmaps can show the changes in many ways; as thresholds in user behaviour (x% doing y action), as hypotheses (if users do x behaviour, then y outcome will be achieved), as opportunities to explore how to encourage new user behaviours (new feature), etc.
Although outcomes aren’t measurable, user behaviour within a product is. That behaviour might be logging-in, clicking links, submitting a form, etc., whatever is causally connected with the outcomes.
Mapping role responsibilities over sociotechnical system
Messy and incomplete, obviously, but I was thinking about who’s responsible for the different aspects of a sociotechnical system. Arguably, everyone is responsible for culture. Who should be responsible for processes and procedures?
