events

Product Tank Leeds — May 2026 notes

Simon Morgan-Wilson

• 10 min read
Share

Notes taken from Product Tank Leeds, May 2026, hosted at Lloyds. Follow-up to my November 2025 notes.

Contents

Talk 1 notes: Polly Wakefield — Making decisions in complex organisations

Background

  • Product owner at Lloyds, working in existing customer mortgage transmit journeys (customer comms?)
  • The Lloyds mortgage book: largest in Europe, roughly 1 in 10 European mortgages

Why decisions feel hard at scale (the system, not the people)

  • Distributed authority and lots of stakeholders to engage
  • Competing priorities — customer-centric v legal v operational v commercial
  • Decision volume and cognitive load: many people are running on fumes by mid-afternoon
  • Governance forums and checkpoint calls, especially in compliance and regulatory contexts, are largely immovable
  • The mantra of "customer first" has to be balanced against risk, regulation and operational reality

Good decisions v good outcomes

  • "A good decision is one you can defend at the time you made it, given what you knew, the constraints you had and the trade-offs you accepted"
  • Separate the outcome goal (the backbone) from the decision-in-the-moment — getting stuck on the outcome means missing the opportunity
  • Judge decision quality by the process at the time, not just the result
  • Complex organisations need decisions that are explainable, auditable and executable
  • Senior stakeholders need it snappy and repeatable — you'll be saying the same thing in multiple forums

Six pillars every product decision needs

  1. Appropriate framing
    What decision are we making today, and what are we not deciding?
  2. Meaningful, reliable information
    Bring what you have, use ranges rather than getting hung up on exact figures
  3. Creative, doable alternatives
    Rule of three, where one option is always "do nothing"
  4. Clear values and trade-offs
    Every decision is a trade. If you don't raise it, you can't fight for it
  5. Logically correct reasoning
    Show your working, especially in heavily scrutinised environments
  6. Commitment to action
    Who does what, by when, and what triggers a pivot

Example: mortgage recalculation comms

  • Lloyds spends £6m a year on letters
  • Digitising them is a multi-year goal
  • One change in scope: rewording recalculation communications
  • Stakeholder inputs:
    • Polly wanted customer clarity
    • the bank wanted regulatory compliance
    • ops wanted it deliverable without adding workload
  • Options considered:
    • proactive education
    • retrospective education
    • segmented audiences
    • one-size-fits-all
    • do nothing and let annual letters catch it
  • Chose the segmented approach despite the added complexity, because mortgages are sensitive enough that uncertainty causes call spikes
  • The defensibility test: "If a regulatory auditor questioned us, could we stand by this?" If yes, it's a good decision

Making governance help, not hinder

  • Agile means you can pivot. It doesn't mean you can change your mind every minute
  • Treat business controls, risk and legal as collaborators not barriers
  • Decisions are harder when the system dominates the people. And easier when the people understand the system

Practical takeaways

  • Use the six pillars as a decision brief template
  • Lloyds is introducing Product Requirement Documents (PRDs) during discovery as a centralised source of truth and a light-touch RACI
  • Retro on which of the six pillars was your weakest link, then improve next time
  • If you take one thing away: always end meetings with clear roles and assignments, and circulate them afterwards

Talk 2 notes: Richard Atha — Why a product knowledge base is the extra brain a product manager never knew they needed

Background

  • Senior product manager at PokerStars

Problems, by show of hands

  • Everyone in the room had re-read a document they'd already read in the last week
  • Most people had prepped for a meeting by scrolling Slack or Teams looking for context
  • Everyone context switches more than 5 times a day

The proposition: get the stuff out of your head

  • Context switching means your knowledge is constantly leaking out
  • Get a product knowledge base, just a set of files on your computer...
  • ...that an AI could read
  • It's not a wiki or Confluence – not another data graveyard
  • The shift: instead of writing things down so you can refer back later (and never doing), you write things down so AI can help you process them

How Richard's knowledge base is structured

  • Inbox
    Meeting transcripts. AI extracts tasks and actions
  • Personal
    Goals, weekly priorities, current tasks
  • Projects
    Initiatives and active work
  • Areas
    Broader topics, especially people: stakeholder profiles built from meeting transcripts. Who they are, role, how like to be spoken to, what are their goals, what they're currently working on
  • Resources

Three components of an AI "second brain"

  1. Memory
    Context files about people, projects, tasks, meetings
  2. Tools
    Connecting things together (email, Confluence, Slack). Some orgs lean in, InfoSec teams can be nervous. Workarounds when direct connections aren't allowed: manual copy & paste
  3. Skills
    Sets of instructions that act like reliable colleagues. His favourites: meeting prep, weekly review, daily plan

In practice

  • Hooked his calendar into Claude
  • Each morning Claude pulls meetings, identifies who's in them, surfaces previous actions from that person's profile, and lays out the day's priorities
  • A skill run before any meeting brings back history, last actions, the person's communication style
  • Uses Whisper Flow for voice-to-text

Why this matters for PMs

  • Never lose stakeholder context
  • Meeting prep comes with history baked in
  • No more re-discovering or re-documenting the same things
  • Easier retros against quarterly goals

Quote of the talk

  • "Most PMs don't have a knowledge problem. They have a retrieval problem"

Getting started

  • Look at your week and notice anything you repeat or restart every day
  • Pick one routine (meeting prep, daily planning)
  • Map it on paper
  • Hand it to an AI with instructions and let it build the skill with you ("what goes in comes out")

Closing thought

  • AI hasn't come for PM jobs yet – the more the AI knows who you are, the more it can help you do your job
  • The corollary: you also need to know who the AI is

Talk 3 notes: Jade Hanley — From laughs to launches

Background

  • Lead product manager at Co-op
  • Openly dislikes presenting, despite the job needing a lot of it
  • Took up improv on a friend's suggestion as a way to find her voice again
  • Signed up to a course, planned to bunk off at the toilet break — ended up doing the final show
  • Realised improv had quietly taught her things about working with teams

What improv actually is

  • Short for improvisation: a performance with no script and no stage directions
  • A few light rules but mostly a low bar to participation
  • Not about being funny — about being yourself
  • Even if you don't perform, you can listen, give encouragement and play an important role

The session was built around three exercises, each with a takeaway for product teams.

Exercise 1: Counting with gestures (builds trust and psychological safety)

  • In pairs or threes, in first round count to three round-robin
  • In second round replace numbers with gestures: clap for 1, click for 2, silly noise for 3
  • The lesson: trust the people around you to react to what's happening, mistakes are part of it
  • For product teams: mistakes are natural and can be the start of learning. Helps establish the feeling that it's okay to take a risk

Exercise 2: "Yes, and..." storytelling (builds collaboration)

  • In groups of three to six, build a story together where each contribution starts with "Yes, and..."
  • "Yes" means accepting the reality of the scene. "And" means building on it
  • Removes the fear of rejection and creates shared ownership, your idea becomes our idea
  • For product teams: more, different and better ideas surface when people know they won't be blocked.
  • The question Jade left us with: what would happen if your team said "yes, and" more often?

Exercise 3: Plan a holiday with "new choice" (forces fresh ideas)

  • Groups plan a holiday: where, what, how, what's in the suitcase etc etc
  • One person plays director and can call "new choice" — whatever was just said has to change
  • Disrupts autopilot, keeps things surprising
  • For product teams: pushes people past the first viable idea, supports pivots and reacting to new information, encourages iteration

My experience: I improvised with a couple of people sat near me — we covered Scarborough, Lisbon and Rome. I enjoyed it (but I like talking shit), but enjoyed more collaborating with the two people I didn't initially know.

Three ways improv makes you a better PM

  1. Trust that mistakes are okay (psychological safety)
  2. Collaboration through building, not blocking ("yes, and")
  3. Fresh ideas come from dropping the obvious ("new choice")

Where to use it at work

  • Check-ins at the start of meetings — works in person and remote
  • Warm-ups and energisers, especially after lunch 😄
  • Demonstrating psychological safety when new teams form

Talk 4 notes: John Steward — Building the plane while flying it: what I learned in the first year of senior product leadership

Same John from November, this time on the leadership transition rather than sustainable AI.

He framed the talk as deliberately unpolished, an early test-and-learn for ideas he's still working through after his first year in a senior leadership role.

Background

  • Head of Product at DEFRA
  • Maker-of-things background, then product roles outside and inside government
  • Recently stepped up into a C-suite functional leadership role
  • Did an MBA hoping it would teach leadership — found it really didn't

Three reasons to become a leader (and one to be honest about)

  1. Impact
    You get a "badge", a budget, and the authority to direct resources. You can shape the organisation beyond what any single contributor can
  2. Money
    Better than nothing but can't be the only driver
  3. Opportunities
    You get into the rooms where big directional decisions are being shaped, before they hit the ground. As an individual contributor (IC), those rooms are a black box

Reframing leadership for tech

  • Brené Brown: "a leader is anyone who takes responsibility to find the potential in people and processes and has the courage to develop that potential"
  • John's extension: in tech leadership, you also become a kind of internal venture capitalist. The currency is resource allocation — which ideas, initiatives and people you back
  • He used to roll his eyes at "strategic thinking is real work". Now he doesn't

The trap most new tech leaders fall into

  • Staying on the tools — leaning on your IC craft because it's what got you the role
  • Setting perfectionist standards based on your own work
  • Therefore stopping delegating, and therefore not empowering the team
  • Tipping into micromanagement
  • Avoiding the people problems because they're harder and more uncomfortable than the technical ones

Step 1: Mindset

  • It's not about being king — it's about results
  • You're a multiplier. If you were removed, the team's output should drop
  • Get good at telling the story of how your work leads to results — leaders who can't articulate this don't get listened to

Step 2: Manage the double (then triple) load

  • As an IC, you have one boss to please and one set of expectations
  • As a leader, you can't please everyone — you have to settle some things
  • The default failure mode is scaling yourself through hours: 80-hour weeks, weekends, evenings. Eventually you run out of time
  • Stop using your IC expertise as a crutch. The bridge between IC and leader skills is curiosity
  • The real shift is from solving tech problems to solving people problems

Phases of leadership and the skills each one needs

(This is no way exhaustive. I was more listening to John than taking thorough notes.)

  • IC
    Roadmaps, wireframes, personas
  • Leader
    Developing others, managing up/down/sideways, delegating, hiring, culture
  • Leader of leaders
    Uniting a leadership team, cross team culture, strategic direction, change management
  • Leader of leaders of leaders
    Org wide culture, relationships across the exec, partnering with other leaders to co-fund initiatives

Owning your own development

  • Your manager and employer are not equal partners in your career — it's on you
  • Build a talent development network of people with skills you want, not necessarily senior to you
  • McKinsey's idea of having dinner with one interesting person a week. John adopted-adapted it (dinners are expensive) and credits a lot of his growth to it

Step 3: Accelerate decisions and growth

  • The new normal is constant team rebuilding on roughly 12 month cycles — "same hammer, new handle, new head" (I was waiting for Trigger's broom)
  • Imposter syndrome is real, especially where you're the most junior person. Coaching, networks, training and speaking help
  • Constant re-prioritisation, dealing with politics (some of which you'll cause, whatever way), creating new ideas to re-align

The civil service leadership statement as a checklist

  • Inspiring = clarity. Would your team all give the same top three priorities? That's the test
  • Confident = giving people the tools they need — laptops, licences, procurement that actually delivers
  • Empowering = energy and recognition. People don't see you as "John the product guy" any more — they see "John the Head of Product". Saying "that was really good, well done" matters more

Patterns and themes across the talks

Mindset over process

  • Polly: separate the decision from the outcome
  • Richard: don't write notes for future-you, write context for AI-you
  • Jade: collaboration is building, not blocking
  • John: stop being the best individual contributor in the room, start being the best multiplier

Make the implicit explicit

  • Polly: six pillars and a decision brief so the reasoning survives the meeting
  • Richard: stakeholder profiles so you don't have to remember how everyone wants to be talked to
  • Jade: "yes, and" as a stated team norm, not an unspoken hope
  • John: clarity test — if your team can't repeat the top three priorities, you haven't been clear

Psychological safety as a deliverable

  • Polly: trade-offs surface more easily when nobody is being graded on whether they were "right"
  • Jade: mistakes are natural, teams that can fail together can learn together
  • John: empowerment is energy and recognition, not just authority

Takeaway

Treat psychological safety as infrastructure

  • Reframe failure as learning (Polly, Jade)
  • Recognise the work, by name, in front of the team (John)
  • Default to building on ideas rather than blocking them (Jade)

Some quick ideas what here might help in public healthcare?

(Not a definitive list, just a quick brain dump.)

Decision making in heavily governed environments

  • Polly's six pillars translate almost directly to NHS contexts where information governance, clinical safety, and procurement all converge on a single decision
  • The "could you defend this to an auditor" test maps to clinical safety and DPIA scrutiny
  • PRDs in discovery as a centralised source of truth could help when "did we agree this?" gets asked across IGARD, clinical safety, IG, and other forums separately

Stakeholder context as an asset, not a memory test

  • Richard's stakeholder profile approach is directly useful for partner selection and engagement. A structured profile per partner (organisation or person) – goals, constraints, comms style, last actions – would mean team members don't all hold the same context separately in their heads
  • This is the kind of thing that breaks when someone leaves the team if it isn't recorded

Improv techniques

  • "Yes, and" is a quietly powerful norm for a team trying to navigate contradictions — accept the offer then build, rather than block
  • "New choice" is useful when a team has converged on the first viable test partner or a possible service idea. Forcing a second and third option surfaces the trade-offs
  • A short check-in at the start of team rituals creates psychological safety in a team irrespective of how well it is bedded in

Leadership lessons for stepping up

  • The clarity test ("would the team give the same top three priorities at 3am?") is a useful regular check for a team
  • The civil service leadership statement is a useful the framework to check the team against: clarity, confidence (tools and licences), empowerment (recognition)

Next Product Tank Leeds: check the meetup for the next event.