Understanding and avoiding miscommunication when making cakes (and other projects)
Have you ever had your order or instructions (for a cake or otherwise) go hilariously awry?
Oh dear... How funny. I'm sure there's a lesson in these somewhere.
Stay tuned to this episode with product development expert John Cutler, for practical advice on improving clarity and collaboration in your projects.
In this episode, we discuss the phenomenon of 'Cake Wrecks,' where instructions for creating something go hilariously wrong, and how this applies broadly to miscommunication in product development. The conversation is joined by John Cutler, a prolific writer and ("on second") thought leader in digital product development. We delve into the importance of clear communication, prototypes, and iterative understanding in avoiding these 'wrecks' in both hardware and software realms. As always, we also touch on real-world examples, the role of user experience, and the necessity of involving all team members in the design process to ensure a shared and accurate understanding of project goals.
Topics Covered.
00:00 Introduction to Cakewrecks
00:57 Everyday Essentials and the Magic of Three
01:44 The Versatile Bic Four Colours Pen
02:17 Reminiscing About Handwriting and Notes
05:31 Introduction to the Podcast and Guest
05:39 Exploring Cake Wrecks and Misinterpretation
06:29 John Cutler's Journey and Insights
13:47 Challenges in Product Development
20:07 The Illusion of Fixing Decisions
20:28 Challenges in Hardware Manufacturing
21:13 The Importance of Clear Communication
22:44 Prototyping and Specification
23:46 Avoiding Misunderstandings in Projects
25:20 Participatory Design and User Experience
28:18 Embracing Diverse Perspectives
34:48 The Role of Sketching in Communication
37:55 Concluding Thoughts and Resources
Get in Touch
Have you ever had your instructions result in something way more literal than intended? Or did you mis-interpret the orders of someone else?
Let us know:
Reference Links
In this episode we also reference:
All music on this podcast is provided by the very talented Franc Cinelli.
Jono Hey:
Cake Wreck is a term where people are given an instruction for a cake and what they like on the cake, and people have read the instruction and interpreted it very literally.
This one just says nothing across the middle.
You know, say, what do you want on the cake?
I want nothing, please.
That's what they got.
I know it from my day job in software development.
You've written something down and then you thought it was clear, but it turned out not to be clear.
John Cutler:
The key thing is to get something in your hands that you can feel and test your understanding over and over again.
Tom Pellereau:
I'll never forget an example where clearly we hadn't provided enough photos.
And so we got delivered six nail files squeezed really tightly into the original package.
John Cutler:
In Spinal Tap, the movie, you know, they don't put the ticks the right way.
So they make an 11-inch Stonehenge.
Rob Bell:
Hello, and welcome to Sketchplanations, The Podcast.
Wallet, keys, phone, swimmers, towel, goggles.
When it comes to the essentials for everyday situations, three is often the magic number.
Let's do some more.
Camping, tent, sleeping bag, flashlight, or just use the one on your phone.
Shopping, reusable bags, wallet, or just pay with your phone.
Shopping list, probably actually in the notes on your phone.
Going for a drive, car keys, use the digikey on your phone nowadays.
Map, come on guys, Google Maps on your phone.
And well, your phone.
According to research, by the year 2036, humans will use their phones for literally everything.
Which raises the question, whatever happened to the humble Bic Four Colours ballpoint pen?
The only other tool in history to be relevant in every possible situation.
Going shopping?
Take the pen.
Going to work or school?
Take the pen.
Going out on the pool?
Take the pen.
I'm Rob Bell, Black Ink, Small Caps.
And joining me once again is the Don Juan of doodling, Jono Hey.
And the colour coding king of the crayon, it's Tom Pellereau.
Hello guys.
Tom Pellereau:
Hello.
Jono Hey:
Hello, mate.
Rob Bell:
You remember the days of the four-way biro?
Tom Pellereau:
I certainly do.
I've upgraded my, I use the pilot friction, which is a four-way that you can rub out.
It's just, but I can't get them in the UK.
I have to get them from Japan.
I have to get them.
It's ridiculous, but they are amazing.
Rob Bell:
Seriously, I expect you get them specially imported.
Tom Pellereau:
I've put them via Amazon, I think.
Yeah.
So it's not too much.
Rob Bell:
I mean, there was no situation back then when you'd have them with you all the time, that they wouldn't come in handy, right?
Jono Hey:
There was one point where I decided that the ink quality wasn't quite nice enough, and I carried around three separate pens.
Tom Pellereau:
I remember that.
Jono Hey:
I might have two in my pocket right now.
Tom Pellereau:
I'm sure you still do.
Jono Hey:
Yeah, usually two.
Tom Pellereau:
You'd have the thick gray one as well.
Rob Bell:
So the pen is still going strong.
I mean, what I find nowadays is having the pen is one part of the challenge.
Finding scraps of something to write on, scraps of paper or, you know, back of a napkin, something that has gone out and you don't see this as much anymore.
Writing stuff, writing reminders on the back of your hand.
I just, I don't do it as much, half as much as I used to.
And you just don't see it happen anymore.
Jono Hey:
Because you write it in your phone.
Rob Bell:
There you go.
Jono Hey:
Yeah, that's sad, isn't it?
Generations of people won't know the pain of writing the by-roll on the back of your hand.
Rob Bell:
Not suffering from ink poisoning or not being able to get it off because you've accidentally used a permanent marker.
Yeah, I figure out of the three of us, Tom, you're probably the most likely to have used all of those, all of those colors.
Tom Pellereau:
Oh, yeah.
Yeah.
Black is for work.
Blue is for personal.
Green is good or highlighting it.
Red is like urgent, obviously.
There's a system.
Rob Bell:
I need to have a system.
Yeah.
Tom Pellereau:
In my diary, in my logbook, in my mind map, to-do list.
Yeah, exactly that.
Rob Bell:
Jono, do you have a system?
Jono Hey:
No, but I like to use just a black and then other ones for highlight.
It can be different colors, but you're adding another layer of information to your existing stuff.
And you see that in the sketches a lot.
Tom Pellereau:
As you can imagine, listeners, Jono also has the neatest and most neat notes.
His university notes were just incredible.
Do you remember them, Robbie?
Rob Bell:
I do.
I changed my handwriting.
Jono Hey:
No way.
Rob Bell:
I changed my handwriting because of Jono and Jono's notes.
Specifically, a small a, a lowercase a.
Jono Hey:
Well, what's funny, isn't it?
The way you're taught to write a's in school is not the way that a's are printed in every book you ever read, which is the little over the top and then the little circle underneath.
Isn't that funny?
Rob Bell:
And it took a while to retrain that, but you know, I was doing a whole image rethink.
Jono Hey:
You had a hair cut as well.
Rob Bell:
Image rethink, yeah.
I saw when I went from Robert to Rob slash Robbie, cut my hair slightly differently.
Jono Hey:
Side parting.
Rob Bell:
So it was a period of change.
Jono Hey:
I love it.
Rob Bell:
And I just embraced it.
Well, listen, enough reminiscing of times gone by, whether by pen, word processor or on your phone, it's time to write new chapters.
It's time to podcast.
This time, we're gonna kick off our discussion around the sketch entitled Cake Wrecks when professional cake making goes hilariously wrong, usually due to the misinterpretation of a customer's request.
And when you look at the sketch, you'll see exactly what I mean by that.
And we'll use that situation as a metaphor to explore the misinterpretation of instructions and demand in a much wider sense.
And to help us do that, we're delighted to welcome another guest onto the podcast, a guest who's been described as a thought leader who has years of experience solving complex problems and answering tricky questions predominantly in the world of digital product development and user experience.
John Cutler is undoubtedly a man of many talents with a prolific output and whose profession and expertise are actually quite difficult to condense into a pithy three-line introduction.
So I thought the best way would be to say, hello, John, welcome to the podcast.
John Cutler:
Thanks for having me.
I prefer to be a thought-fast follower or an on-second-thought leader.
I'm going to coin that one.
Tom Pellereau:
That's really good.
Rob Bell:
To people outside of the world of digital products and services, myself included, who might not know you as well as those within the industry, how would you briefly describe what it is you do?
John Cutler:
Well, I started to write obsessively about product as a product manager, and I just kept writing, observing and writing, observing and writing.
Then I started to get some jobs that put me in touch with more companies every day.
So it was more external focus, so dealing with customers and talking to customers.
I'm an observer, I guess.
I'm a pattern matcher, and I talk about the patterns I see, talk about shifts in the product landscape, talk about doing product management, some design stuff, some UX research things.
But I'm basically chronicling my own journey in understanding product, and I just did that obsessively.
I've written hundreds and hundreds of posts.
It's probably millions of words now, but I calculated the other day that I've written a blog post every 4.2 days since 2015.
Rob Bell:
This is the prolific output I was referencing, Jon.
John Cutler:
This is it.
So yeah, it's tough to describe, but I'm sort of a...
That's why I cringed a little bit at the thought leader thing.
I am really just exploring this space and then chronicling it while I'm doing it.
And I have built some perspectives over the years, but I try to stay fairly open minded about it.
Rob Bell:
And when we're talking about products, because as I mentioned, many of our listeners won't be involved in the digital world.
So when we're talking about products, we're talking about digital products, online products, apps, this kind of stuff.
Is that right?
John Cutler:
Yeah, I have focused there.
I've also focused on generally in companies in general.
Some of the companies I've worked at have had physical products too, like point of sale systems and things that you interact with as well.
I have become increasingly interested in decision making and design is a more broad concept like service design or thinking about how companies change or organizational design.
So yeah, my sweet spot was product development, digital product development, the app you use, the thing.
But I've been increasingly thinking about how to think of whole companies as a product or a book as a product or a workshop as a product.
So my thinking has expanded over the years.
But yeah, for reference for folks, it'd be easy to think of it as the company that builds the app you use, for example.
Rob Bell:
Now one thing I read about you, Jon, I think this was maybe earlier in your professional career that you created a video game based on running a bar.
Is that right?
John Cutler:
I did.
That was my first product.
I dropped out of college.
Rob Bell:
Yeah, this is good.
These are the good stuff.
John Cutler:
I marched to the department store with a credit card that I had found my parents to cosign for somehow, that was meant to be used for school supplies, and I used it to buy a computer.
Then I went about this way to make a bartending game.
I was inspired to make the game because I tried to get a job at a bar and it was difficult.
I thought, how can you learn how to make all these drinks?
You can still go on YouTube and search Last Call Bartending Game and you can see it's this 2D cell animation product.
But it was a lot of fun.
It's a great thing to do in your early 20s is to try to make some kind of product like this with a bunch of people.
But it was fun to do it.
Rob Bell:
Well, listen, with many people's lives being increasingly influenced by digital products, either directly or indirectly, I've got a hunch, John, that there's a lot we can talk about and hopefully learn from you in this discussion that's applicable both inside and perhaps outside that digital world.
And Jono has done quite a few sketches that relate to product development and UX.
But what I thought we'd like to start with would be to talk about Jono's sketch on Cake Wrecks.
Now, you should be able to see this sketch on your screens there now, but I'll include a link to it in the podcast description down below just in case.
And whilst you're there, you'll be able to find links to any other sketches and interesting references from this episode, including that link to the YouTube clip of Last Call.
Don't forget, we'd love to hear from you, our listeners, about any of your thoughts or experiences with the bits we covered today.
Tom Pellereau:
And you can email us on hello at sketchplanations.com.
Rob Bell:
Brilliant, right, Jono, do you want to give us a quick summary of your sketch on Cake Wrecks?
And then let's open this bad boy up and explore how this phenomenon affects where John can often be found in the world of product development.
Jono Hey:
Yeah, for sure.
I mean, I really like the idea of Cake Wrecks.
And so there isn't honestly much in the sketch other than drawing what counts as a Cake Wreck.
And Cake Wreck is a term from Jen Yates, who I think she had created a blog of these examples of these ridiculous cakes, where essentially what had happened was people are given an instruction for a cake and what they like on the cake, and people had read the instruction and interpreted it very literally.
And so you end up, so the sketch has one, which is, you know, it says Happy Birthday across the middle, and then underneath it says in purple, common no nuts, which is obviously not part of the description for what was supposed to be on the cake.
But you can go look, and she's got a tonne of other examples, some some brilliant ones, as this one which just says nothing across the middle.
There's another graduation cake that says I want sprinkles on it.
Tons of examples of where basically people have tried to communicate what they want, and they've given it to somebody, and they've got back a very literal interpretation of what they they asked for.
You know, say, what do you want on the cake?
I want nothing, please.
That's what they got.
And I learned about cakewrecks from a really useful book I like.
We use a story mapping by Jeff Patton, and he gives it as an example because it happens in software development a lot where you're trying to build a product, and so you're trying to decide what it is where you should build, and this is what should happen.
It takes usually a lot longer to build the thing than it does to write down what it should do.
So you say, okay, this is what it should do.
And then there are various models of software development.
Very often, what will happen is that at some point, that will pass from somebody who knows the context really well and has written it down to somebody who's going to build it and maybe doesn't know it quite as well.
And it's a common example of taking something very literally from what was written when you didn't exactly necessarily mean that or whatever.
And so that's the example where I know it from my day job, where so many times you've written something down, let's say, and then you thought it was clear, but it turned out not to be clear, and somebody interpreted it that way.
But Cake Wrecks is this really concrete, brilliant example, and they're very funny if you go and look for them.
Rob Bell:
So Jon, how common a challenge is this in your observations, would you say?
John Cutler:
Oh, it's extremely common.
And it happens in many different ways, too.
You know, people are encouraged to talk to customers, and you talk to a customer and they say they want this, and the team will go off and dutifully build that, and the team won't pause for a second to think that maybe the person who asked for the thing hadn't really fully thought it through about what they were trying to accomplish or what they were hoping to achieve in the long run.
And that's not a fault of people because people in general aren't great at giving descriptions to people about things, about products that they want, you know.
So a good example of that is that someone will say, you know, I need a way to see all the rows of my accounting line items.
And they'll say, I just need to see 100 more of those on the screen.
And you'll dutifully add 100 more of them.
And what they're actually trying to do is they're trying to scan down and find the ones that match a certain characteristic.
It's just a lot easier to view them all.
And I remember being on a team that did that, which thought they had found that if you ever use a product and it seems sort of limited to 50 rows, like your email, you have to press another button to see 100 rows.
You know, we switched it because everyone said we want to see more rows.
We might have saved them a tiny bit of time, but they were still mired in trying to select all the things they wanted to delete or something, right?
And typically, we're not very aware of how we're using the things that we're using or why we're using them in the way that we're using them.
An example recently that was very interesting is a product designer reached out who's trying to decide on how to build something.
And they said, you know, you're in a room and the music is extremely loud.
And you have an option on how you want to make the music get softer.
You can have a physical knob.
You could do it on your phone or you could do it in voice control.
And then they asked another question, said you're in another room and the same thing happens and the music is loud in another room and you want to do it.
Would you use the same tools?
Now, what was funny when I first looked at it, I was thinking to myself like, well, of course, I would, of course, I would want to use my phone for that.
I would, let me, let me turn down the speakers in any room like with my phone.
And then I gave it a bit more thought because I've done this and you can sort of think through the edge cases of this and say, okay, I'm sitting there, slouched down in the couch.
I've probably lost my phone, nested inside the couch.
And if the music is really loud, typically when I move a volume knob, I want to get a very, it's a tactile thing where you're finding the perfect level.
Rob Bell:
Precise, yeah.
John Cutler:
And I thought like, well, voice is going to be hard.
Make it lower, make it higher, make it lower, make it higher.
You could just imagine sort of shouting at your volume control.
And similarly, the app, I would need to find the phone.
And I realized when I answered them, I was like, well, realistically, the physical knob for being in the room, because I want to find the perfect volume to balance my room, would be the thing.
Now, if I was in another room, I think I was correct in predicting perhaps that I would want to just be able to shout at some system, turn that fricking music down, and then it would just cut it in half and it would be the right volume.
So it seems like such a trivial thing, but there's some designer out there from some speaker manufacturer who's obsessing about building AI voice-activated, phone-activated controls for the house, and someone's told them, well, of course, I want to use the app for that, and that's why these apps to control your whole house are what they are.
But you wouldn't really know, and it took a little bit for me to think it through what I would actually do, and even then, I'm probably wrong.
Even then, I'm probably mischaracterizing what I would want versus what I would actually use, because I've got plenty of gizmos in my house that seem to...
Look at all the buttons on a remote control.
I only use 1% of that.
It was literally turn the thing on or off, but how many product designers have added the one more button to the thing because someone said that they were going to do something with it?
These are the analogies we think about a lot in product.
Rob Bell:
That's really interesting because then it becomes very contextual, isn't it?
And by that, I mean the context of whatever project this might be, the project of your limitations and constraints, maybe time and budget, how much time have you got to produce a prototype, do user testing and then come back?
Or does this just need to get done in the quickest time possible?
And similarly, I think that a challenge is also about the culture of communication and whatever that is within a project team on something like this where for whatever reason out of respect or hierarchy, maybe you might be afraid to ask too many questions or you might feel that you might come across as incompetent.
And I think that that does become a cultural thing within a team, does it?
John Cutler:
Oh, a great example of that is my joke.
It's called the CEO's Significant Others feature request because they happen to be using the app in the car.
You know, it's kind of like at some point you're going to get this request, which is, you know, my significant other was using the product in the car the other day.
And they want to be able to see the full screen.
Yeah.
Whatever.
Something.
And you don't...
I'm just noting the political and power aspects of that particular thing.
You know, the customer who says that they promise to give you, you know, buy your product if you can just build this one thing, especially in software, the thing for folks to keep in mind is software is very mutable.
You know, it's very changeable.
And you can change it in a second for a lot of software.
I was using an audio product earlier today, and in the right nav, it said, we've updated the product.
Restart.
And so I restarted it.
And then 10 minutes later, it said, we've updated the product again.
Restart if you want to update it.
So that's how quickly you can update these things.
And so it tends to give this sense of lack of permanence.
And you can always sort of go back and try to fix your decisions.
Of course, people don't go back and fix these things.
They say they will, but they don't go back and fix it, which leads to, in many cases, pretty crappy products that a lot of us use.
Rob Bell:
This is really interesting.
And this feels like a really good opportunity, Tommy, to come to you because we talked a lot about how the supplies in the software world.
But actually, what you do, you produce hardware, right?
And manufacturing, to a point.
And often, the people doing your manufacturing aren't anywhere near you physically, are they?
So this does come down to communication, and it does come down to trying to be as clear as possible as to what it is you're after for your products, those prototypes, or for a production run.
Tom Pellereau:
Yes.
And I've had quite a lot of instructions or documents over the time that go inside a product.
Because when we make a product, we make three or 5,000 of them.
And when they ship, they're not easy to change.
And there have been instances where an instruction booklet or the backup pack will say, no text here, for example, because it's been forgotten to be taken out.
And it will still say no text there.
And communication to manufacturers is so incredibly difficult.
And as we've seen with this cake example, someone was trying to be really helpful by really clearly specifying exactly what they wanted.
But I sometimes find that you can over-specify, and then you end up with a cake which says in green or Helvetica or something like that.
So we originally had very simple instructions.
And I'll never forget an example where it was one nail file to go in one packaging.
But then our retailers, they'd want then six of those, six of those packs to then go in a little store case which gets delivered into store.
So we were like, so we specified six nail files in a pack times six.
So of course the manufacturer misread or maybe I'd missed a comma or clearly we hadn't provided enough photos.
And so we got delivered six nail files squeezed really tightly into the original packaging, you know, squeezed so tightly.
And you look at this going, in what way did they think that was, you know, how?
And then you reread the instructions and it's like, yeah, okay.
So these days, so we're launching seven new products in July.
And today, we've just finished the specification document for the final one.
And each of these documents is over 30 pages long now.
And because we have a physical photo of absolutely everything, of every stage of the assembly process, we then also have a link to a video for the showing of it.
Because we've just found that so many, and sometimes you get, you know, an early video will come back about them from the production line, and be like, how on earth did you think that we wanted it that way around or that way up?
And it's like, well, clearly, we just weren't clear enough in our things.
But yes, in the physical world, in the product world, when we're making things at scale and in volume, it's quite amazing how often little things can cause this issue.
And that's just the manufacturing side.
It's a whole other game, which will come back to the other side, when consumers receive it and they start reading the instructions and they misuse it.
But yeah, it happens a lot.
Rob Bell:
So Jon, do you have advice, like a suite of advice of how developers and people working in projects and teams might avoid the cake wreck phenomenon?
John Cutler:
The key thing is to get something into your hands that you can feel and test your understanding over and over again.
The story reminded me of Stonehenge, by the way, the 11-inch Stonehenge.
It's probably the classic example when they are going to...
So in Spinal Tap, the movie, it's a heavy metal band, and they have an act involving Stonehenge that they want it to make like the 11-foot Stonehenge that the little munchkins are going to dance around as part of their live show, and then they don't put the ticks the right way, so they make an 11-inch Stonehenge.
It's a good video for people to check out.
We'll probably link it.
Rob Bell:
I will find that somewhere, yeah.
John Cutler:
But it does seem like it is about getting tactile and testing the understanding over and over again.
You can't just rely on the written word, and the visual world helps.
Certainly when I was involved in music, if you tried to describe in words, I want you to play that chorus like a little bit, whatever, it didn't make much sense until you heard it or showed someone what they were doing to play with those things.
So imagine the cake wreck thing, it would be, imagine if the person in the office had just quickly sketched out a cake, and they wrote the cake thing on it.
That would have been addressed fairly quickly if they had done those particular things.
So I think that that's sort of the key.
For a while I was a UX researcher.
Part of my role was doing a participatory design with customers where we were actually designing together.
Rob Bell:
UX, meaning user experience.
So that's the interface that the users will have as they try and go through it.
John Cutler:
Yeah, and we would do an activity with customers was more participatory design, which was to involve them in the design of the thing.
Now, frankly, they typically weren't very good designers.
So we sort of throw away what they...
Their solutions often weren't the best solutions, the best design solutions to the problem.
But the act of designing alongside of us and drawing with us gave us much better insight into what was really, really happening.
And so, you know, I always remember examples of where, you know, they sort of would draw something kind of clunky that would never really work in an interface, but it really helped you see what their real need was when they drew it out.
So, you know, drawing things, making it visible or audible or playacting the thing to make it real.
Those are things that we can do to prevent that.
Tom Pellereau:
We make so many prototypes of everything.
You take pictures of the prototypes and you...
We have a weekly team meeting where it was like half an hour.
We're just checking with everyone that knows what's going on.
Because there's just so many things that can go wrong.
It's unbelievable.
Rob Bell:
Do you see this, Jono, as well in your work?
Jono Hey:
Yeah.
I often describe the process of product demand as going from very low fidelity to very high fidelity.
At some point, it's going to literally be ones and zeros in a computer running this stuff.
And it's going to do the same thing every time if you give it the same input.
And at the beginning, you've got an idea like, it needs to be easier to use, or I need to be able to do my finances with my spouse together.
And they're really sort of vague ideas.
And so along the way, you have to shape it and give it form in order to get to something where you're like, we can make lines of code that are going to do this thing, and it's going to be this big, and it's going to sit on the screen at this point.
And this is where people are going to click.
And when you click, it's going to do this.
But to get there, you have to give it form all the time, and so you're trying to...
You do this kind of...
We often do this bouncing around.
Yeah, you put like, what if it's like this?
And then, of course, that doesn't work.
And so you have to be like, it's okay that it doesn't work.
What does work about it?
What do you like about it?
What don't we like about it?
Let's take those bits.
What can we learn from it?
And so you're sort of bouncing around like that.
I often think about it.
You've got like, literally, it might be one word.
I gave an example in a previous one, like, we need to make a pension.
And then I go, what is that?
It could take a million forms.
And so at some point, you're going to get it to, it's going to be exactly this in all of these ways.
And so how do you get there?
Making a lot of stuff, in one way, maybe the best way.
Rob Bell:
Are there any other facets of this cake wreck, Norman and Jon, that scream out to you, that you've seen and observed in a lot of the companies and projects you've worked on?
John Cutler:
Well, I think one thing is trying to force language to mean the same thing for everyone.
There's a difference between agreeing...
Rob Bell:
That's good...
John Cutler:
.
on everything and then generally being coherent about what you're trying to achieve.
And so what you notice sometimes, especially when people do written specs, is that they're trying to all agree on what everything means.
They're trying to align on that thing, but then they lose the real coherence about what the goal was.
And so I think that that's one thing that I've noticed.
The other thing is that people describing things in different ways is diversity.
It's part of what makes things special.
And so I think people, you know, when they're writing marketing copy or they're writing things like that, they sort of try to get everyone to agree on the same.
They want people to agree on the same articulation of the thing.
A great example is I used to do a type of research with customers when I worked at a company and I was trying to understand how they perceive the brand.
So I would say to them, insert the name of the company is a car brand.
What car is our company?
And some customers would say, at the time, it's a Tesla.
It's the most modern thing I've ever used.
It's the best.
And other customers would say, well, it's like that stable Ford truck that we have.
And what's interesting there is you can imagine as a company, you tend to want everyone to get agree, but realistically, one group of people described it in a different way than another group of people.
And so I think there's a lot of things where we imagine we're just going to write it up and everyone's going to agree.
But even within your company putting together a product, people might have very different ways of describing something, or very different ways to describe the essence of something.
And so maybe embracing a little bit of the incoherence is something that you can think about.
You don't need everyone to use the same words all the time for everything.
Rob Bell:
As you were saying that, the question that was forming in my mind was individuality of perspectives and interpretation.
Is that something that should be embraced within a project?
John Cutler:
Well, and I think especially when you're trying to tease out the different edges of different perspectives, I mean, we call it premature convergence.
You could imagine there's premature convergence and then there's like endless divergence.
You know, if you diverge endlessly, you'll never get anything.
Rob Bell:
Uh-huh.
Yeah.
John Cutler:
And if you prematurely converge on things just to agree, you'll probably end up, you'll sort of settle with some approximation or average of the different ideas that were involved.
And you might not have explored all the different strands and threads of the particular thing, which I'm sure Jono actually probably has a drawing that explains this pretty well.
In a lot of corporate cultures, there's such pressure to converge quickly to move on.
And you sort of, you end up with a mediocre solution.
And I'll give you a very, very specific example.
If you are in a family and you have a significant other, you know this problem of scheduling things.
Rob Bell:
Oh yeah.
John Cutler:
And it's a little bit like, do I put it on my personal calendar?
Do we have a shared calendar?
What if I wanted to put it on your calendar, but not my calendar?
What if I want to just assign Jono to go out and get milk, but I don't want to do anything?
What if I want to be busy?
What if I don't?
Where do we put the doctor's appointments?
Where do we do all those things?
And so you could imagine a team of people sitting there and just saying, okay, here's the problem everyone.
The problem is like, how do people do this?
And someone would say, shared calendar, you're gonna use a shared calendar.
That's not really what people want.
So if you didn't diverge into all those edge cases, you wouldn't necessarily, you wouldn't end up at something that really, really solved the problem of what it means to have people collaborating on their schedules with kids and things like that.
So that's just one example.
Rob Bell:
That's a very good example.
It's a very relatable example, John, I have to say, I'm sure for many of our listeners.
Jono Hey:
I can think of just, I've got more specific examples where I've had in software development, where I always think you want the best of every skill set in the team and what can often happen is somebody says, okay, we figured it out, we're going to do this.
And then somebody else is goes, okay, fine, we'll do that.
But what you want them to say is, well, looking at it, I think I like that, but I would do it this way.
And you want them to be at that space to bring their ideas to it.
I really distinctly remember, it was quite, it wasn't early, but it was like 2010 or something.
So we still had like browser compatibility issues and stuff like that.
And I remember we created some designs which looked great.
And then one of the developers kind of made it work, and another developer was like making it look exactly like the designs.
And we learned the next day, it basically stayed up all night long, trying to make it look exactly like the designs.
And you won't know this, but there used to be a time where if you wanted a button with rounded corners, you had to like divide it up into like a nine by nine square, and then you had to have an image in the top left and an image in the bottom left, an image in the bottom right, an image in the top right, an image at the bottom where you wanted a shadow.
And all of that was ridiculous stuff.
And that was what was in the design.
So this guy spent all night long trying to make this happen.
And all he had to say was, guys, there's some rules we can do and it will come out kind of like this.
And actually that would be like so much easier and it'd be much quicker to load and everything.
And we didn't know that and he didn't tell us.
And at the end of the day, you're like, oh, but then you're like, it's done and now you can't change it.
And so there's all these things where you want to get that collaboration, but you still have to write down what you have to go, what do I want?
I want this.
But then they need to be able to look at it and say, you want that, but I would do it this way.
And then you need to have that room for flexibility.
And it's tricky and schedules don't always allow it.
And people don't always feel comfortable saying it.
So yeah, there's lots of challenges, but definitely the best works when you get everybody's experience in there.
You can have a situation where everybody thinks they understand and everybody says, yeah, no problem.
Yeah, that's fine.
And nobody sees any issue because but they've all agreed to slightly different things.
Tom Pellereau:
And actually, they've all seen a different thing in their brain, right?
Yeah, everyone's seen a slightly different thing.
Yeah.
Jono Hey:
So you sit there and you have a discussion like this is what we want to do.
And everybody says, yep.
And they all came away with a slightly different idea of what it is that you wanted to do.
And you're like, okay, well, he didn't have any questions.
So I guess they must understand exactly as I do.
But that actually wasn't the case.
And I've seen that happen so many times.
And to my shame, it's happened to me a million times.
And I'm like, yeah, no matter how much I try to avoid it, people say, yep, no questions.
I know exactly what I'm doing.
And then it turns out it's different.
Tom Pellereau:
Rob, if you're possibly trying to bring this together, as this is Sketchplanations, the podcast, I'd say often the solution is to draw a good sketch.
Certainly, the Cake Wreck would have been solved if that person just drew a little sketch.
And I often find that people are like, oh, I can't draw.
I've got to write it.
I can't, everyone can, every five-year-old draws, every eight-year-old draws, you know, we just sort of forget to draw, I think, as we get a bit older.
And there's so often where you can just draw something on a bit of piece of paper, take a photo of it, and send that off.
And that can save an unbelievable amount of time.
Rob Bell:
I do feel like our old friend Hindsight is maybe rearing his head here as well, slightly.
Which is probably a fairly common aspect in your observations as well, I imagine, Jon.
Because as an observer, you are watching the reality play out in order to come to some kind of conclusion.
And you go, oh, well, that's where that went wrong.
John Cutler:
It's funny, just this morning, I heard someone frame something that is already swimming in my head.
And we were talking about this phenomenon in tech companies when you have to migrate from one tool to another.
We call that a migration.
You're going to migrate to a new tech stack, or you're going to migrate data, or you're going to do something like that.
And it basically means you're going to use the new thing.
And what we were talking about is how funny the word migration is, because it's taken from birth.
It's taken from migratory things.
Yet, we perceive it as this gap.
We're going to take it from this, and we're going to get it to there, and then we're going to be done, and we're going to have migrated.
And certainly, that is like some forms of migration or like that.
But they were challenging me to think about it as migratory.
We're just moving.
We're shifting our understanding as we go along.
So I think that people in organizations, you'll have many opportunities potentially to revise this and to improve on what you're doing and get better at it.
So I think that that's a little bit of it as well as sort of adopting the mindset that we're fragile in the ways that we're fragile and we're short sighted in ways that we're short sighted, we miss things.
And it's not necessarily the gap all the time getting to the other side.
There's a little bit of the, it's called the ideal present.
You know, it's like, how can we make what we're seeing and experiencing right now a bit better all the time?
And so I think that that's, that's something that, you know, depending on the industry you're in, you may or may not be able to do.
I remember in recording music, there is a certain point when you'd have to put it on a CD, you know, and whatever, a record or vinyl or do whatever.
And that was a pretty harrowing point.
But at that point, you've heard it so many times that you never wanted to hear it again.
And so you're sick of it, right?
And so I think that, but with a lot of the things we do in work and with digital stuff, you know, it really is something that's going to evolve for a while.
Rob Bell:
In life generally, I'm always really motivated when I hear someone talk with real passion and real expertise and knowledge.
And especially when it's in an area that I'm, I'm not that knowledgeable about myself.
So thank you.
I've got a lot of energy now, which is slightly annoying because it's my bedtime, but that's cool.
I will figure out something to do with it.
Jono Hey:
That happened last time I chatted with you, John.
I didn't sleep for hours.
I was just buzzing with ideas.
It's terrible.
Have that effect on people.
Rob Bell:
If anybody's interested in hearing or reading more from John, you can subscribe to his newsletter and your podcast.
Is that right, John?
The Beautiful Mess.
John Cutler:
I'm experimenting with that.
That's, I just shipped it and we'll see what happens.
No, my attitude with this content stuff is just ship it.
Rob Bell:
Good.
John Cutler:
And I was the same thing with songwriting.
I couldn't leave the room until I at least had a version of it that I could put in the car.
So it was the same, yeah, just ship it, just ship it.
Rob Bell:
Get it out and then feedback, you can either take on board or ignore.
That is the beauty of creation, isn't it?
But yes, The Beautiful Mess is the name of John's newsletter and podcast, so you should get in there.
And I should say as well, if you just Google John Cutler, you're spoiled for choice on the amount of videos and podcasts that you've appeared on, John, and conference talks that you've given.
Each one is slightly different haircuts, I have to say.
John Cutler:
Yeah, well, the good one too is Google Images.
If you go to Google Images and type in John Cutler something, you'll see I like drawing, so I'm a fellow sketcher, but not, I'm a diagramer.
I'm not a, I don't do stick figures all that well, but there you go.
Rob Bell:
This is the prolific content creator we were talking about.
And Jono, is there anything that you've got coming up that our listeners might want to look out for?
Anything you want to plug at all?
John Cutler:
Subscribe to the newsletter, and then, yeah, stay on the lookout for the podcast.
Rob Bell:
Get online, seek out the newsletter and the podcast, The Beautiful Mess by Jon Cutler.
Jon, thank you so much once again for coming on.
Very enjoyable conversation.
Jono Hey:
Absolutely, thank you, Jon.
Rob Bell:
Don't forget, we'd love to know what you have to say about any of our discussion in this podcast, and you can send your thoughts, stories, and experiences to hello at sketchplanations.com.
But as we close out this installment, I'm left with a very difficult decision.
As I edit this recording, should I underline important sections in green or in red?
Tom Pellereau:
Green, obviously.
Rob Bell:
Thank you all for listening.
Until next time, go well, stay well.
Goodbye.
Tom Pellereau:
Goodbye.
Rob Bell:
All music on this podcast is sourced from the very talented Franc Cinelli.
And you can find loads more tracks at franccinelli.com.
For any new listeners, we thought it might be fun if we highlighted one favourite episode each. Guess who picked what...