(This is actually not a transcript, it’s a script.)

Metaphor podcast script

Hi, this is Nils Davis, and you’re listening to All the Responsibility, None of the Authority.

In this podcast I answer the questions I and others have about the realities of product management, product marketing, going to market, and critical skills for business success like persuasion and influence.

My goal is for this podcast to give you the best mental models, tools, techniques, and secrets for creating value in the world, and delivering solutions to problems that need solving.

This is episode number 331, and as always you can find all the links I mention in the show notes at alltheresponsibility.com/331.

Metaphors

So, my launching off point for this podcast episode is the metaphors we use for creating new products, especially software products. I’ve always thought these metaphors are very interesting, the most commonly used one, especially because they are so misleading if you don’t use them right.

I’ll also share my favorite metaphor for creating useful products that people love, which is not all that much in use, but it’s very powerful. I didn’t come up with it, although I’ve added a few of my own twists, thanks in part to that great product management thinker, caustic chef Gordon Ramsey. I’ll explain that a little later.

Technically, a metaphor is defined as:

“a figure of speech that, for rhetorical effect, directly refers to one thing by mentioning another”

Of course, in common use we think of a metaphor as more of a cognitive device. A more cognitively oriented definition might be:

“A metaphor is a comparison that shows how two things that are not alike in most ways are similar in another important way”

In this usage, metaphors are a kind of mental model. You can take what you know about one end of the metaphor – the thing being compared to – and perhaps come up with insights on the other end of the metaphor, which is presumably your product, or your process, or your company, or whatever.

I was a math major, and metaphors remind me of a powerful concept in mathematics called an “isomorphism.” (Definition and example.) The thing about an isomorphism is that, in its nature, it’s highly accurate or trustworthy. If something happens in one end of the isomorphism, you can predict precisely what happens in the other end of the isomorphism.

Metaphors, although they are kind of like isomorphisms, are not mathematically accurate objects. Which means in practice that they break down. This shouldn’t surprise anyone, but it seems to me that in fact many people use metaphors in product management in a way that makes me think they don’t understand this fundamental problem.

Probably the most popular metaphor since the invention of software development as a discipline is the metaphor of the “software shop” as a factory. You hear this in lots of different forms. For example, the ideal of reusable libraries is compared to the idea of interchangeable parts, which of course is one of the inventions or developments that enabled the Industrial Revolution in the 19th century.

This is a beautiful idea because of what factories do:

They produce valuable things
Very quickly
And at high quality
They are very predictable
And are relatively inexpensive to staff, and in fact can often be automated by robots

But, this beautiful metaphor, when applied to software development, or in fact any product development, is also extremely disappointing, because it fundamentally misunderstands what happens in a factory doing mass production.

What a factory does is a copy function. Some factories can make variations in the copies, based on a few particular designs, and they can use different colors, but basically, the function they fulfill is *copying*.

And of course, in software development especially, the copy function is trivial. We can make copies of our software infinitely, as many as we want, with perfect quality, and we can do it literally as fast as the speed of light, if necessary.

The whole factory that’s used for manufacturing dozens of new cars per day is replaced, in the software world, with one command – “copy.” “Take this software I wrote and copy it and send a copy of it to the customer.”

Of course in 2019 we don’t even do that anymore. For many of our applications, the copy is virtual – when you log into the server, you basically get to run the copy of the application that’s already in memory, along with all the other customers of the application vendor.

So, in one sense, software development – part of it – *is* like a factory. But that’s trivial, and it doesn’t achieve what people are hoping for when they try to apply the factory metaphor to software development.

And to explain this, let’s talk a little bit about making cars.

Let’s assume Ford has decided it’s going to do a new car model. In fact, the major manufacturers refresh their car lines every three or four years.

It used to be four years, now it may be closer to three. That means that for three or four years, every new Ford Focus sedan has basically the same fundamental design – the same body panels, the same engine, the same undercarriage and suspension.

(I’m going to oversimplify a little bit in this example, but it’s basically accurate. And I don’t know if 2020 is a model year refresh for the Ford Focus, or if they are even still making the Ford Focus.)

There might be small cosmetic changes over the course of a style run of 3-4 years, they might change the paint colors on offer, they might upgrade the radio, or shuffle the various options between the different trim levels, but nothing major.

These Focuses are all built in one factory, or maybe a few factories, and those production lines *only* make Ford Focuses – they don’t make trucks or Lincoln Towncars – only Focuses.

And no matter what trim version of the Focus sedan it is, they can crank those babies out of the factory, dozens a day.

Then, after three or four years, there’s a new version of the Focus sedan. New body panels, new suspension, new lines, new drivetrain. (Although actually, even then, most if it isn’t really new – it’s slightly improved drivetrain, etc.)

Let’s talk about what Ford did to enable them to put out that new model of the Focus.

First of all, think of the new Focus model that’s coming to market in late 2019 – that’s the 2020 model, by the way. It’s a changeover year, where there’s new body panels, new drivetrain, etc. (I don’t know if this is actually happening this year or not – it’s a thought experiment.)

How did this happen?

Well, about three years ago – THREE YEARS ago – Ford started the planning and design for this new model that’s just seeing the light of day in late 2019. There’s first of all probably six months of planning and developing of requirements – what should this new version do or look like or say to the market that the current version doesn’t?

Once planning has been going on for a while the initial design work – prototyping and testing of new ideas – goes along. This might involve creating mockups of the car, including mules that can be taken out on the road to test new running gear.

They are not just creating working mockups to test the car’s engine and running gear, they are also designing how the new model will look. They might use a a clay model to test out their new ideas. That’s a car-sized piece of modeling clay that people model with their hands and with hand tools.

https://www.fastcompany.com/3045316/why-the-car-industry-still-builds-life-size-clay-models

When the initial design in clay is completed, the engineers transfer that design to their computer-aided design and computer-aided engineering systems. There they do more modeling, and often a lot of testing and refining of the design. The clay model, of course, doesn’t have any interactions, so they can’t be sure the doors will actually open correctly, for example.

That kind of thing can be tested in the computer-aided engineering models. Likewise for other types of interferences, and also manufacturability. In this stage they might also be focusing on how to reduce costs – the original body design might be simplified so some of the panels only require 4 hits from the sheet metal press instead of 5 hits.

How long does it take to design a set of new body panels for a changeover model? About a year. There are many complications that have to be handled, from “does it look good,” to “do these parts fit together well and can I still open the door?” to “does it conform to US and international safety regulations?” to “can we do it cheaper?” and of course, “can we build this?”

That’s the design part. What happens next? The manufacturing engineers have to figure out how to create those new body panels. Note that they have many knowns in this process. They likely know:

The material that will be used for the body panels.
The factories in which the body panels will be produced.
The metal forming machines – drop presses, robotic welders, etc – that will be used to make the panels.
The required duty cycles.
And, most importantly, they have 100s of person-years of experience in how to make manufacturing processes to produce body panels.

Just to let you know, the way body panels are created is pretty amazing. They start as flat sheets of steel. Those flat sheets are loaded into a series of giant punch presses, which contain multi-ton dies, which stamp the car panel into shape, punch out the various holes in the panel, roll over edges, create flanges, and so on. The goal is to hit the panel with a die only once in any location that will be visible.

So, as you can imagine, the design and manufacture of these dies is a critical part of the process of getting a new car to the showroom.

As I said, designing the panels takes about a year, then engineering and manufacturing the dies to create the panels (and fixing any problems) takes about a year.

So, those are just a few of the activities – there are lot more, like the new drivetrain, which may be only a slightly updated motor, or it might be a whole new transmission system.

Eventually, they shut the factory down for a week and install the new dies, equip all the machines with the new parts and jigs, program the robots to make the welds, and so on. One week – at least – of no production. (And, notably, they can no longer build the previous version of the car! It’s gone forever.)

This story is going on too long, so let me cut to the chase.

Building the cars in a factory is like our copy button. They are fast, but we are way way faster.

The part of car manufacturing that’s like what we think of as software product development is this three year slog to design a new car model, then building the manufacturing capability to create it in bulk. Which takes three years.

And at the end of it, you have a car with four wheels, an internal combustion engine, and maybe two extra cupholders.

While, in the same time, the software company has released new applications that potentially change every aspect of life, like a Facebook, or Amazon Prime, or Fortnite, or Slack.

In short, my summary of the factory metaphor:

“Feature factory” – this metaphor is dumb because in a factory, the cars (or whatever) are produced after a very long design period.
It’s the design period that is the equivalent of writing software. That’s the part of the metaphor that everyone is missing. I don’t know why this is, but it’s just amazing to me. People are not thinking these things through.

OK, so that’s the factory metaphor, hopefully laid to rest at least in your mind after this.

A much more useful and fruitful metaphor

Now let’s look at a metaphor, or really a family of metaphors, that is a lot more useful day-to-day for people building software products for people to use. I’ll give you a metaphor that helps you think about your product’s usability and functionality and a metaphor that helps you think about your organization’s ability to produce products.

Your product is a restaurant, serving fine food, and its service.

Your customers are patrons of the restaurant. They are here because some friends, or an online site, recommended it, or perhaps because they’ve been before and had an enjoyable meal.

Your user interface is the waiter and the menu. Think about the user interface of a good restaurant. When you enter the restaurant, you are greeted politely. If you are a regular, you might be welcomed by name, and at a very good restaurant, they might start preparing your preferred cocktail.

When you are seated, you are given menus, the waiter introduces him or herself, and usually asks about drinks (if you don’t have them already). The waiter might mention the specials at this point, or might wait until after the drinks are delivered. The waiter then rushes off to fetch your drink orders while you are perusing the menu.

Then, the waiter comes back, answers any questions you might have, offers to come back later if you need more time, and eventually takes your order. In the process of ordering, you might ask for slight changes in the dishes (mashed potatoes instead of roasted, extra vegetables instead of rice) and at a good restaurant these changes will be accommodated.

I’ll stop the narrative here, because we’ve seen enough already to start messing around with it a little bit. This is a normal, expected, and it sounds like, delightful dining experience. I hope these peoples’ dinner continues on like this, and that their meals are as pleasing as the experience.

Let’s see what this experience would be like if we turned the metaphor around, and said the restaurant experience was like the experience of using many software products.

You arrive at the restaurant, with a reservation, but it’s lost. It’s under a name you forget. So you need to reset the reservation. So, the restaurant has to text you a code. It takes five minutes to get the code. But you use it to reset your reservation – oh, but you used an illegal character in your password, but you don’t know which one it was. Or what the legal characters are.

Eventually, you get into the restaurant.

You’re seated. The waiter hands you, instead of a menu of exquisitely prepared dishes developed by a professional chef, a list of ingredients that you can choose from. Not a complete list, of course. And in fact, it’s up to you to figure out what you’ll be eating tonight – and how it will be prepared.

Unfortunately, the grilled T-bone steak with Bernaise sauce you decide on isn’t really possible because, well, the restaurant doesn’t support Bernaise sauce yet. That’s coming in the next version.

In the middle of ordering, another waiter comes by with a dessert menu. Oops! You dismiss her.

But you have to start your original order again because the first waiter disappeared when the dessert waiter arrived, and when he reappeared he had forgotten what you already told him.

And so on.

All of these are of course things that would never happen in a real restaurant, but I’m sure you’ll agree that they ALL have happened in software products you’ve used. And perhaps even software products you’ve released yourself.

But it illustrates why the restaurant metaphor is so powerful. You can think about something your product does, some part of the user experience, and ask yourself “what’s the analog of this experience at a good restaurant?”

This metaphor came to me from Alan Cooper, in his great book The Inmates Are Running The Asylum, about the reasons why most software and high tech products are so terrible. This is in a chapter called Designing For Politeness, about how software can be – and should be – polite. And he uses the metaphor of a waiter to describe 14 types of politeness.

I have created a mindmap for myself that lists out the 14 types of politeness, and I’ve used it to help me design polite features. I truly credit this metaphor for one of the coolest features I ever developed. I’ll link to this mindmap (in some form) in the show notes at alltheresponsibility.com/331.

But restaurants aren’t good only for politeness metaphors. They are also great for thinking about your capacity and capability for delivering solutions. And this metaphor arose for me from watching Gordon Ramsey’s Kitchen Nightmares series – the original one from England. Ramsey would go around to various failing restaurants in England, and attempt to fix them. And one particular restaurant really stuck with me. This restaurant, in the hinterlands of England, some small town or other, had a beautiful menu, filled with continental delicacies like Beef Wellington (which is actually English, I guess) and Veal Saltimbocca.

The problem was that if you ordered one of those, you got something terrible, and not really related to what the dish was supposed to be. There turned out to be two big problems in the kitchen. One was that the chef didn’t actually know anything about cooking fine cuisine. He just put these dishes on the menu more or less because he liked the sound of them. But the other problem was that the kitchen itself was broken down – burners didn’t work on the stove, the walk in fridge didn’t get cold, and so on.

Ever since then, I’ve thought about the metaphor of the “broken down kitchen” for software development. Obviously, the kitchen (and the chef) is like a software development team. There are two big lessons- if you have a chef who doesn’t know how to cook fancy meals, don’t put fancy meals on the menu. That is, don’t sign up to develop software that you’re not capable of building. You will surely fail. And if you have a broken kitchen, you need to fix your kitchen before you kill someone with salmonella. In other words, if your processes can’t produce quality software products, then you have to fix your processes before you can be successful.

Summary

Metaphors are obviously powerful for helping us think through things cognitively. I could say a lot more about both the “factory/car design/manufacturing” metaphor for product development, but I’ve already gone on long enough.

The kitchen/restaurant metaphors for software development are actually a lot more powerful and give you much better insights.

If you want to apply this thinking, here are some things you can start doing today:

If someone says something about “making the software development process more like a factory,” you now know a lot more information about what you can say to that person. Like, for example, “Oh, you want us to take three years to get a new version of the software out, like a car company? I think we can do better than that!”
Get the book The Inmates Are Running The Asylum, by Alan Cooper. I’ll put a link in the show notes at alltheresponsibility.com/331, but you can get it anywhere you buy books. This book has given me two powerful mental models I use all the time. The first is the 18 types of politeness model using the waiter, that I just shared. The other is the idea of “personal goals.” I’ve done some writing and podcasting about “personal goals,” and I’ll put some links to those articles and episodes in the show notes.
Download my mindmap of the 18 types of politeness, or ge the book and make your own mindmap, and start using it while creating your next feature. It will assuredly give you some good insights into how to make your feature more delightful, more responsive, and more engaging.

Outro

In the show notes at alltheresponsibility.com/331 you will find a links to the book and the mindmap and the episodes and articles I mentioned in the episode.

You will also find links on that page to subscribe to this podcast on iTunes, Stitcher, Google Play, Spotify, or wherever you listen to podcasts.

If you like this podcast, please consider rating and reviewing it on iTunes, or clicking the Recommend button in your podcast player (in Overcast it’s a little star on the episode). Your recommendations help others find the podcast, so it really helps me out and spreads the word. Of course, you can also share the podcast with your friends and colleagues directly!

If you would like to support the podcast, which I create totally out of my own pocket, with no ads, you are always welcome to support me via my Patreon, at patreon.com/nilsdavis. There are a few different levels, with different bonuss.

Until the next episode, this is Nils Davis for All The Responsibility, None Of The Authority. Bye bye!