Weeknotes #279
Photo of the week:
This week, I did:
Evaluation
I mapped user journeys specifically for evaluation purposes, and it got me thinking about whether and how the evaluation of programmes that aim to achieve considerable life changing outcomes can be part of feedback loops. Intuitively, it makes sense that small outcomes have small feedback loops and large outcomes have large feedback loops. But a few things to remember: the aggregation of lots of small outcomes doesn’t necessarily equate to a large outcome, evaluation can be linear and not feedback, and it’s easy to evaluate different things than those that might change the outcome.
And speaking of using feedback loops better, I presented the solution design work I’ve involved with to the developers for their feedback on the feasibility of the ideas. It was really useful and has meant I can creating two solution designs that are more right-sized for what they’ll need to achieve in different circumstances. Such is the benefit of sharing incomplete work early for fast feedback.
Fluency of ideas
I did some more work on Future Skills emails. I complete the second email which is about fluency of ideas, the skill of coming up with lots of ideas quickly. I wrote this email far more quickly than the first so my hope that setting a template would make the content easier seems to be working. We’ll see for the next email which is about active learning. I still have a long way to go to create all of the emails but I think I’m going to focus on this for December rather than spreading my time across other projects like Systems-shifting product management and future.charity.
Retro and delivery planning
As it’s the end of November and beginning of December I did my monthly retro and delivery planning. My lesson from November was about how aiming for simplicity has lots of benefits. Complications slow down progress and drain motivation. In an attempt to make the most of this lesson I’m going to try to focus more time in December on just one project.
And I read:
Measuring kanban
More and more I think the solution to digital, remote, asynchronous working (DRAW, as I might start calling it) is going to be about how we mix and mesh different models, frameworks and practices. One of those things to figure out is how we measure the progress of work without having to be limited to a single way of working that provides consistency in reporting. Kanban metrics focus on how “cycle time that deals with the average amount of time taken for a task to move from start to finish. Improving cycle times by removing waste and blockers help to achieve improved results.”
Humane and ethical design
Following on from completing the Humane Tech course, I read some stuff from Humane by Design and Ind.ie. The pyramid of technology that respects Human Rights, Human Efforts, Human Experience is interesting, and “resources that provides guidance for designing ethically humane digital products through patterns focused on user well-being” are really useful.
Tiny little binge
I read lots of stuff from Tiny Little Business, including The Durable Business Course.
I thought about this week:
Fast and light
Pieter Levels tweeted about shipping fast by building light which prompted me to think again about how I priortise the things I want to work on. I’ve tended to focus on things that interest my rather than things that might be of value to others. Honestly, even if I do figure out how to create a DAO charity, no one is even going to be interested let alone pay for it. The usual way creators figure what to build is to build for their kind of people. Developers build things for other developers. Remote content designers build things for other remote content designers. As a charity product manager there aren’t enough of us. I’m too niche. The answer, perhaps, is to find things that interest me and are useful to others.
Abandoned teams and lack of leadership
I was thinking about autonomous teams and what it takes to get there, and how leadership works for high-performing autonomous teams. Teams have to have leadership. The ideal for autonomous teams is that the leadership exists within the team. For non-autonomous teams, leadership should come from outside the team, from above. But what happens when a team doesn’t have either. A team without leadership is an abandoned team, left to get on with things without direction or cohesion. I’ll probably write up these ideas into a blog post if I get time.
Digital Remote Async Work
Or DRAW, for short. I’ve been thinking about some of the problems we’re all trying to figure out for effective digital, remote, asynchronous working. Things like communication, alignment, coordination of work, etc., all need to be revisited and reworked. Just applying the old ways isn’t going to work. It seems like there’s a good market size there but I stopped myself from buying the domain digital-remote-async.work. I should focus on finishing current projects rather than starting new ones.