Weeknotes 462
This week I did:
Where to play
Even for internal products, where to play and how to win questions are still essential for success.
- Watched a talk about leadership by the brilliant Oli Lovell, with gems like “Outcomes are slow magic”.
- Facilitated an all-day strategy session with folks from marketing, engineering, architecture, data and delivery. Went pretty well, got some answers, got good scores on my feedback survey.
- Pitched some cross-team work for a proof-of-concept. Now all the follow-up work.
- Worked on a team costs model to help us make better decisions about investing our time in different pieces of work.
- Went on a mission to find someone with PowerAutomate skills and failed (but failure is all part of learning).
- Played around with grouping work into Epics and Features and writing user stories. It’s been a few years since I’ve used that structure, and it makes me question why and who it’s for.
- Chatted about data quality, and how intractable problems are a messy combination of ownership, incentive, focus, etc., etc.
The numbers
- Tasks completed: 29
- Minutes in meetings: 510.
Not bad for a four day four week with one day in the office.
Old news
Moved my old newsletter posts onto my website so I can delete my Substack account.
I read:
Product Management vs Service Design
I completely agree with Scott about product and service design bringing different but complementary perspectives (same goes for business analysis, content design, development, etc.).
Agile AI
“Problematically, there is no standard practice for how to implement AI in your business. That makes it very difficult for business leaders to reduce their risk of project failure… First, make sure you’re working on the correct business problems. It is difficult to identify business cases for which AI solutions will drive impactful change to the business. Some business problems are not economical to solve with a model because gathering, cleaning, and storing the data are cost prohibitive.” Sounds like you need product managers.
User story mapping
I thought about:
A range of outcomes
When we talk about outcomes, and especially outcomes over outputs, we seem to treat them as conceptually the same kind of thing. But outputs are deterministic, we know what we’re building. Outcomes are uncertain and probabilistic, we don’t know for sure what we’ll achieve. So we should think of outcomes as a range, maybe as best-case to worst-case, or likely to unlikely. We should talk about possible outcomes and not get caught in the trap of treating like better outputs.
AI economics
Last week I mentioned how AI might affect product pricing models, and this week it’s how AI might affect software economics. If cost-per-token becomes a metric product teams monitor to understand the costs of using AI in their products, how might that affect how they use it? I know understanding true cost is next to impossible but it seems very likely to be that AI will change product development costs.
Failing gracefully
Thought about failure quite a bit this week. Read a bit about Amy Edmundson’s spectrum of reasons for failure, reflected on a few recent failures and where on the spectrum they sit. Mostly, I think we still regard failure as a bad thing, something to be avoided, often by having more checks in place. But I think that approach lulls us into a false sense of security because our checks can never cover the unknown unknowns.