Weeknotes 429
This week, I did:
Horizons
I’m starting to see the future of our product fitting nicely into some well defined horizons which helps with the real roadmap (not the one with features). Also…
- Quarterly direction-setting. And thinking about OKRs.
- Saw a really interesting presentation from our director of marketing about the competitive environment we’re working in.
- Set my personal objectives for the year. You know how I feel about this sort of thing, but sometimes I have to do as I’m told.
- Did some prep for a big presentation in a couple of weeks.
- Started (unpopular) conversations about how we decide if work is worth doing before falling into path dependency of doing it because we’ve started doing it. It’s tempering ambition with the challenges of complexity.
- Chatted about how the product manager’s role involves getting close to the reality, which includes understanding market shifts, organisational politics, priorities and processes, teams capability and capacity, tech debt, data, etc., etc., to help other’s who don’t get to see all those different parts of the picture to be more aligned, make better decisions, etc.
- Added our design principles to my product assessment (along with user outcomes, service standard, delivery progress and eventually financial performance such as ROI).
- Passed my probation, or to put it another way, I’ve been in my role for six months.
- Lots of retros.
And I read:
Building software like hiring a team
David Knott writes some interesting stuff, including thinking of investing in software like investing in hiring a team. It makes a lot of sense and the analogy goes a long way. There’s a hint of posthumanism in there too.
Roads are set, routes are discovered
I completely agree about using roadmaps to tell the story of a product as you write the story, to show the uncertainty and . That message about how product development goes is as important as what is being developed. But the thing about roadmaps is that time is inherent to them, whatever you call them and however you format them. For example, the Next on a Now Next Later roadmap is always taken as ‘what we’ll do next’, not ‘where we’ll go next’.
Common direction, boring magic
Canvases
Lots of canvases here and here. I like canvases for visualising the work and providing limiting constraints. There are a lot of bad canvases that are just boxes on a page, but there are some really good ones that actually get people to put their thinking together in one place.
The SCARF Model for Psychological Safety in Groups
The SCARF Model identifies five key areas that affect how our brain works in social situations:
- Status
- Certainty
- Autonomy
- Relatedness
- Fairness
These 5 areas represent the social needs our brain considers essential for safety and survival. When any of these 5 needs unattended to, or not met, it sets off a threat response in our brain. When the needs are well-attended to, our brain experiences a reward response. I like this response better than the other one.
Who does what by how much
No solution is specified, and customer behaviour is the measure of success, so the team has to discover the best solution for achieving the behaviour change. If they learn that what they shipped didn’t change behaviour, then they try something else.
I thought about:
Enabling environment
An incomplete and not-entirely-thought-through model of things you might have to change to make a new framework work.
Characteristics of teams from different paradigms
| Industrial-era | Internet-era | |
|---|---|---|
| Governance | Hierarchy | Responsible autonomy |
| Team structure | Functional | Cross-functional |
| Purpose | Meet stakeholder needs | Meet user needs |
| Organised around | Technology | Problem |
| Focus | Efficiency through standardisation | Effectiveness through adaptability |
| Scope | Clear division of labour | Whole task |
| Assumptions | Closed system isolated from its environment | Open system influenced by environmental factors |
| Theory | Scientific management. Taylor (1910s) | Socio-technical. Trist and Bamforth (1951) |
Deproductisation
Not everything has to be a product. In a non-zero interest rate age, organisations have to make very careful decisions about what they treat as a product and where they use more tried-and-tested methods for running teams and systems effectively. A product is a sociotechnical construct. That means it only exists in our minds. Something is a product if we choose to treat it like a product, and it isn’t if we don’t. So, things that just have to happen for an organisation to operate shouldn’t be treated as products. If the problems are well known and there are already established patterns for solving them, there is nothing to be gained from involving product management in trying to discover worthwhile problems. Better to point product managers at areas of uncertainty where there could be competitive advantage.