Stories and handoffs and testing, oh my!
5 things that surprised me when I spoke at a conference last week
Hi! It’s lovely to see you.
Today, I’m going to share 5 surprises I experienced at a conference with other product leaders last week.
Surprise #1: stories are hard
Ben Sauer ran a high-energy workshop about story and metaphor, and I was surprised to meet a few people who really struggled to tell a story.
One exercise was to tell one another a short story that wasn’t directly about a situation, but that exposed important themes – this showed how you could use a story to lightly bring new perspective to different situations. But some people just … didn’t seem able to tell a story. They would share famous quotes and list sensible principles that applied, but step daintily around anything resembling a narrative like it was a poo on the pavement.
Then I remembered a point from Cynthia Kurtz’s excellent book Working With Stories:
“the number of personal stories told in natural, everyday, casual conversation by any random person in any industrialized country is likely to be smaller than at any time in the past, reaching back tens of thousands of years ... we just don’t tell stories the way we used to.”
So what?
We could all use more practice collecting and telling stories. Especially oblique ones!
I know I know. You’re rolling your eyes and sucking your teeth at this obvious point. “Storytelling” is such an overexposed trope in business, with articles, books and courses piled high. But I’ve found that most of what happens in practice is still too literal, too direct, too paint-by-numbers. I think it misses the magic of the oblique story.
Ben’s book and workshops might be just the new angle you’ve been looking for.
Surprise #2: handoffs are still everywhere
Alicia Calderón gave an excellent, pragmatic talk about designer and developer collaboration, and I was surprised to realise just how many companies still (yes, still now in 2024!) rely on a high-fidelity design-to-dev handoff as if it’s a thing you have to do.
I enjoyed the amount of detail Alicia got into about some of the misery this practice generates (not all of it, mind… I mean, she only had half an hour) and her clues for how to start to smear out the handoff from one moment to many, so you can — gasp! — work together. And eventually maybe not need a handoff at all.
So what?
After I mentioned this on LinkedIn, a friend asked if I knew why handoffs are so hard to shift – even on teams that know they suck. I ended up thinking of so many personal and collective conditions that it’ll make for a whole nother post. (Let me know if you’d like to read it soon.)
One condition is that meetings and workshops often feel like a waste of time. That one I can help with right now.
Perhaps your experience of collaboration has mostly been talky-talky meetings about abstract concepts and then everyone goes off into their cave to chew through their task list? Perhaps it’s been long workshops that drowned you in sticky notes but didn’t make anything clearer? In either case, may I recommend trying Multiverse Mapping, initially with a small group?
I give quick instructions for free here, or you can get a detailed video walkthrough here. Multiverse Mapping isn’t magic, but it is quick and enlightening. The game is to gently herd everyone to a collaboration-friendly level of granularity – somewhere in between the Lofty Idea™ and the finicky implementation details.
Surprise #3: testing ideas is still abnormal
With my usual caveat that “validation” is a deceptive framing, it’s also a term that has permeated through businesses like a retro-virus. Tshili Ndou shared compelling stories of how validation testing had saved her company vast amounts of time and money. She made an impassioned plea for teams to do more of that kind of thing.
I confess I was surprised that people needed to be told it was a good idea to test their ideas. My hunch is that deep down everybody already knows that it’s a good idea, and yet they’re still not doing it. Less a question of motivation, and more a question of capability and incentives.
So what?
I suspect part of it is a Catch-22, where most teams haven’t had a chance to practise designing effective experiments. In 2024, tech teams ride on a razor edge of constant burnout just getting stuff done. I can understand why they’d be wary of adding more process and more testing, especially when it feels like it creates more delays.
So I’ll give you my best secret trick: never ever add work, only sequence the work differently so you can get signals now.
A simple example. You’ve been given marching orders to ship a new feature this quarter. This means designing and building it, then getting it out to customers. It’s day 1 of the quarter and you’re planning your work. You realise you can hear an annoying voice whispering in your ear. It’s me! I’m saying this: “imagine it’s already the end of the quarter, and you’ve built the feature. Now you’re figuring out how to get it out to the customers. How are you doing that and what do expect the result to be?” After you tell me the plan I ask, “and why not try a small, rough version of that plan today? Draft some copy and get it to a subset of customers! You’ll get ahead of figuring out that bit so you won’t be rushing it – and you’ll be able to use what you learn to do a better job!”
With every team I’ve helped, we’ve been able to spot something with a lot of uncertainty that they planned to do later, and do it today instead. This something is often getting the idea in front of customers. Other times it means you get hold of some real customer data to put through an algorithm or design your screens. Or it’s about trying to get third-party APIs or suppliers to play ball.
Your success always depends on the behaviours of people and systems that are outside of your control. So bring those parts up front and save the comfy, easy stuff for later. Hard Test, Easy Life my friend.
Surprise #4: customer contact sports
In a happy coincidence, I brought the above threads of story, collaboration and validation together when I ran 2 workshops at the conference. I took about 150 people through Multiverse Mapping. This is a kind of structured storytelling. It pulls everyone to a level of granularity that supports collaboration between disciplines. And it can help you quickly design effective tests, experiments and technical spikes – simultaneously getting buy-in from your team and execs alike. (Big claims, but I’ve seen this work enough times now that I’m backing it.)
One thing that surprised me during the workshop was that two independent teams ended up tackling the design of a contact form, and both openly shared that the goal was to make it much harder for customers to contact the company. I probably shouldn’t have been surprised, given ... *gestures around at everything* ... and yet.
I hope the teams wanted to make the rest of their customer experience so amazing that nobody would ever need to contact them. I’m not so sure their organisations are on board with that though.
So what?
As I suggested to the teams in the room, if the “best universe” you map tells the story of a customer being stymied by bureaucracy, then the “worst universe(s)” on your map might tell the story of a frustrated customer starting a viral social media storm or lodging a complaint with their MP or ombudsman, as well as taking their wallet elsewhere.
You could also extend your map earlier in time to cover some of the reasons customers are getting in touch, and build a positive business case to tackle those instead. Show the thing to create a chance that you can change the thing.
I’m borrowing this from another speaker at the conference, John Willshire of Smithery. He gave an amazing talk packed with insights and gorgeous story of rewilding (seriously, if you get a chance to experience it yourself, do!). And a simple diagram he shared really landed for me. This is the virtuous cycle at the beating heart of Multiverse Mapping:
I live in hope that — as you’re reading this — you want to de-suckify your software, not just metaphorically stuff your fingers in your ears so you can’t hear your customers wailing.
Surprise #5: what’s a Cynefin?
I opened the conference with my talk about what I called the “Complexity Gap” in research and design. In the talk, I build on Dave Snowden’s Cynefin framework and then share a simple, pragmatic method you can use to embrace the generative power of emergence in complexity – instead of trying to wish complexity away or sweep it under the rug.
I was REALLY surprised that only a handful of people in the audience had heard of Cynefin (or at least admitted to having heard of it). It’s been an incredibly useful framework that’s challenged and shaped my thinking and practice for the past 8 years. I think anyone working in product or tech would be wise to be aware of it.
And so I was also delighted when more than a few attendees said my introduction made it really clear, as it’s not always easy to approach.
So what?
If you’d like to see the talk too, join me for The Complexity Gap: a live webinar plus Q&A on 17th July at 5pm BST.
In a live 30-minute talk, I’ll cover what goes wrong when you try to jump over the Complexity Gap ... and what you can do about it. This will be followed by an open Q&A when you can grill me with your thorniest strategy questions.
See you there!
Were you surprised?
Which of these 5 surprises was surprising to you?
Or were you more surprised that I was surprised?
Leave a comment and let me know!
Bonus Surprise!
UX London was a surprisingly brilliant conference. Thanks to Jeremy Keith, Louise Ash and the whole Clearleft team for organising, plus all the amazing speakers, workshop facilitators and attendees – I really enjoyed hanging out with you.
Until next time,
Tom x
P.S. if you know a conference organiser I should talk to about speaking or workshops, please let me know.
Damn! #3 is just what I needed for a tech leader in meeting with today. Thanks for the elegant example, Tom!