Weeknotes 408
This week I did:
Only three days?
I had two days off this week, and one of the days I was at work was spent at an event, so there was a lot to make progress on in a short period of time.
- Went to a Salesforce Education event. Two thoughts; lots of universities are using the same tech but each in completely unique ways, and how the big tech strategy of creating lock-in is being used in that space.
- Apologised for shutting down and talking over a colleague. I don’t know what I was thinking, but I don’t expect that kind of behaviour from anyone else so I don’t accept it from myself. I’ll do better.
- Wrote up the retro I ran last week. I like writing up retros more than I like running them. The process of synthesising the points people discussed into themes, building a mental model around using what the team is good at to overcome the challenges, and creating actions for people to own just fits how my brain works.
- Ran a session to come up with some prioritisation criteria and apply them to decide what we should work on next. Amazing what you can achieve in a 25 minute meeting when everyone is focused.
- Had a fascinating chat about measurement and reporting. It was only afterwards that I started to realise that we were coming at the conversation from different points-of-view, and it was thanks to a point Teresa Torres made on a podcast. She said something along the lines of continuous discovery and business research not needing the same degree of reliability and validity as academic research.
- Did some prep work for a service designer to join the team. I’m really looking forward to this and have high hopes for us bringing more user perspective and creating
- Pivoted my approach to creating our roadmap. I’ve given up on my analytical approach of connecting opportunities to objectives and obstacles to provide rationale and am creating a quicker version. I’ll still be able to talk through the rationale, but we need something sooner so progress is more important than perfection.
Am I an unProduct person?
Jukesie’s post about being an unProduct person got me thinking. There’s lots of interesting stuff so I wrote a post questioning whether I’m an unProduct person.
Shuhari for product managers
I wrote a few, mostly incomprehensible notes (it was late at night), on shuhari for product managers. Having thought about it a bit more, I’m wondering if shuhari complements capability frameworks. Capability frameworks are about the skills product managers need, they are defined, have clear(ish) boxes around them. Shuhari is about the practice; it’s fluid, undefined and intangible. Together, they are a bit more holistic. (And, not to get too inception-y, but weeknotes are part of a reflective practice.)
Racing
Went to Silverstone to watch a friend racing. Can’t quite figure out why people do it. When I used to run mountainboarding events, the competition was just an excuse to bring the community together. But in motorsports there doesn’t seem to be any community. People turn up, do their thing, and go home. So why turn up at all?
I read:
The flow system
I started reading The Flow System. I’m of the opinion that the next step in the knowledge base of product management isn’t more frameworks and models, it’s in ways to make the existing frameworks and models fit together. I hope this book helps with that.
How to Be Kinder Sooner
This is a nice post by Kody Fintak and Tara Scott. It doesn’t really go anywhere other than the obvious, but I’m glad to see kindness showing up in software development circles.
The Behaviour Change Technique Ontology
This is amazing work on developing a Behaviour Change Technique Ontology. Behaviour change is so overlooked in product management but it’s so important for outcome-focused work where we define an outcome as a change in user behaviour. It always baffles me that the question of whether product managers should be technical or not comes up again and again, but no one seems to ask if product managers should understand psychology.
And I thought:
Why simplify
Simple things have greater explanatory power than complicated things. So, if we want people to understand more, we have to make things simple. But that definitely doesn’t mean taking things away, hiding or ignoring complexity, or reducing things. That doesn’t make them simpler, it just makes them less.
Philosophically, a simple thing has elegance – only has the parts it needs, and parsimony – all the parts are of the same type. So, when I try to make things simple, e.g. a roadmap (head, meet wall), I have to make sure it ticks those boxes and I don’t try to add stuff that breaks the elegance and parsimony.
Make things, develop people, make things happen
Thought more about Monozukuri, Hitozukuri and Kotozukuri as part of a theme around simplicity. Along with my three-word definitions, and breaking more rules as my practice goes through shuhari, I wondered if rather than specific frameworks and thinking tools, we should start work and teams with the three simplest things of a way to make things, a way to develop people, and a way to make things happen. And do it using plain English, which is another bee I’ve got in my bonnet at the moment.
Will it make the boat go faster?
In my ongoing attempts to help our team focus on the things that matter, I’ve been trying to come up with our own, “will it make the boat go faster” question. The closest I’ve come so far is, “Will it help students succeed?”. I need to test it our with people as at the moment, I know it won’t resonate as we aren’t user focused enough yet. But we’ll change that.
Thought leaders and inaccessibility
LinkedIn’s algorithm seems to amplify posts with images. So, if you’re someone trying to build an audience around your thought-leadership, you might be tempted to create images with text to widen the reach of what you’re putting out. But this isn’t very accessible. I don’t even consider myself disabled, but I use LinkedIn on my phone and have to do a lot of pinch zooming to read the text. It must be a lot harder for others. If you’re a leader that doesn’t care about accessibility, I don’t much care about your thoughts.
Simple product strategy
A simple product strategy has three parts:
- A worthwhile problem to solve
- A hypothesis about how to solve the problem
- A way to know if the problem has been solved
A worthwhile problem to solve
This is where product managers spend most of their effort – finding and understanding problems and figuring out if they are worth solving. Those problems can be big or small, tame or wicked, organisational or customer problems. What makes the problem worth solving depends on the context but could include how many people it affects, how much they are willing to pay for a solution or how much it limits an organisation from doing what it wants to do. Without a worthwhile problem to solve, no strategy is going to create a successful product.
A hypothesis about how to solve the problem
With a deep understanding of the problem and confidence that it’s worth trying to solve, a product manager can create multiple hypotheses for solving the problem. Testing and validating these hypotheses enables the product manager to hone in on the solution most likely to succeed. Getting to a single well-defined hypothesis gives direction about what to build in order to solve the problem.
A way to know if the problem is solved
Product managers have to figure out how to know if the product they built has solved the problem. Often this is by understanding user behaviour and measuring whether the product caused a change in that behaviour, also known as achieving an outcome. The product also has to be scalable, financially viable, marketable, etc., etc. in order to solve the problem for lots of people at the same time.
Shuhari for product managers
Shuhari is a Japanese martial art concept which describes the stages of learning to mastery. Shuhari roughly translates to “to keep, to fall, to break away” or “follow the rules, break the rules, transcend the rules”.
What shuhari is
It’s what happens when you focus on a practice. It doesn’t matter what the practice is for as long as it involves:
- A skill that improves when repeated intentionally.
- Has an established and documented body of knowledge.
- Has space for novel change.
What shuhari isn’t
It isn’t:
- A maturity model – it doesn’t give us a stepped or staged approach to improving skills. It’s almost impossible to define the line between shu and ha or ha and ri.
- A skill assessment framework – it shouldn’t be used to compare one person with another. This is because everyone’s practice is unique to them.
Shuhari for product managers
Everyone starts their practice by learning and following the rules. In product management, this often means using frameworks and techniques without really understanding how or why they work. User stories are a good example. At the shu stage, the product manager focuses on the format and religiously sticks to the ‘As a…’ way of writing a user story. Everyone has to start here.
As they practice, they understand the limitations of sticking to the prescribed format for user stories. They develop the tacit knowledge of how user stories are really just a way of capturing conversations and recording shared understanding. When the product manager learns that how understanding is created and shared is more important than the format it’s recorded, then they are breaking the rules of user stories.
In time, with lots of practice, the product manager learns to apply the reasoning and rationale of user stories without having to consciously think about doing it. They know that user stories are a kind of boundary object. They have transcended the rules of user stories and reached the state of Ri.
Shuhari for teams
Different people on the same team can be in different places. One person might be very experienced and have spent a lot of time developing their skills, whilst another person might not have invested as much effort in their professional. This can cause tension. Someone at Ri could do something because they are so practiced they don’t even think about why they do it, but to someone at Shu, it looks wrong and doesn’t make sense.
Why shuhari matters
We often focus on skills at work but skills are really just the visible manifestation of practice. Shuhari isn’t about the skills; it’s about the practice.
Shuhari tells us that practice and practicing are important for knowledge work roles like product management where there is always more to learn.
Shuhari tells us product managers to get the reps in if we want to be better product managers.
What makes product managers unique?
Maybe what makes it hard to explain the value of product management is all the talk about product manager skills being about communication and influence, which of course is also true of every other discipline and role. If product management doesn’t have anything unique to bring, then how could it show its value?