Weeknotes 502
I did:
You can’t make an omelette with breaking some eggs
You always lose something when you create a new thing. That’s part of the work to change and improve things. Did this stuff too:
- Talked about what’s next on our roadmap and when it becomes now.
- Went to a workshop to help join up product, policy and operations, which was really helpful in agreeing our responsibilities.
- Saw a really excellent example of the team critically evaluating work and deciding not to do it.
- Chatted about the conundrum of needing to know what you want to achieve to justify starting work and needing to start the work to figure out what you want to achieve.
- Had a great chat with a product manager about career development.
- Said farewell to one of our associate product managers who’s taking a year off to travel. I’ve really enjoyed getting to know him.
Future of education AI
Went to a jam with Oxford University’s UX team. We spent the day going through a user-centred design process for understanding a problem. It was interesting to see how others approached it.
I read:
Platform product management
Read two books on platform product management. The power of product platforms and Effective platform product management. They’re both good but aren’t quite giving me what I’m looking for, mostly because I’m not sure what that is, other than some way of framing the difference between platform product management and the other sorts of product management.
Your Theory of Change Isn’t a Theory
This caught my attention because I’m a big believer in theory of change. I agree that the theory of change documents we create tend to be too linear and fixed. A theory is any hypothesis or set of ideas intended to explain something, especially one based on general principles independent of the thing to be explained. The point of it is to test it against reality and refine it until it provides consistent and reliable explanation. That’s a big mindset shift from how most organisations operate. They still work on the assumption of a predictable world where a theory of change can be specified upfront and doesn’t need testing.
What can we automate?
“What can we automate?” rather than, “What future are we trying to create, and does this tool help or hinder it?” I wonder about this too when using AI in product management, but maybe the either/or nature of the question is wrong. Maybe the future we’re trying to create is just one of improved efficiency and productivity through automation. That’s certainly the economics perspective. There is a future where the scale of change AI brings is similar to email; it doesn’t fundamentally change what we do, it just makes it faster at scale. And there is another possible future where AI’s scale of change is akin to electricity, and so it does change what we do, how we do it, and why we do it. Of course, the future isn’t evenly distributed so different parts of society will experience change differently, and the timeline matters, are we talking about a year or a century.
I thought:
Self-efficacy: Toward a Unifying Theory of Behavioral Change
Self-efficacy is an individual’s belief in their capacity to act in the ways necessary to reach specific goals. The concept was originally proposed by the psychologist Albert Bandura in 1977.
It’s an important concept for product manager’s because as our job to change user behaviours in ways that achieve business results (you know, outcomes)
Bandura’s model says “expectations of personal efficacy are derived from four principal sources of information: performance accomplishments (such as previously being successful in accomplishing something on the product before, AKA “aha” moments), vicarious experience (learning from other products that behave in consistent ways, e.g., the X to close a pop-up is always in the top right corner), verbal persuasion (spoken or written communication such as onboarding videos and micro-copy explanations), and physiological states (how calm the person is because the product is quick and easy to use). The more dependable the experiential sources, the greater are the changes in perceive self-efficacy.”
Achieving a stronger sense of self-efficacy makes it more likely users will change their behaviours and achieve the outcomes we want.
Backlogs
There’s a lot more to backlogs than most people think.
What’s most important:
- The principles – forcing function to reduce options and increase focus, limit work in progress, make work visible, etc.
- The logic – prioritisation criteria, queuing theory, etc.
- The information – about the item, e.g., assignee and status, which allows the item to be managed, and info about the work the item represents, etc.
What’s less important:
- The tool – Jira, ADO, Trello, Post-it notes, whatever works for the team.
- Who manages it – It should be a shared team task anyway.
- Why the work is on it – Obviously that’s important for other reasons, but the backlog doesn’t represent those decisions.
Productisation
“Productisation relates to the process of analysing a need, defining and combining suitable elements, tangible and/or intangible, into a product-like defined set of deliverables that is standardised, repeatable and comprehendible. “ Yeah, that’s product management.
Flow efficiency
Thought about the flow efficiency of the things I’m involved in, which things have higher and lower flow rates, and why.
If I spent all my 37.5 hour week on one thing, it would have a flow efficiency of 100% because I’m at full capacity on it, and a piece of work that has one 30 minute meeting a week has a flow rate of 1.33%. Knowing this helps us understand the difference between working on something for four hours in one week, which has a flow rate of 10.7%, and working on something for one hour a week for four weeks, which has a flow rate of 2.7%. We spend the same amount of time on the work overall, but focusing and getting it done in one go is more efficient.
Observations:
- Flow rate becomes more interesting the longer the time period it’s measured. My coaching work had a flow rate of 10% last week, which is pretty consistent with other weeks. Learning and development had a flow efficiency of 21% this week, but if I look over a year it drops to 0.5%.
- It’s also more interesting as an indicator of time trade-offs. So if I consistently spend the same amount of time on something each week, it will have a consistent flow rate, but when other work causes me the adjust how much time I spend on something
- Flow rate slows when the wait time in between working on something increases. If instead of one hour a week for fours, I do one hour a fortnight, the flow rate drops to 1.3%.
- It’s ok for some types of work to have low flow rate because it’s the kind of work that progress slowly but regularly, things like risk management meetings that will never be “done”.