Navigating the Fog: Embracing Uncertainty in Product Delivery

Martin Reilly at UXDX Community: Product Development in High Growth Environments - Dublin. Video: https://youtu.be/_S8xZ5XMFkk

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Two types of uncertainty

[00:00:01] Hello. The topic that I am going to tackle is uncertainty, and uncertainty is usually defined by ignorance. The first thing to know about it is that it's probably an awful lot worse than you think it is, for two reasons. Firstly, it's difficult to know what you don't know. And secondly, people are uniquely set up to try and avoid uncertainty. It's uncomfortable, we don't like it, so we tend to minimize it and we tend not to see it. So we'll delve into the two types of uncertainty.

[00:00:39] The first is this problem of knowledge, of the past and of the present. You have things like the market, your customers. You have problems with knowing what your team is capable of, what your budgets are. And then within those, even if you do get the information, often it can be overwhelming or it can be inaccurate, and it's difficult in a lot of companies, as we've heard earlier today, to get the time to do research as much as people would like. So you're always dealing with this problem of poor information and uncertainty of what's out there.

[00:01:19] And the second problem is that the place where you are trying to launch your product is all the way in the future, and between now and then no amount of research can help you, because you can't research the future. So you've got all of the randomness, chance and volatility of the marketplace, and then you also have changes within your team, and also the changing knowledge as you evolve through product development.

Antifragility

[00:01:43] This is the only concept, hopefully, that I will introduce here, and some of you will be familiar with this idea of antifragility. It's the property where some systems gain from disorder and chaos. This is an economic principle, we're going to loosely apply it here.

[00:02:03] There are three types of system you can think of. Fragile systems, like a glass of water on a table: disturbance and chaos, not so good for that. Robust systems, like a football: you can kick it around, it's still going to be a football, it can take an awful lot of punishment. But then there's this third type of system, which is things that gain from punishment, things that gain from disorder and chaos. Economic systems tend to be like this, that's why an economist came up with it. But you can see this in product development, and I think I have seen this in the teams I have worked with that tend to work best in these uncertain circumstances.

Tinkering, not strategy

[00:02:42] We're going to talk about five approaches that a team could take to try and move forward through uncertain times. The first is tinkering, not strategy. The problem with strategy is often that it has to predetermine outcomes. Usually when you use some type of strategic framework you're trying to get inputs into the framework that will help you to come up with outcomes that you can then aim at. It tends not to work in these uncertain circumstances. Incremental trade-offs tend to work better than big solutions, because they allow you, as you move forward, to integrate this information into your evolving concept of what the product is.

[00:03:33] This is very much, I think anyone who's an engineer here will recognize this way of working, it's sometimes called the engineering method. I'm a designer, so we tend to want to do research and then come up with a hypothesis, and we won't put pen to paper until we have a good idea of what's going on. But that's not exactly how engineers work, and the engineering method versus the more scientific, quote unquote, method can be much more useful for these uncertain circumstances.

[00:04:01] The area I work in at Toast is the fintech area, and one of the problems with fintech and doing research with customers is that when you ask people what they want to do with their money, or what they would do with their money, it's very different from how they actually use their money and spend their money and think about money. People tend to use their money with their lizard brain, and they imagine an angel of themselves when you ask them what they might do with it.

[00:04:31] That's another reason why these frameworks can have their limitations. Strategy frameworks are great, you should use all of them. I have used any amount of them. Whenever I see a new one I immediately try and implement it: playing to win, jobs to be done, personas. All of these things can really help, but there are limitations because they require knowledge, and without knowledge what goes into them is assumption, and that can bake too many assumptions into your product.

Optionality, not planning

[00:05:00] The second one to talk about is optionality, not planning. Planning can sometimes pretend at certainty, because when we're in uncertain situations we love to try and get all the pieces together and try to wrangle the uncertainty out of it through some type of planning process. People like to do that, it's a tendency of everybody, but it has this issue: in these uncertain circumstances, when you embed these tools and structures you tend to end up with an entrainment effect, and it ends up making you more fragile and less able to adapt. In this antifragile thing, the parts of the system need to be able to break and be replaced and change and come together in order for the thing to move forward.

[00:05:51] The best example, or best analogy, I can give is the difference between when you're trying to get somewhere and you have to take several modes of public transport. If you've got to get a tram, a bus and then the train, which people in Dublin will know all about, this multimodal thing, as soon as one piece doesn't work, especially if it's early on, then the rest of the plan is gone. It's too rigid, especially in uncertainty.

[00:06:18] Whereas that's why people tend to prefer cars, sorry planet Earth. Cars give you an awful lot of optionality. You can choose when you're going to leave. If let's say you run into traffic, you can pull in, you can have a cup of coffee, you can turn what would be adversity into some type of advantage, and it gives you far more options. People with children especially will know this, about being able to fill your car with all the stuff they might need to entertain themselves, versus taking three kids on a bus.

[00:06:49] And of course optionality is the huge advantage of agile, and that's why it gives you enough structure that you can be flexible within it. That's why attempts to put something over agile to try and contain it tend to not really work, and I think most people here have seen various versions of that, where you start off agile and it gets more waterfall as time goes on.

People, not process

[00:07:18] So the next approach you can use is to focus on people and not process. Process is very bad at accommodating new information and uncertainty, especially formal process. Informal processes tend to increase the speed at which you can make decisions, and sometimes you need to make decisions quickly. Process can really hold you up.

[00:07:46] The best example I have of this is probably working with legal and compliance in the fintech world. When I started off in Toast, working with legal and compliance, we would have these large documents where we would make comments and we would respond and we would do revisions, and it was all very asynchronous and it took forever to do anything, especially if you had structural change. It's great if you want to change a line, but if you have a new idea about the way we should do it, it's very poor at that. Whereas as time has gone on and we've become more familiar, that process has been able to be broken down, so that essentially we just set up half an hour, open up Figma, and then everybody has at it. It looks an awful lot messier, but the result is an awful lot cleaner in the end.

[00:08:32] The other thing is that it's far more likely to be more like the tinkering that we talked about earlier than it is like strategy. This is also true with top-down decision making. If you ask high-up decision makers to make decisions, they must by necessity be categorical, because they only have so much time and they're not familiar with all the trade-offs that you are trying to make, and that's often where you can run into issues.

Simplicity, not complexity

[00:09:03] The next approach you can use is simplicity, not complexity. Somebody said before that complexity is a trap for clever people. I think most people in here can probably recognize this in themselves, where you want to be really good at your job and you want to impress people and you want to design something that's cool and build a product that's great, and so you think bigger and better, and you want all of the outcomes to be in the first draft. This can be a trap that people can fall into by trying to do the right thing, but ultimately it doesn't really work out.

[00:09:43] I'm sure people are familiar with this, they probably read it in all types of agile books: all complex systems that work evolve from simpler systems that work. It sounds trite, but there you go.

[00:10:00] The best example of this I can give is the idea of the sandwich, everyone's favorite form of meal. I can almost guarantee everybody in here that the most interesting meal they've had in the recent past has been a sandwich, and it usually comes from only having bread and then whatever else is in the kitchen. The simple structure of the sandwich seems to allow people to make unusual meals for themselves that they wouldn't otherwise cook, and that's because that familiar structure seems to have the space within it for innovation.

[00:10:36] You also tend to see it in restaurants. People start out a new concept as a sandwich shop, and I think especially in Dublin in the last years a lot of the innovation in food is in various different types of fusion food contained within two pieces of, sometimes, bread. So products are very similar to that, and that's why the MVP is such a good concept. It's not just that it's faster, it's that within this familiar framework a team is able to create something novel, because they don't have to worry so much about all of the other things around the periphery.

Minimize the downside

[00:11:13] And then this point is the last point, and I think it's the most pertinent point. If you're going to do this antifragile thing, you're going to try and create opportunities for yourself and for your team. That's the whole idea of the optionality and the tinkering: you're trying to, within uncertainty, create opportunities for your team to grow and learn their way into your product. But the real downside of it is that it increases risk, because you end up launching things that might not work or that might annoy customers. So it's really important that you try to think negatively as much as possible about your product. You're trying to keep the upside that you create but minimize that downside.

[00:12:01] The best example, my favorite example and favorite restaurant actually, is McDonald's. When you go to McDonald's they are not trying to provide you with haute cuisine, they are not trying to wow you, they are not trying to provide the greatest customer experience ever. They try to provide the customer experience that they can scale, and the thing that they promise you is that it doesn't go below a certain level. You're never blown away, but at the same time you're never completely disappointed. You can go to McDonald's anywhere in the world and be almost guaranteed a Big Mac, and that's part of their strength.

[00:12:43] Sometimes you need to sacrifice, when you're creating products in these uncertain times, the wow factor for a somewhat more consistent and boring experience. And when you try to minimize those negative things, that's sometimes the effect, especially at scale, because mistakes can actually knock you out of the game, they can annoy customers. If you have a product that absolutely wows and delights 10% and completely annoys 5%, that's an awful lot of calls you're going to have to deal with, so this can be a problem. So those are the five approaches, and thank you very much for listening.

Q&A

[00:13:32] Host: Do you apply the same approaches to scenarios involving uncertainty as to the scenarios that lean more to ambiguity?

[00:13:39] Martin: I don't really know the difference between uncertainty and ambiguity in this case. I think I'm talking about the same thing. You could put ambiguity under uncertainty. Someone could clarify their question. I think people tend to use the word ambiguity a lot for the same thing. That's a bad answer.

[00:13:57] Host: This one, yeah. Can you back up this claim, that embedding processes, tools and structures to reduce uncertainty makes you more fragile? Personally, working with or without OKRs, I'll take OKRs for accountability. So they're very opinionated about having your OKRs.

[00:14:12] Martin: Yeah, I mean, I think that's partially just the way that I set up this talk, that it's hard to make equivocations when you're trying to make slides. So obviously you do. I'm not trying to say throw out all the structure, get rid of planning, let everyone do what they want, live your best life. Nobody really wants that. You do need OKRs, but there's a difference between an OKR that is an actual business metric, like sales or revenue, and an OKR that's just people who clicked on a thing. You can really go down the rabbit hole when it comes to creating OKRs, I think, and lose sight of what you're there for.

[00:14:50] Martin: Just by show of hands, how many of you have an OKR dedicated to your craft, design, research? Can't see anything. Let's go with ten hands. How many of you wish you had an OKR tied to design, research, UX? About double the number of hands. Okay.

[00:15:13] Host: I feel like OKRs sometimes split the room. Some people are really loving them, some people hate the process because then there's even more planning. I'm doing OKRs right now for January and I'm like, no, could we just wait? But then I also don't like OKRs. So let's talk about this one. How do you identify casualty in a scenario of uncertainty?

[00:15:36] Martin: Causality. Causality.

[00:15:38] Host: Causality, in a scenario of uncertainty. I said casualty. Death.

[00:15:44] Martin: We can get data, but most of the time we can't identify cause and consequence. Again, it's down to trying things. If you can't identify the cause, just try, you just remove something else and see if that, it's a kind of a process of elimination at that point. Sometimes you launch products and people don't like them for reasons you can't quite get your handle on. Changing something else often gives you the reason.

[00:16:07] Host: But trial and error. Say again? But just trial and error.

[00:16:12] Martin: Yeah, I mean, trial and error is really useful, it's fast. I'm not saying don't do research, do the research for God's sake, but trial and error can be very fast and it can allow you to get to the quick of something.

[00:16:26] Host: Nice. I've recently heard a story about a couple of really famous YouTube stars who put out a different YouTube channel for every idea they had, and then whichever one stuck they made more content for, and now that person is the most paid YouTube channel in the world. Mr Beast.

[00:16:42] Martin: Mr Beast.

[00:16:42] Host: So it wasn't like there was one amazing idea from day one and it just blew up to a billion. It's just 10, 20, 30, 40 different ones, and one of them became the entire thing.

[00:16:54] Martin: I really wish I had that story for my presentation.

[00:16:56] Host: Right, yeah, pay me billions of dollars for my A/B test. All right, so how do you keep your team motivated when your vision or roadmap might be uncertain? Is it harder for delivery teams to stay motivated during uncertainty?

[00:17:08] Martin: Yes, absolutely it is. And it depends. Sometimes it depends on the temperament of the team. I know individuals have temperament, but the temperament of a team in general can really affect it. Some teams absolutely hate working like that. I've been very lucky that, especially in my job, and in previous jobs, I've gelled with teams that were kind of in the same vibe. I don't know, vibes is a really stupid answer to any question, but yeah, it tends to be very difficult with certain teams, and then some people just don't care.

[00:17:51] Host: Nice. How do you identify a product that can be antifragile as opposed to not?

[00:17:57] Martin: It depends. If I think of the recent past, say I'm working on the financial reporting that we send to restaurants. It's not so much a product, but it is kind of a suite of things, a suite of applications that we show them, and that tends to be very, very quick to iterate on, very fast to change. And also it's really boring for many other people in the company, so you can make changes and people are not like, hold on a second. So you can tinker a little bit more in those darker corners where people don't want to read all the financial statements of a restaurant. It's not very exciting to them, but to a restaurant it's obviously one of the most important things they find.

[00:18:40] Host: Yeah, okay, nice. Let's take one more question. So we've already gone through these questions. Have you personally sold trial and error to senior executives?

[00:18:56] Martin: I mean, this is what all of us are... you can't really sell them trial and error. That's a kind of a show, don't tell thing. I think that executives love success. That's the thing about them. So if a team is being successful and launching products, they tend not to wonder about the detail too much. They don't really want to be walked through the Mural board a lot of the time. Even though you have the link ready and you think, oh, now's my time, I'm going to show them how clever I am, and they never want to see it. That's from my experience.

[00:19:33] Host: I totally agree, and actually I'd be more concerned if suddenly my CEO pops up in Figma or in Miro. I'm always like, everyone stop clicking on anything, it's the worst thing in the world. No, this is a draft, rename every file draft, suddenly this is not finished, don't send this to the board, don't put this in front of any head of advertising anytime soon, delete the boards, move to a new file. I always wonder if at Airbnb the designers freak out because the CEO is a designer. Do they just get full-on mockups sent to them and they're like, hey, couldn't this be your roadmap, and they're like, why does he have Figma access?

[00:20:04] Host: No, but anyway, enough of me making jokes about sponsors. Let's talk about one last topic. What is something that you wish you could do differently in the last six months of Toast?

[00:20:19] Martin: In my last six months at Toast, I'd probably do it all differently, I suppose.

[00:20:23] Host: But you had uncertainty before, right, and now you have some certainty about some things.

[00:20:30] Martin: It's very difficult to say. I think I would probably take on fewer projects and do fewer things. We do have an awful lot of freedom at Toast, which is nice, but sometimes you can get excited, everyone's got lots of really cool things that they want to work on, and you want to work on really cool things, and often you don't end up putting your all into it.

[00:20:52] Host: So much to juggle then.

[00:20:53] Martin: Yeah, exactly, that's probably the thing I'd do.

[00:20:56] Host: Okay, wonderful. Let's give one big round of applause. Thank you so much.