Weeknotes 536
I did:
You’re only as strong as your network
I was chatting to a couple of colleagues about how knowing who knows what you need to know is the secret to success, which made me think about the theory of weak ties again. Anyway, this stuff happened too:
- Talked about which markets we compete in and how they are changing.
- Lots of mixing service vision, product strategy, user experience design.
- Prototyping with copilot (I was pleasantly surprised).
- Ranted about “Individuals and interactions over process and tools”.
- Added new prompts to my AI tracker to see how the answers change over time and whether we’ve been able to affect them.
- Set up a group for some reporting. Small communities around shared challenges is where it’s at.
- Talked different types of work as requirements-driven, evidence-driven and value-driven. Which made me think about push and pull systems and where the ‘No Signal, No Work’ mantra fits.
- Did some roadmapping to test out ideas for communicating for connections between oragnisational priorities, user outcomes and business impact.
I read:
Design Engineering with Maggie Appleton
Your Strategy Is Decaying… Here’s How to Save It
Interesting episode of the One Knight In Product podcast with Evan Campbell. He talks about how, “strategy naturally decays unless you actively maintain it. Organisational inertia, competing priorities and everyday distractions gradually erode strategic clarity. Leaders need to continually reinforce strategic intent and check whether people are still pulling in the same direction.”
The 7 Moats That Still Hold in the Age of AI
Hayder Schneider uses Hamilton Helmer’s 7 Powers to talk about most for AI products. A moat, he says, “is a sustainable competitive advantage that protects a business from competition over time. It makes it difficult or costly for competitors to replicate the business’s performance or take its market share.” I’ve not given it much thought but there’s something interesting how organisations might mix the powers to the create unique moats.
I thought:
Product is sharing
On my more idealistic days, I see products as an ultimate act of sharing. They bring together people’s knowledge, expertise and lived experience, codify it in software, and then share it with lots of other people for them to benefit from.
Think about any product you use, and think about all the people who contributed stuff they’ve learned to make that product possible. I don’t mean the designers and developers who built it, I mean all the people who’s knowledge they built upon. For example, I use kanban boards a lot. And there are lots of kanban-esque products (Trello, Jira, Azure DevOps, etc., etc.). All of those products are only possible because people like Taiichi Ohno and thousands of others contributed their knowledge to the idea, practice and popularity of kanban, which is built into those products.
Three outcomes
When you shift to being outcome-focused, success becomes far more ambiguous. Outputs are easier, you either shipped or you didn’t. With outcomes, there are three possible results:
- The outcome is achieved (user behaviour changed and it lead to business results) and it was because of the work you shipped. This is the one we all hope for but without robust measurement and analysis it’s easy to mistake correlation for causation.
- The outcome is achieved (user behaviour changed and it lead to business results) but it would have happened regardless of whether you shipped your work or not.
- The outcome isn’t achieved (user behaviour didn’t change, or it did but it didn’t lead to business results). This is where lots of product teams find themselves more often than not. Shipping work that changes . It’s the learning space. There’s lots to figure out about why the outcome wasn’t achieved and what to do about it. Do you iterate or abandon?
I reckon there’s some Bayesian calculations that could help figure out the probability of each.
Cowork
Co-work, not cow-ork!
