Weeknotes 497
I did:
Commonly-held truth
This week had lots of thinking and talking about how to get to an agreed understanding about complex, uncertain, and changeable things. It’s where the really interesting product management work happens. Lots of other stuff too:
- Did a quarterly business review.
- Went to our community of practice and realised I don’t talk to enough product people.
- Chatted about the tension of simplicity and variability in business models. You can’t have both.
- Met a new product manager.
- Shadowed an operational team to understand some processes and how they affect the student experience.
- Did some work on defining business readiness and release planning.
- Discussed moving to outcome-focused goals and how they are better for dealing with uncertainty and ambiguity.
- Did some forward-thinking for where a product I’m working on might go in the future and what kind of investment it might take to get there.
- Talked about how most product management questions come down to dialectics (synthesising opposing perspectives through dialogue, AKA communication and stakeholders management) and logical reasoning (deductive, inductive, and abductive thinking, AKA analysis and evidence-based decision-making).
- Developed a proposal for a common approach to platform product management.
Get weeknotes in your inbox
I read:
Team stability
I’ve been trying to figure out how much team stability affects team performance, so I read these:
- Team performance between change and stability
- Antecedents and consequences of team stability on new product development performance
- Team roles and team performance: is there ‘really’ a link?
- On teams, teamwork, and team performance: Discoveries and developments
- A Meta-Analytic Review of Relationships Between Team Design Features and Team Performance
My sense is that there is a sweet spot between too much change and not enough change that is where teams perform at their best. A team that hasn’t spent much time together, doesn’t know each other very well, doesn’t have established roles, has different degrees of experience, etc., etc., isn’t going to be high performing. And a team that has become stuck , isn’t going to be high-performing
The long nose and the long tail
Another insightful and well-grounded piece from Matt Ballantine, this time about how quickly or not technological change is happening.
Bridging silos and overcoming collaboration antipatterns in multidisciplinary organisations
Lots of interesting ideas to dig into from Emily Webber and Ben Linders. I particularly like the ‘collaboration antipattern’ of an X-led organisation and how cross-functional leadership can tackle it.
Being less wrong
I’ll be doing some work on measurement over the next couple of weeks, so I’ve been reminding myself about Bayes theorem and thinking about how to use it to measure uncertain outcomes.
I thought:
Outcomes and objectives
What’s the difference
Both describe a desired future state we want to get to, but provide very different focus for how to get there. Outcomes focus on what’s going on outside the organisation (the clue is in the name), objectives are inside the organisation.
| Outcomes | Objectives | |
|---|---|---|
| Description | A change in user behaviour that we believe will achieve a business result. | A business goal that we believe will achieve a business result. |
| Usage | Situations of uncertainty and ambiguity where it’s unclear how to affect a result. | Situations with a cause-and-effect relationship to things that make a business succeed. |
| Measures | Only measurable indirectly and never with a high degree of verification. | Measurable directly and objectively, i.e., you know if it’s been achieved or not. |
| Phrasing | User does x. Applies equally to one user as to many (that’s why it doesn’t use adjectives like an objective does). | Increase/decrease y. Implies adjectives that describe change such as more, better, faster. |
| Example | New customers can book an eye test within five minutes. | Increase the conversion of new customers booking eye tests. |
How to use them together
Using outcomes on their own or objectives on their own is fine, but they work better together because they provide different perspectives on how to get to the desired end state and know when you’re there.
When we use OKR formats like ‘who does what by how much’, we are intentionally mixing outcomes and objectives. ‘Who does what’ describes the change in user behaviour, that’s the outcome. ‘By how much’ is the objective.
Eat carrots
If you want to create organisational change, tell me how you’d get everyone to eat carrots. How would you buy enough carrots, where from, when would they be delivered, how would you tell people, would you have a stick for those that don’t eat their carrots, who would use. If you can’t get people to eat carrots, you can’t create change.
How to choose metrics
It’s easy, just pick whichever metric intuitively seems important, but before you do that…
- Critically evaluate your organisational beliefs to identify the ontology and epistemology that best fits.
- Define what decisions you want to be able to make from the analysis.
- Carefully select what phenomena you want to observe.
- Understand your theory of change; where the thing you’re measuring is right now, where you want to get it to, and how you believe you can get there.
- Document the evaluation methodology you intend to use, including its limitations.
- Check you have the data available, check it’s quality and that it really is about what you think it’s about.
- Be sure the collection method has consistency and longevity so you know more of that data will be available in the future.
- Make sure you have the pipeline set up to refresh the data on your chosen frequency.
- Establish what kind of analysis and interpretations you want done on the data.
- Decide what data visualization tool you’re going to use.
- Check someone has the skills to query the data, perform the analysis, and update the dashboard. And check they have enough time to do it as often as you’re asking.
- Figure out who needs to know about the dashboard and how your going to tell them about it.
- Check they have the knowledge and skills to interpret the dashboard correctly so they don’t make too many wrong assumptions.
- And many, many more things.