Weeknotes 480

Roger on 10/10/2025

I did:

Starting

Started lots of new things this week.

  • Started a new business case for some future work.
  • Started meeting people from a new team I’m joining soon.
  • Thought of some ideas for an upcoming AI hackathon.
  • Watched a presentation on some brilliant service design for how to improve outcomes for students furthest from advantage.
  • Started planning a workshop about opportunity space mapping.
  • Wrote a list of 4000 profanities for blocking from our platform. The things I get up to.
  • Chatted about playbooks and how they should be the “collective wisdom of multiple voices”, not an instruction manual for the one and only way to do things.
  • Set my annual objectives. I’m not usually keen on personal objectives when everything we do is in collaboration with others, but I’m interested in setting a baseline and seeing how much I can achieve in twelve months.

I read:

Autonomy and alignment

I’ve been trying to understand autonomy and alignment better so I watched and read:

And learned:

  • Autonomous agile teams increase employee motivation and job satisfaction significantly as well as boost creativity and productivity.
  • The biggest barriers to autonomy are teams understanding overall direction (goals are often set by management without involving the teams, that they are often equal to deliverables and deadlines so team members don’t know what the goals are) and managing external dependencies (which requires extra, often distracting work).
  • Formal (e.g., standardised reporting) and informal (e.g., shared values) control mechanisms are necessary for organisational alignment.
  • Enabling constraints (e.g., work in progress limits) help teams have autonomy.
  • Feeling a heightened sense of responsibility is an important cultural element for achieving the balance between autonomy and alignment.

My conclusion is there is a big difference between autonomy and alignment and autonomy in alignment. If you ensure alignment first through enforced control mechanisms and only give teams autonomy within those controls, then you aren’t balancing autonomy and alignment.

Releasing the work at the right rate

A roadmap for successful AI adoption in Higher Education

I respectfully disagree. Not only does the article not mention any of the challenges facing higher education institutions, it talks about starting with well defined problems, but then only problems that can be solved by AI.

I think it’s important to remember that AI and its economic benefit is still just a big bet, it isn’t proven yet. I’m leaning towards it having a revolutionary impact on society but that taking decades to pan out, so in the short-term here’s my roadmap for success with AI (in higher education or any sector):

  • Understand your users. If AI bursts, you’ve got a better understanding of who uses your products and services.
  • Fix your data. If AI doesn’t pan out, you’ve got your data in good shape.
  • Improve your content. If AI fails, you’ve got great content.
  • Train your people. If AI doesn’t replace everyone, you’ve got really capable people.
  • Improve your operational processes. If AI doesn’t automate everything, you’ve got a more efficient organisation.
  • Encourage a culture of innovation. If AI doesn’t live up to its promise, you’re able to respond to the next big change.
  • Coach your teams. If AI doesn’t become the ultimate assistant, you’ve got great teams that can tackle complex problems.
  • Educate your leaders. If AI doesn’t create new business models, your leaders will.
  • Update your technology. If AI isn’t the next big tech trend, you’ll have reliable, secure systems.
  • Run experiments. Even if all your experiments with AI fails, you’ll know how to learn from evidence.

Sort all those things out and AI is easy. Don’t sort them out and nothing you do with AI will succeed.

Thinking about managing

Started reading about the history of management for the first module of my MBA. Interesting insight: cross-functional teams in coal mines were studied back in 1951 for the efficiency gains they had over functional teams with hand-offs.

I thought:

What we get wrong about prioritisation

In his talk about team trust, Tom Dolan mentioned the challenge of prioritisation is (and I’m paraphrasing) that we’re not comparing apples with apples, we’re comparing apples with oranges with a pear tree with an orchard with the concept of horticulture. There is no way to make a rational comparison. So the answer is to not compare. The answer is asking the right questions to decide whether to go forward with the opportunity. Every opportunity should be assessed on it’s own merits.

Future of work

Adam Smith gave us the phrase ‘division of labour’ in 1776 and the factory owners of the industrial revolution turned it into the standard concept for organising work around specialists who perform one part of all the work required to create something of value. Since then pretty much every job has been based on that idea, whether it’s manufacturing, service or knowledge work, each person only knows how to do their little bit.

AI might be the thing that finally changes centuries of industrial thinking about how to organise work. Rather than people with limited specialist knowledge moving the work onto the next person once they’ve done their bit, we’ll have people who are domain generalists doing the human stuff like relationships and navigating messy social systems working with AI that has the specialist knowledge in the domain.

Health care is an obvious example of a domain that could see this change. A patient wouldn’t see a nurse for triage, a radiologist for an x-ray and a doctor for treatment. In this new world, they’d see one person who would use AI to do the triage, x-ray and treatment.

Privilege distance

If power distance matters within organisations, then privilege distance matters between organisations and users.

Weeknotes 479

Roger on 03/10/2025

I did:

Zoooom

Sometimes I work on things that will come to fruition years into the future, but the things I worked on this week things seemed much closer, only weeks or months away. Zooming into the detail and out to to big picture, connecting stuff happening now to far-off futures, thinking strategy, tactics and logistics, and holding all these different perspectives is a product skill I aspire to.

  • Chatted about bias-for-action and when exploring options rather than deciding now is the right thing to do, and my agile decision-making experiment for leaders.
  • Led a leadership standup session. It was interesting to try out the ritual at a larger scale of work. Maybe things like standups working in fractals is a sign of a good ritual pattern.
  • Thought about how we choose the right methodology for certain types of problems, e.g., service design for services, six sigma for processes.
  • Saw some fantastic delivery management clearing space for technical folks to really focus and achieve loads.
  • Chatted about using a personal triage scale of 0 – not worth my time, 1 – I’ll do this myself, 2 – My immediate team needs to be involved, 3 – This needs more coordination across the wider team, and 4 – This needs lots of coordination across and outside the team.
  • Went back to the scenario planning I did a few months and updated based on what we know now. Its a really useful tool for staying on track towards some uncertain goals.
  • Wrote some business rules in Gherkin. It’s been a while since I’ve used it but it’s nice to brush off old skills sometimes.
  • Lots of interviews.

The numbers

My busiest week for a long time.

Number of tasks completed: 62.

Minutes spent in meetings: 1,110.

Escalators and mazes

One of the ways I sometimes use my weeknotes is to get a new idea down and see if I think about it enough to expand on it in a blog post. Escalators and mazes is one of those ideas. These metaphors describe the two broad types of digital products. Escalators take users from one place to another and mazes keep users within the maze. Because “product” doesn’t have a single definition and is often easy to talk about at cross-purposes, I think it’s useful to have lots of different ways of thinking about product, including using metaphors.

I read/watched:

Demystifying product management

Joined Herd Consulting’s fantastic webinar on product leadership skills, radical focus, listening, nudging decisions, correcting for bias, messy realities, experimenting, learning in motion, and aiming at opportunities.

Trusted team toolkit

Got to watch Tom Dolan do a practice run through of his talk for Agile Cambridge. He had some really interesting ideas and practical tips on how teams can focus on building trust.

Kevin Hall triple

Bought kill bad meetings, speed lead and making the matrix work, all by Kevin Hall. I haven’t read them all yet, but I flicked through them and they look interesting.

Stop Saying “Product-Led.” It’s Setting You Up for Failure

Kinda obvious for anyone who’s done and product transformation in a complex organisation but important to say nonetheless. There’s an interesting pattern where complex organisations that do lots of things can’t adopt any a single approach like being product-led for the same reason they can’t get to being strategically focused, there are just too many people, teams and departments to ever reach consensus and coordination.

Scrum Guide Expansion Pack

I read the Scrum Guide Expansion Pack. That’s half an hour of my life I’ll never get back.

I thought about:

Probabilistic product development

Last week, I read Sarah’s post about how the product development process is not designed for building with AI. So I thought a bit about what a probabilistic product development process might look like.

It would be rhizomatic.

It couldn’t use the ‘think big, start small, learn fast’ pattern of modern product development because there would be no way to define any kind of end state or outcomes up front.

It would use language like possible and probable to describe what might happen.

It would accept that user outcomes are unpredictable and uncertain, along with knowing that the product interface and interactions are unpredictable.

Balancing over overing

Not outcomes over outputs. Better to think of it as balancing outcomes and outputs. We talk a lot about trade-offs in product management, as if we can ever choose one thing over another. Instead, it’s almost always a messy mix of different and sometimes conflicting things.

The strategy is relevance

“Relevance is the quality of being closely connected with or appropriate to the matter at hand, indicating the degree to which something is useful, pertinent, or applicable to a specific situation or goal” -thanks Perplexity.

Relevant to who, about what, by how much? Those are strategy questions for organisations in shifting market environments.

A macro example of staying relevant through the last four waves of new tech and how it changed a product might look like this: Banking current accounts (which is the product) used to be paper – paper money, paper cheques, paper records. Then computers came along but were only useful in branches for digitised records. Then the Internet came along so for current accounts to stay relevant their needed online banking so users could access their accounts at any time. The third tech wave was Mobile, which made it so products could be used anywhere, required banking apps to ensure the current account stayed relevant. AI will make it so products are used without the user needing to take action. Throughout those waves of tech innovation, the product stayed relevant by becoming easier (to use anytime anywhere), cheaper (less investment of money and time) and faster (time-to-value).

I might write up some thoughts on how to assess a product strategy based on its relevance. Maybe some kind of scoring system against the three high-level jobs-to-be-done of easier, cheaper, faster.