Weeknotes 451
I did:
Gradually, then suddenly
Hemmingway’s phrase came up a few times this week, and it nicely describes change; how we experience it and how we make it happen.
- Facilitated a workshop to define future team structures.
- Talked about how we might build up our ability to spot opportunities and what we need to do to be able to jump on them once we’ve spotted them.
- Went to a strategy session. Made me think we don’t need a strategy, we need strategy-agnostic business architecture that still works when strategy changes.
- Got involved in some support tickets to try to understand how that side of things works.
- Started designing training in how to run retros.
- Had a meeting in the woods. It was like the old days.
The numbers
Tasks completed: 30.
Minutes in meetings: 705.
I started tracking my quarterly objectives, and after just one week it’s clear that most of my work doesn’t contribute to them. Might have to do something about that.
Something to think about
Spent some time thinking about ways to help product managers learn, and make use of the thousands of links to articles, blog posts and videos I’ve collected over the years. Maybe it could be some kind of daily prompt for micro learning.
There was a time when I would have jumped straight to building it, but nowadays I’m more considered and cautious of how I commit my time. Or to put it another way, I haven’t actually done anything about it.
I read/listened to:
When to pivot
Researcher Rita McGrath of Columbia University explains inflection points, why we fail to see impending moments of upheaval, and what we can do to be more adept at spotting them.
Impact-first product teams
I started reading Matt LeMay’s new book, and I have to say, it’s as good as everyone says it is. It has simple ‘this, not that’ way of explaining the difference between impact-first teams and low-impact teams that creates a useful mental model for simple brains like mine.
Waterfall is never the right approach
Regular feedback, no hand-offs, small batches, creating shared understanding as you go, accepting what you don’t know, not working in isolation. Is that too much to ask?
I thought about:
Ownership
Ownership is such a messy thing, no wonder it causes confusion. Even between two teams there are lots of scenarios:
| Team A | Team B |
|---|---|
| Thinks Team A owns it | Thinks Team B owns it |
| Thinks Team B owns it | Thinks Team B owns it |
| Thinks Team B owns it | Thinks Team A owns it |
| Doesn’t know who owns it | Thinks Team A owns it |
| Thinks some other team owns it | Thinks some other team owns it |
| Thinks some other team owns ‘that’ bit of it. | Doesn’t know which team owns ‘that’ bit of it. |
| Doesn’t know who owns it | Doesn’t know who owns it |
Product, Project, Platform
Don’t really know what I’m trying to say here, just collecting thoughts in progress (TIP™)
| Product | Project | Platform | |
|---|---|---|---|
| Goals | Outcomes – change in user behaviour that achieves business results. | Outputs – expected and planned deliverables. | Orchestration – interactions and transactions. |
| Patterns | Vision, strategy, opportunities. Iterative change. | Scope, time, cost. Upfront plan. Big bang change. | Healthy ecosystem. Strategy-agnostic. Network effects. Standardisation. |
| Antipatterns | No discovery. | Variances – unexpected changes that go against the plan. | Non-scalable single-point solutions. |
| Deadline | Time-to-value. | Time-to-delivery. | Time-to-coverage. |
| Adoption mechanism | Value proposition, maintaining or increasing user value. | Management, marketing. | Policy, monopoly, seeding, critical mass. |
Making things self-explanatory
If you need to explain how to interpret documents, spreadsheets, miro boards, etc., then you aren’t designing them very well. A simple ‘rule’ for making things self-explanatory is to follow other common conventions: Time flows left to right, bigger things are more important than smaller things, red is a warning.
Step-by-step
I keep going back to the idea of writing simple step-by-step plans for doing a piece of work. Doing it often reveals that we don’t know how to get from where we are to where we want to get to. And then we wonder why work feels so uncertain and reactive. It’s a skill worth practicing.