Weeknotes 369
This week I did:
Researching why people donate to charity
We’re planning some user research to help us understand why people donate to charity, so I’ve been going through lots of secondary research to help frame the questions we want to ask. There are lots of different perspectives but no academic consensus on why people donate to charity. Snip & Babiche (2011), said, “Trust in a charity organization, affinity with the cause of a charity organization, moral obligation to donate, and donating experience are factors that could positively influence people’s intention to continue donating to a charity organization, while perceived opportunism or risk is a factor that could negatively influence people’s intention to continue donating to a charity organization.” I’m really looking forward to the user interviews.
Check your hearing later
I wrote a blog post about a piece of work we did. The blog post went from idea to live in about 27 hours. I was aiming for 24 but there was some confusion about who was publishing it which delayed us. Speed of delivery is one of those things that is both important and unimportant. I think teams should know how to deliver quickly so they can choose whether to deliver quickly.
Reverse engineering outcomes from outputs
I think we all agree it’s better to start with the outcomes we want to achieve and then figure out the outputs that will get us there, but when that’s not possible it’s good to be able to reverse engineer outcomes from outputs.
Daynotes
I’ve been trying to get into the habit of writing daynotes, which as you’d expect are smaller versions or weeknotes. I try to capture a few things that I’ve thought about that day.
Productivity
I completed 46 tasks across 13 projects. I averaged 9.2 a day, which is a drop from last weeks 9.6. Three days next week and I’ll have a month’s worth of data to review. I want to try to understand if I’m focusing the right amount on the right things. I also shared my tracker with a colleague in case its helpful for them.
Website metrics
In the last five days, my three most popular blog posts were What’s the difference between a roadmap and a delivery plan? with 42 views, Case study on Amazon’s approach to innovation and competition in the knowledge economy, with 33 views, and Systems thinking for product managers with 19 views. Total views was 349.
I read:
The tyranny of collaborative ideation
I read this article about why collaborative ideation is bad, not to find why, I mean who needs more than four words to make that point, but for the last section that mentions how to ideate alone. Last week I started thinking about how there aren’t really any well-established frameworks for developing ideas. Maybe this will help.
Is full stack product management a good idea?
“…whether it’s called “full stack product management” or not, the essence of the product manager’s role remains the same: to be knowledgeable in multiple disciplines and bring them together” I prefer the term “full loop product management”, but I guess the point is the same.
Defining the role of the Product Manager
This is an interesting study on what Silicon valley tech companies expect from product managers, and it’s a long way from full loop. It’s not that different from how the charity sector sees the role of a product manager.
And I thought about:
Product teams are different teams
For a little while I’ve been trying to figure out what makes digital product teams different from other teams. One idea I’ve had is that most teams figure out what problems they need to solve and establish ways of working and processes for that solve them, and then they repeat again and again. That’s the nature of their work. Product teams face new problems each time. Attempting to solve every new problem in the same way will lead to sub-standard solutions. The nature of product work is that it is novel. Maybe that’s part of the difference. It’s also why product teams need to spend time reviewing and improving their working processes, because they might not work on today’s problem.
Prioritise value
Some prioritisation frameworks attempt to prioritise work by what’s convenient for the organisation. Impact/effort does this. What work is most likely to achieve the goals (impact) for the least effort. But, if we want to be focused on delivering value to our users then we should prioritise the most valuable work, even if it’s harder for us.
Barriers removed, value delivered
This diagram tries to show how the most value is delivered when we remove the biggest barrier, and that as we remove progressively smaller barriers the value diminishes until there’s no reason to invest anymore.
