Weeknotes 430
This week I did:
All talk
Lots going on this week to get ready for the next couple of months work. And also…
- Second workshop with the product managers to analyse the activities we do and decide whether we should be doing them. Next time we’ll pick a few and come up with things we can do to improve our knowledge in certain areas and then go do more of the things we should be doing. Follow-through is the key here. It would be easy to run a few sessions and then never make the change happen. Keep on keeping on.
- Had a chat about how we improve communication in the team. My simple answer is talk to each other more. And following my own advice I’ve started setting up chats with all the other product people across the university.
- Reviewed this quarters OKRs and set next quarters. We had some nice successes last quarter but are still getting into the rhythm of when to measure to have confidence we’re achieving the objective. It’s like, if we measure in ten years from now we’ll be really sure.
- Chatted about how to manage some upcoming work that’ll have some challenges. My instinct is to go with light-touch coordination, a bit individuals and interactions over processes and tools.
- Talked a bit about dealing with knowledge worker imposter syndrome, because thinking and talking doesn’t feel like work as it doesn’t produce something tangible.
I read/watched:
User needs checklist
Can’t remember where I found this slideshow but I get the feeling it makes much more sense as a talk. This slide has some nice heuristics for good user needs. It got me thinking about how user needs and user stories relate. And I mean user stories as boundary objects, not formulaic descriptions of what we think a user is trying to do. Clearly user stories should be based on user needs, but beyond that, should there be a one-to-one relationship, should a user story try to meet as many needs as possible, can a user story partially meet a need?
Research methods
Lennart Nacke wrote a great post about picking the right research method. He’s right. It’s so easy to just go with what you know rather than understand what you’re trying to learn and pick the method accordingly. I was I had time to spend analysing a whole load of data. I’d really like to validate my idea that product metrics should be constructivist rather than positivist.
Applying Product Thinking To Your Product Transformation
As is John Cutler’s style, it’s less of a talk about applying product thinking to product transformation and more of a stream-of-consciousness through lots of concepts and frameworks with all kinds of insights. I really like his hill climb analogy and how it takes a long time and has lots of false starts to reach the next local maxima.
I thought about:
Why teams should have regular contact with users
One of the assumptions that makes Internet-era product teams different from industrial-era is that teams work in an open system that is constantly changing and they have to respond to those changes. Industrial-era teams assume a closed system, they aren’t affected by things changing out there in the world. One of the best ways for Internet-era product teams to know about changes is to have regular contact people who’s behaviour shows the change. Things like insight reports on customer behaviour, whilst useful, distance the team from the changes users are going through. They make an open system behave like a closed system.
Operationalising working in the open
Stef Webb, posted on Bluesky, ““Working in the open” are there checklists, frameworks, spectrums I can learn from? Often it seems a theory without practice…”
I think, that like health, working in the open is a phenomenon that can’t be understood by itself. We don’t have a way of saying someone is healthy so we look to indicators like BMI, alcohol intake, etc. We also don’t have a way of saying a team is working in the open so we have to look to indicators like blog posts, show and tells, weeknotes, etc.
Obviously you have to be clear about why you’re working in the open, what you’re trying to achieve, because without that its easy to just mindlessly do stuff, but assuming it’s because you want to change the governance model around the work the team is doing, then other indicators might be how many senior leaders attend show and tells (because it tells you they are being taken seriously), how many questions are asked in non working in the open governance ceremonies like steering groups (because the team is answering them ahead of time), does decision-making speed increase in line with the accumulated working in the open artefacts (because more people have the same knowledge when they need it).
Sociotechnical influencers
What if the delivery manager role was modelled on a social media influencer? They would create a personal brand, get well known for being well known, have followers, learn how to influence people, individually and in groups. If delivery managers were like that, then they’d be in a stronger position to bring about change in whatever organisational situation they find themselves.
User journey happylytics
Been trying to visualise a way of reporting the success of each step of a user journey by defining cohorts by behaviour, where one set of actions are the most desirable but there are other sets that for other cohorts that tell us where we need to do work to shift the percentages.
