Weeknotes 411
This week I did:
Emerging and merging
The theme for this week has been how things affect each other and evolve together, emerge and merge. I did lots of stuff, including:
- Interviewed senior product managers.
- Joined an in-person team meeting. Still feels weird to be in an office, even if it doesn’t look like an office.
- Discussed prioritisation frameworks. Prioritisation by scoring is a rubbish idea (see below for a better way). Began setting up for a prioritisation session we’re doing soon.
- Talked about the deterministic approach to work and the move to understanding that modern knowledge work is probabilistic. This is the big, hard, deep stuff of digital transformation and the product-centric organisation. You can’t move from having an outputs focus to an outcomes focus unless you’re ready to allow outcomes to be unknown and emerge over time.
- Presented our vision to the team. I had two points to make; a vision is best used to create an identity for our product so others know what we do and why, and that it will be constantly evolving and changing (like any good identity).
- Thought a lot about the privilege people bring to shared working spaces.
The numbers
Completed 36 tasks.
Wrote 9 pages of notes.
Spoke to 36 people, 88 times.
Spent 22 hours in meetings.
I read:
Product principles
Scott has written three principles for creating a pragmatic foundation for organisations to become product-centric. I’ll be honest, when I first clicked the link I was sceptical, but it’s actually quite brilliant (and not just because Scott references the scientific method which I consider to be first principles thinking (no pun intended) for product managers).
Top 10 Ways to Foster Psychological Safety in the Workplace
Levelling power gradients is the number one thing to do to help create psychological safety within a team.
Using brain science to build better products
I bought Design for how people think. I haven’t read much yet but it seems really good and in line with my thing about product management being more about behaviour change than technology.
And I thought:
TBL prioritisation framework
One of the many problems with prioritisation is the idea that using a framework brings some kind of rationality and robustness, when often what goes into it is little more than a guess. As a product manager in a complex organisation, your role is less about making prioritisation decisions, and more about facilitating robust thinking and decision-making to help the team reach prioritisation decisions together. This is especially important when prioritising lots of different types of work that aren’t easily comparable using something like RICE.
Here’s my thoughts on prioritising in that kind of situation:
- Trust – Bring people together and trust their expertise.
- Value – Help your experts discuss the relative value of the things they want to achieve.
- Balance – Help your experts balance the type of work and try not to do too much of the same type at the same time. This is good for stakeholder management and value delivery.
- Limit your work in progress – Do fewer things, better and faster. It’s that simple. If you really want a “framework” for this, here’s one I just made up. Using the Fibonacci sequence, wherever the your team size falls, the next number down is your WIP limit. So, if you’ve 6 people on the team, that’s between 5 and 8, so you should have 3 things in progress. If your team expands to 9, your WIP limit is 5. This helps tackle the idea that team size and output scale linearly.
If you can get a bunch of people who all want different things to agree to let each other have a bit and not overwhelm your team, you’ll go far my son.
Frameworks vs. Concepts
If something is simple enough to be explained in a diagram, then it’s a framework. If it can’t be explained so easily, then it’s probably a concept. Frameworks exist to simplify complicated ideas, concepts just draw boundaries around complicated ideas.
Concepts can’t be explained in a diagram. They require deeper understanding, and no two people understand them in exactly the same way. Psychological safety is a concept, there’s no diagram to tell you how it works. Agile is a concept (I know agile gets referred to as a mindset but I disagree), scrum is a framework.
Why does it matter? Because frameworks are quick to understand and easy to implement but provide shallow, tangible value (which is to say that one framework to do something is just as good as any other). And concepts are difficult to grasp and hard to implement, but provide deep, often intangible, value. A mix of both is good.
Change
There are only four things an organisation can change: people, processes, technologies and products & services. For each of these there are different mechanisms of change, for example, in the people zone changes either who is in the org/team (hiring & firing in HR speak) or what those people know (learning & development).
A change in any zone almost always creates change in all the other zones. There are always ripples. If an org wants to create a new product it’s probably going to need some changes to it’s tech, processes and people.
But for creating certain types of change, the overlap between the zones has higher leverage. So, if you want to change culture, that’s in the overlap between people and processes. Because something like culture is intangible, it only occurs when tangible things interact.
Product thinking
If you want to improve your product thinking, learn about indeterminism.