Weeknotes 524

Roger on 15/08/2026

I did:

Seeing around corners

One of the less appreciated product skills that I try hard to cultivate is my ability to predict what’s going to happen based on observable signals. A few things I predicted came true this week, and a few more are looking more likely. It’s a skill I keep trying to calibrate and get better at. And did this stuff too:

  • Chatted about the product strategy I’ve been working on. I did some more competitor research but still have so much work to do on it..
  • Shared the bad first prototype dashboard for our North Star Metric for feedback ahead of presenting it next week.
  • Handed over product management of our big bet for one of our products to another product manager. Part of me would have liked to have worked on it but I know he’ll do a much better job of taking it where it should go than I would.
  • Wrote some definitions of “validation” and “time-to-value”, which I really enjoyed because it tested my logical thinking.
  • Agreed recommendations for what we do next with an AI feature we’ve been testing.
  • Got a volunteer to take on managing our analytics capability.
  • Brought together different thinking on delivery reporting and product evaluation. Where I’d like both to go in the future is using Bayes to show the probability of delivering on time and achieving outcomes.
  • Short-listed candidates for a content role in our service.
  • Planned more work. Like I always say about agile planning; I can tell you what will be delivered but not when, or when but not what.

I read:

Know Your Agents

Read Tom Loosemore’s full briefing for Know Your Agent, which he very kindly sent me.

Tom says, “People are starting to send software, not themselves, to deal with your organisation. If that sounds slightly odd, it won’t for long.”

I completely agree. There was a time when organisations thought the internet wouldn’t change how customers interact with them. And then it was mobiles. Now it’s AI. The pattern repeats. Get ready.

I thought:

Loops, not lines: a modern product development process

Most product development processes follow linear steps based on manufacturing processes, often to their detriment. Far too much software gets shipped that that no one wants because once the process starts it doesn’t know how to stop.

I’ve been trying to figure out what a looping product development process that seeks progressive validation of an opportunity (rather than delivering on unvalidated assumptions) might look like.

  1. Analysing existing evidence
    1. Evidence quality: Existing research data, not from users, not from interacting with a product.
    2. Techniques: Performance data, previous user research, third-party information, industry case studies.
    3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 2.
    4. Confidence-in-value level: Low.
  2. Collecting new evidence
    1. Evidence quality: New research data, from test users, interacting with a test product, with an intermediary.
    2. Techniques: User interviews, prototyping, observation study, fake door tests.
    3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 3.
    4. Confidence-in-value level: Medium.
  3. Generating real user proof
    1. Evidence quality: New usage data, from real users, interacting with a test product, without an intermediary.
    2. Techniques: MVP, split, concierge and wizard of oz tests.
    3. Decision: If this analysis shows the opportunity to not be worth investing in, stop. If the analysis suggests potential value, go to step 4.
    4. Confidence-in-value level: High.
  4. Collecting proof at scale
    1. Evidence quality: New usage data, from real users, interacting with a real product. without an intermediary.
    2. Techniques: Data analysis of a large user base, performance data that signals continued, repeated use or a pipeline of new users.
    3. Decision: Continue to invest in supporting the product.
    4. Confidence-in-value level: Very high.

This approach tries to fit with the stuff I go on about the job of product management tools is to filter out the ideas that won’t work. If there ever was such a tool, it might be based on this concept of progressive validation.

Disruption-proof

Are any industries not susceptible to disruption, and is higher education one of them?

We know what the pattern of disruption looks like. A new market entrant provides an offer that looks worse than the incumbent offers, attracts a new audience, builds momentum and investment to grow, provides a different or better offer to the incumbents audience and steals enough of them to make the incumbent fail, and the new entrant becomes the incumbent and sets the direction of the category.

That model works for fairly straightforward industries such as mobile phones (Nokia and Apple), watching movies (Blockbuster and Netflix), but the higher education industry is far more complex and extremely difficult for new entrants to unbundle in a way that creates a disruptive offer.

Universities bundle many things in tightly-knit ways; learning, accreditation, making friends, choosing a career, finding a partner, shaping identity, growing up, changing careers, having a sense of achievement, and so much more.

I think that bundling lots of things together in a tight-knit way where everything connects to everything else, makes universities really difficult to disrupt. Those that say things like, “YouTube is free university”, don’t get what a university is. This also means universities have no need to innovate on their business models, but then again, do they need to?

Sociotechnical systems change mechanisms

When we talk about change, what things can we actually change within an organisation? Sociotechnical systems theory gives us a broad framework of six areas so I listed all the changeable organisational elements I could think of within them.

Goals:

  • Vision
  • Strategy
  • Prioritisation
  • Target-setting
  • Performance measures
  • Governance

People:

  • Recruitment
  • Role design and responsibilities
  • Reward and recognition
  • Management and reporting lines
  • Coaching
  • Training
  • Community
  • Incentives
  • Motivations

Process:

  • Workflow design
  • Policies

Technology:

  • Tool utility (how well does it do the job without workarounds)

Culture:

  • Leadership behaviour
  • Communication
  • Storytelling
  • Role modelling
  • Shared norms

Infrastructure:

  • Workspaces
  • Facilities
  • Equipment

So, if you want to have a well functioning organisation, you need to get all those things right in ways that they don’t contradict each other.

Copilot notebooks

Microsoft might have actually found a way to make OneNote useful by connecting it to Copilot.

Get weeknotes in your inbox