“OKRs are a mindset. They exist to help you make choices about what to build and what not to build. The team needed a different guiding principle – and I didn’t know exactly what it was, but it needed them to think more deeply about why they were doing this work.”
https://www.takahe.org.nz/heat-death-of-the-internet/
Not to be pedantic but this article describes the world wide world not the Internet. While this dystopian future emerges for the humans using the web, there’s a golden age for the machines using the Internet. Sensors livestream the status of every streetlight in world, the levels of microplastics in the ocean, the heart rate and step count of millions of people. Powerful machine learning algorithms analyse huge amount of data and spot patterns showing how the physical world is interconnected in ways beyond human comprehension.
Driving from A to B, the shortest, most obvious route has roadworks. Even so, it’s still the quickest route… if you only think about yourself and how long your journey takes.
If you think about the effect you journey the queue has on all the other cars, the accumulated delay you create for all those other drivers, then the better thing to do is to take a route that avoids the roadworks, even if it takes slightly longer for you.
Think more widely.
Fight for the things that you care about, but do it in a way that will lead others to join you.
Ruth Bader Ginsburg
This week I did:
It’s been a little while since I’ve been excited about my work. There’s good work to be done here supporting the teams and building products that help the Open University achieve it’s mission. I’ve got lots to learn, lots to figure out, and hopefully lot of fun to had.
One of the things I do when I’m working on a product is create a wiki for it. Usually it’s just a single document when I put info, links notes about changes, etc. I’ve started one for the product I’m going to be working on and it’s already up to 9 pages. Not only is it useful to have everything in one place, but when someone asks “what do we mean by ‘product’?”, I say “everything in the wiki”. A product is the sum of vision and strategy, market research, user experience, security and data protection, testing, change and release management, training, roadmap, risks, governance, team values, etc., etc. Bundle up all that knowledge and expertise, put it out in the world for people to benefit from, and you’ve got a product.
Completed 36 tasks, an average of 7.2 a day.
Met 47 people.
Wrote 32 pages of notes.
Removed work apps from my phone. Not sure how I feel about this, I still have the habit of checking messages in my head but now I can’t do it.
I wrote about my ten years as a charity product manager and three of the challenges for good product management in charities. Because I do occasionally finish blog posts.
I read:
Excellent example of making principles actionable rather than vague sayings that no one knows what to do with. A behaviour change expert I worked with once said, always start with principles to guide you.
I listened to Scott Colfer’s tips for creating a good strategy. And, because it seems to be doing the rounds again, read Martin Eriksson’s Your strategy (probably) sucks. I’m still of the opinion that, just like planning, strategizing is more useful than strategy.
And I thought about:
I read a post on LinkedIn about how product leaders bring a way of thinking about problems that . I take the point it’s making about hiring, and how perhaps some organisations make the mistake of excluding people without industry experience, but I don’t think it holds true that being a good product leader is more valuable than industry experience.
The question, of course, is how does experience correlate with achieving outcomes? We can assume that a product leader who knows how to do things in the right way and has considerable industry experience which means they know what are the right things to do, has a successful combination of factors (assuming you aren’t specifically looking to disrupt an industry). But having one (in this case knowing the right way to do things) shouldn’t be an inherently better factor of success. I wonder if it’s a fallacy in thinking to assume that knowing the right way, being practiced in using frameworks, techniques and methods, is better (see below about shuhari).
I have a bit of a problem with capability frameworks. Product managers learn by doing, and yet so many things that product managers are expected to know are the kinds of things they might do only very occasionally. How does a product manager taking a single product through its lifecycle over a number of years get the reps in for things like market analysis, business cases, defining an MVP, develop a product strategy, etc.?
When everyone knows the same thing, everyone can make aligned decisions. When different people know different things, they make different decisions.
This is why communication is so important in modern (non- command and control) organisations. Without this tacit means of coordination, misalignment is inevitable.
Thought about shuhari some more (it’s been in my head for a few weeks). Criticising those at the shu stage is sure sign of being at the ha stage, just as focusing on techniques is a sure sign of being at the shu stage.