Weeknotes 530
I did:
Evolution
A few things from this week seemed to be around the theme of evolution, which is an interesting way to think about organisational change because it has no centralised oversight of change, it happens in response to the environment, but also not entirely without coordination.
- Went to a fantastic product group session where teams presented their visions and progress towards them. I think there’s some useful things me and the other product managers can do to help these teams be more successful.
- Talked about when a product approach (you know, understand your users and their problems, try out ways of solving them, get feedback to know if you’ve been successful, go round again with a better understanding of your users and their problems) does and doesn’t apply. For example, it probably works for communicating to large groups of people but might not work for organisational change.
- Prepared presentations for next week. One on the compatibility of proprietary AI models with organisational processes and another on integrating with a third party systems. How cool am I?
- Did some more work on platform product practices, particularly on understanding developer experience and sharing insights.
- Set up a new planning system to try out for a couple of months.
- Chatted about backlogs, vision and strategy, which was really a chat about pluralism (see below).
I read:
Making data-driven decisions with a small sample size
How to Test Product Hypotheses When Your User Base is Tiny
Signals & Levers: Systems Thinking Tools to Unblock Software Delivery
Written in the vein of The Phoenix Project and The Unicorn Project, Signals & Levers talks about metrics and measures, activity and progress, in software delivery. I’m always alert to the fact that software delivery is not the totality of product work, but I’m interested in what I can learn, especially as Phoenix and Unicorn got me interested in Lean again.
I bought it as a kindle book, which I don’t usually do, but given I have five big boxes of books that I don’t know what to do with, I’m beginning to question my life choices.
Marty Cagan’s 10 regrets from the past 25 years
I thought:
Pluralism
If you work in a complex organisation, particularly public sector, pluralism is a useful explanation for how organisations operate. It’s a term used in many different contexts but with the same underlying idea:
- a condition or system in which two or more states, groups, principles, sources of authority, etc., coexist,
- a political theory or system of power-sharing among a number of political parties,
- a theory or system of devolution and autonomy for individual bodies in preference to monolithic state control,
- a form of society in which the members of minority groups maintain their independent cultural traditions,
- a theory or system that recognizes more than one ultimate principle.
Why it matters so much in product work is because it shows us that the popular narrative of one vision, alignment, single purpose, etc., isn’t the only way things can be. It tells us that multiple goals, ideas, values, etc., can coexist, can be in conflict and yet be equally right. It tells us, as product people, that we are in a constantly negotiation, that multiple visions, strategies and priorities can be in play at the same time. It requires us to avoid extreme positions and engage in good faith dialogue that reflects and balances competing principles. It’s a very different kind of product work than you see in the YouTube videos, but it’s just as important, and I think, more interesting.
Coherence
I’ve been (very slowly) writing a blog post about coherence in products. It’s an interesting concept that, to me at least, explains great products. Coherence is, “in general, a state or situation in which all the parts or ideas fit together well so that they form a united whole” and in “scrum and agile methodologies, coherence is defined as a measure of the relationships between backlog items which make them worthy of consideration as a whole.”
We all know that product vision and strategy are our tools for achieving coherent products, but I’ve been wondering if there’s a way to empirically test coherence in a product. And I’m not talking only about the features users interact with, I also mean things like budget, team size and skills, goals, measures, reporting, compliance, decisions, etc., all the organisational parts that make up a product. The logic test I’m playing around with at the moment is whether one thing conflicts with multiple things. An example might be ambitious goals for a well-used product with strong decision-making (all things that seem to have a coherent relationship with each other), but budget that makes the ambition impossible to achieve. The budget is in conflict with the other three things and reduces the overall coherence of the product.
Context ≠ process ≠ results
Those three things are largely independent of each other. The context within an organisation can change without changing the product development processes used by an organisation. And similarly, the product development process can be changed without requiring any changes to the organisational context. Results, and this is the hardest pill to swallow, are mostly unaffected by the organisation’s context or the product development process it uses. We like to think the three are intimately interconnected, that by making changes to processes for example, we can get better results, but it’s just not true.