Weeknotes 459
This week I did:
Balance
Among other things, I…
- Stuck to my new approach to planning my work for the third week in a row. It seems to be working pretty well, probably because it’s not particularly radical. All I do is decide what I want to do this week, add some public accountability, and then get stuff done.
- Went to the CX Circle event and learned some website traffic trends, most interestingly that desktop traffic is growing more than mobile.
- Did some complicated roadmapping work, which was kinda fun. I don’t often have time to get deep into things.
- Planned for an upcoming strategy day that will bring together marketing people, data people, engineering & architecture people, and product & delivery people to think about the next year.
- Chatted through some of the implications of our team moving to more of a build-run-own approach, particularly around access to tools and how much processes need to be standardised (you know how I feel about standardisation).
- Had a conversation about team autonomy and how alignment balances that autonomy. Balance, in all things, is the key.
- Talked about knowing when to quit.
- Got two AI’s talking to each other with humans doing their bidding in between.
The numbers
Tasks completed: 38
Minutes spent in meetings: 885
(First five day week in a long time. Going to have to do something about that.)
I read/listened:
Money stories
Rich Mironov talks about how product managers need to talk about their work in financial terms, which I completely agree with, alongside also telling user stories, systems stories, impact stories and so on.
Minimal product management
Love this idea of picking your four product management tools. Mine are:
- User journey mapping – If one of the core tenets of product management is “create coherence”, then showing the user’s experience the product in a coherent way, and what we’ll need to build to make that coherence a reality is essential.
- Theory of change – Showing the logic of how inputs enable activities, which generate outputs, which allow for outcomes, which achieve impact is amazing for surfacing assumptions, pushing logical thinking, creating a plan.
- Step-by-step – A simple listing technique that brings clarity to actions, and which is so often missed when we only talk about the “next steps” but not what comes after that and after that. If you can’t tell me how you think you’re going to get from A to Z, then you probably aren’t going to get there.
- Kanban – Visualise work, track flow, see current status, limit work in progress. A good Kanban is a thing of beauty.
Imagine a tool that could map user journeys and connect a theory of change at the outputs level, show the activities as a Kanban with the step-by-step for each work item, and the outcomes as metrics. That would be so cool.
State of DevOps report
Read this distilled summary of the 2024 state of DevOps report. The full report goes into the Four Keys, and how to improve measuring them, although I prefer my phrasing of the key metrics. The seven key findings from the report are:
- AI adoption increases as trust in AI increases
- User-centricity drives performance
- Transformational leadership matters
- Stable priorities boost productivity and well-being
- Platform engineering can boost productivity
- Cloud enables infrastructure flexibility
- High-levels of software delivery performance are achievable
AI as normal technology
This is amazing work. “Over time, the superintelligence view has become dominant in AI discourse, to the extent that someone steeped in it might not recognize that there exists another coherent way to conceptualize the present and future of AI… AI as normal technology is a worldview that stands in contrast to the worldview of AI as impending superintelligence… We hope that this paper can play some small part in enabling greater mutual understanding, even if it does not change any beliefs.”
I thought about:
Algorithm of user behaviour
Every product has one, but I’ve never seen it documented. The if-then logic of what a user does and what happens because of that action. Could also think of it as the ‘rules’ layer. I might try to create one for a simple product.
Roadmap zero
You’ve heard of inbox zero, right? What about roadmap zero? Roadmap zero is about taking continuous improvement thinking, the law of diminishing returns, and predictive planning techniques to figure out what a product might look like when it’s no longer worth investing in to keep adding features.
Requirements
I don’t have a problem with requirements, but I do have a problem with the assumption that they need to be known upfront and fixed before work starts. In my experience, every requirement is negotiable and is better shaped through multiple conversations.