Cringe Driven Development (CDD), a Template for Unavoidable Valuable Progress

Kevin McDonagh at UXDX Community: The UX of Career Building: Failing Forward in Tech. Video: https://youtu.be/MQnUPlBXUdo

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.

The U-1206 and cascading failures

[00:00:08] Hello. Thank you. Hi, I'm Kev McDonagh. I lead product at AppVelocity, and I am going to speak to you today about harnessing the power of cringe in your product with cross-functional interviewing.

[00:00:25] I'm going to start with a story about a submarine in 1945, the U-1206. These submarines, at the end of around 1945, cost around 50 to 100 million dollars. They took only eight months to get to production. They were really turning these out. There aren't many creature comforts on a submarine, especially then, and the most requested upgrade during this time was for the waste facilities. There was a model that they wanted to put out that they believed could stay submerged longer, because you had to come up to release the waste. But it was quite complicated. They came up with a really complicated method where you could have vacuum chambers that would release the waste into different areas and then out, actually while you were submerged. It was so complicated you needed a dedicated engineer to man the bathrooms.

[00:01:50] The story is that on the maiden voyage of the U-1206, Karl Schlitt, the commanding officer, the captain of the submarine, in its first few days at sea had used it once before, and he felt maybe a little bit overconfident. He felt like he got the gist. There are different stories as to what happened next, but you can now visit the U-1206 off Cruden Bay in Scotland with a scuba outfit, and you can go and visit the remains of it. What happened was that he got himself into a bit of a pickle, and then he called the engineer, and then he left, and the engineer was like, "Ah." The water all came out and it cascaded onto the batteries, which were below the bathroom. Then methane gas was released, and they had to quickly raise the submarine to the surface, and the Royal Air Force were just at that moment going above, and they bombed it, and everyone had to escape it.

[00:02:58] This, I believe, illustrates a challenge that all startups have. You've got to get your product to market. You've got to get out there fast, and there are compromises you're going to have to make. But those compromises have to be made in a fashion where there's joined-up thinking, because of the cascading failures that can happen when there's not the joined-up thinking of working together as a team. You could think some things are really trivial, but they're not trivial. It can work in a laboratory, but it needs to be truly modular in the context.

[00:03:46] If you take one thing away from this talk today, just this one thing, it is that for startups in particular, cross-functional interviewing is mandatory. It's not negotiable. You need to have all of the different disciplines involved in your interviewing to get that buy-in, to overcome all of the unknown unknowns together and make it a conversation. It's only that way that you're going to be able to surface the technicalities that you don't know about before they happen. Those cascading failures: maybe the batteries shouldn't be underneath the bathroom. When it leaks, maybe that shouldn't happen, and you need to completely challenge that all the time.

[00:04:36] I'm going to give you a very simple recipe for growth and for success, and I believe it entirely: it's simply rubbing your nose in it all the time. I can't guarantee the amount of growth, but I can guarantee that you are going to see people try and react to those challenging problems all the time.

[00:05:02] My background is that I have run a large digital product agency. I have worked in large companies helping their digital products achieve significant growth, millions of users. And I have had my own startups where I've been working in cutting-edge technologies, trying to get people to use augmented reality, TikTok and augmented reality, and in some really challenging circumstances, like old-world industries of fresh produce. But now I am working in the now, where you should be using AI user testing in your products before speaking with your customers, to make sure that you're raising the floor and helping that out.

What cringe is: shame and antibodies

[00:05:48] But today I'm going to be talking about cringe. What is cringe? And then I'm going to tell you about how I've embraced cringe and how I've used that power of cringe in my organization. I hope you can too. Cringe is like secondhand embarrassment. It's like you're laughing at, not laughing with. Some figures of British culture that best reflect those feelings are pioneering comedians like Steve Coogan, who has run with Alan Partridge, whom he's metamorphosed into over the years, and Richard Medley [?], who has not broken character for 30 years. Very funny man.

[00:06:35] In the context of interviewing, depending on whether you are an observer or an interviewer, cringe is largely shame, and shame is the result of internalizing a social contempt. It's a feeling of falling below the judgment, the bar of opinion, and the shame that counts most is in front of those you respect or admire, your peers. Enduring the experiences of shame is traumatic. It leaves a long-held memory. "The shame of the world has a precise function. It serves to immunize us. It can potentially prevent a repetition of horror and hatred." That's a quote from Primo Levi.

[00:07:33] But the antibodies that you get when you're feeling this shame, you can't get them secondhand. You need to feel the shame firsthand. But when you realize this construct of shame, it can be deflected. You could turn it back on itself. The way that I think of shame, it's like a box. It's a box of other people's opinions, the social opinions, and we have to go over those opinions. We have to imagine past those opinions. I believe shame ought to be the price that we pay in interviewing, everyone involved in it. That's what it is. You have to seek it out and take part in it.

[00:08:18] During his lifetime, Jean Genet was a scoundrel. He lived around 1910 in France, and he was a thief and a homosexual, which was not encouraged, and he wrote a book about his experiences in the Mettray penal colony, where young delinquents were sent to be rehabilitated and disciplined. Throughout all of this discipline, he came up with this spiritual exercise in himself, where he thought to himself: for every charge brought against me, unjust as it may be, from the bottom of my heart I shall answer yes. He started to say, yes, yes, I'm taking it. That's how you perceive me, and I am going to work beyond those foundations. So he built this system where he was strong, something he could control, because the desperation not to die confiscates everything, including inducing a lack of shame. It induces a lack of shame.

[00:09:34] This, I believe, is very pertinent to startups. You don't get to be ashamed. You don't get to worry about that. You have to engage with the shame where it is happening. You need to do it. And you have to imagine past that shame, because we need imagination to conceptualize what this shame is. But you have to imagine past that and not live in the eyes of others. You need to think yourself greater than that.

The workflow: speaking with customers all the time

[00:10:03] Moving on to the workflow. How can we engage in this conversation of shame in a normal workflow? Well, I lived by the lean startup. There's only one book that you ever read. It's the book that's been the whole cause of lean penetrating into the minds of product, and it's The Lean Startup by Eric Ries. But I also love Lean Customer Development by Cindy Alvarez, and this gives you a structure for doing it. Continuous Discovery Habits, where you have got the opportunity solution tree, and Escaping the Build Trap, where we're talking about working to outcomes rather than outputs. I'm going to mention these as we go along.

[00:10:49] But the real work of user centricity, and I want to be super, super-duper clear, is prioritization, and it's assuming the shame of where you are right now. Because if you are not embarrassed about where you ship, where you start from, then you haven't done it soon enough. You need to be embarrassed, and you need to be there engaging with the shame all the time. It's not about tickets. It's not about writing things. It's not about anything else apart from speaking with customers, and you need to be doing that all the time.

[00:11:22] There's a great story about Jeff Bezos. Sorry, it's a bit trite to pull out these people you've heard of a million times. Jeff Bezos is in his executive staff meeting with everyone, and someone's got a stat on the board, and it says that the average phone wait time is 59 seconds. It's like, 59 seconds is average, that's great. But he had this email account where he was seeing all these people complaining about the wait time all the time. So in front of all of his executive staff, he phoned the customer support line, and 60 seconds passed, and then 2 minutes, 5 minutes, and there was no answer. Then after 10 minutes on the hold music there was still nothing. They had to wait a really long time and nothing was happening, and it turned out that the metric for the average wait time for answered calls ignored the time until it got picked up.

[00:12:34] I think that represents the quote that he said: when the data and the anecdotes disagree, the anecdotes are usually right. There is nothing like seeing that firsthand. There is nothing like internalizing that firsthand, taking that and owning that deep cut. With my team, where they started from was that they couldn't really see the point, to be honest. But when they felt the pain, they were like, I really don't want this anymore. But they kept doing it. More power to them.

[00:13:14] Whole-team interviewing enhances that empathy. It's not just a hypothetical exercise anymore. It's not a thought experiment. You're there and you're speaking to real users using your product, the thing that you're making. It doesn't matter if they're in customer success, marketing, it doesn't matter if they're in HR. They should all be given the opportunity to really be in front of the people using the product that they're talking about, all the time. That is such a powerful thing. I believe that as our discipline of product management moves more and more to being automated in all these other ways, that exploration can never be automated.

[00:14:02] It really bridges so many gaps where we don't know what we don't know. So we're trying to seek out these user confusions, the pain points. You're going to see those high bounce rates, and you're going to see those low feature adoptions, things that just don't make any sense. That's your opportunity to be interviewing, and you want to take as many people as possible into the interview.

Whole-team interviewing at AppVelocity

[00:14:28] I'm going to tell you about when I joined this company I'm with, AppVelocity. When I joined, they were a completely different product, and they didn't have any users. They'd been in development for nearly a year and a half, and they believed that they really knew their audience and knew their product. I was like, but who are the customers, and where are they? And they're like, "No, no, you don't understand. We have so much experience." And I was like, "Okay."

[00:15:07] What we did was we got all together, and I opened up my LinkedIn, and I said, "Right, guys, you know the target audience." We made this target audience together, and we were going to pinpoint people in my LinkedIn network, and we were going to talk to them over the phone, and you're going to sell it to them, because they'll understand, right? In that first week we did eight interviews, I think, over three days, four days, something like that. It didn't go well. It didn't go well at all. People were confused. The value proposition wasn't clear, and obviously it had to be worked on. Altogether there was a slight despondency and a stepping back.

[00:15:52] But in that gap, that chasm, there was an opportunity for change away from the tightly held beliefs that previously they knew they were on to something. When they had to be in that driving seat, when they had to engage with those target users, target customers, which ones, I don't know, they had to really reconcile those differences. What we did was we quickly found our initial first target customer, and we used a technique called Min Specs, which is part of Liberating Structures, which I thoroughly advise everyone to use. We iterated through the room to get to a point where, together with our customer, we found the things that it must do and must not do, and we iterated to get to a minimum specification. Then from there we used RICE to prioritize what we were going to deliver from that work.

[00:16:54] We came up with this proposition. Okay, get it to market. We've got something that we need to put out there. We had to work to get it to anything that could be used as soon as possible. I put interviews in every single week. From now on, we are interviewing every single week, multiple times a week. I would put some on the Tuesday, some on the Wednesday and some on the Friday. That sounds excessive, right? That sounds hard. But if you want to create urgency, these engineers knew that they didn't want to be in those meetings. We had to really get to something fast.

The scoreboard: 49 minutes to 18

[00:17:28] The problem was we had this huge journey where you had to get all the way through this process to make it sync. The product was completely different then. It was synchronizing variables from design into the codebase, and the actual work required internally was too much. It was boring, and you needed to use the terminal. I was using the terminal, and I, an experienced user, got it down to six minutes, six and a half minutes, to actually get there. But what I did was I made a scoreboard for time to first publication, which was our North Star. I was like, "Okay, guys, we're going to get this down. And until we get it down, we're going to be on interviews watching other people do it."

[00:18:18] If you want to see cringe, sit for 49 minutes on an interview while you watch people use your product. Look at the difference: the guy that took 49 minutes, and they sat through that, and it wasn't even a week later and it was 18 minutes. That's the power of cringe. If you get the engineers into a room and they're all like, "Oh my god, I really don't want to sit for 49 minutes watching somebody else do it," 18 minutes. There is absolutely power there.

[00:18:49] But while we were doing this, the world moved on. The world had already moved on from the proposition as it had originally been set. Lovable and Bolt and all of these products came out, and they were great, and the value proposition which we were originally on just didn't make sense. But it's okay, because we'd interviewed loads of people, and all of the engineers and the designers felt the same way. They were like, "Now that we've spoken to all of these designers, we can really quickly pivot." All of them felt the same way. We all pivoted, very user-centric. We had all of the data needed to really change our story maps. We modified them slightly, and from there we were able to find what the opportunities were going to be in this new context.

[00:19:45] While we're doing all of our interviews, we always put opportunities right down there, loads of little bubbles to come back to. We went back to all of our opportunities and made new opportunity solution trees. That's where we're trying to meet a target. The first target is going to be X amount of users. I think to begin with it was just to have 10 users. Then from there, what's going to get us those 10 users? Well, we've heard this a whole bunch of times, and then there we're going to have solutions to get those 10 users. We were very quick to address the high-value, lowest-satisfaction elements to be able to get out to market where our competitors weren't even looking. From there we were able to offer instant feedback, something that we believed was going to really see a high uptake. From when we first released, it was around about here. This is very low activity, but I'm going to have to fly by because I'm getting on to my time.

Cringe-worthy moments and the pull towards simplicity

[00:20:52] Quickly, some things that we did that were cringe-worthy as well, that we had to fight through. I want to give you the benefit of these cringe-worthy moments. In Figma, you have the concept of a playground. That's where you can use a plugin very quickly. We had to fight through this playground. It had loads and loads of steps and loads and loads of text, and we had to tell people how to use it. Over 10 interviews we managed to shorten it down from originally, I don't know, 25 or 30 steps. We got it down to three, but still there was loads of text on it, and no one read the text, and everyone was confused. Eventually, over the interviews, we got to basically absolutely none of our interface, simply a challenge. And this converted way more than anything else. It's funny how you reduce. You can say the best interface is no interface, but feeling the pain really makes it happen.

[00:21:51] We still had all these challenges with conversion. We had all of these input fields that were required, because designers felt like it needed to have these to be a professional design user testing product. Engineers felt like it needed to have this at this period for technical reasons. But after so many input errors, so much lorem ipsum being entered in here, actually witnessing it getting in the way of people using it, at the end of the day we ended up with one prompt. It makes the whole team feel the pull towards simplicity all the time. And again, putting the sample file and the demos front and center in front of people got it really used.

[00:22:44] The worst of all was the idea of wrapping a section. In order to make this happen faster, we wanted as small an area as possible to actually consume, because we make a snapshot of it. We tried everything to get people to understand: we need you to do this, we need you to do this. We even animated it. We told them in every way we could. But all it did was stop people using the product, until eventually we put this little message down here, and it converts better than anything: if you want to make it go faster, do this. If not, more power to you, you can wait. And when people waited, the thing that we did most successfully was simply to stick a random link on the interface that people could click out to. We didn't hear any problems again, and they could just peruse it. Conversion improved. Hurrah, great. That all worked. You can see here, this is from March, the user session time just shot up. So we're very useful now. It's great, and I want everyone to go and check it out.

Benefits and challenges: no more analysis paralysis

[00:23:53] Basically, the benefits and challenges here. The biggest one I'm going to say is that analysis paralysis is no more. Don't worry about it. If you pull all those people into the meeting, they are not going to be paralyzed by analysis. They're going to want to tackle it. It brings the team together in their thinking, and it helps people get creative in the gaps. You're going to get pushback, and people are going to say things like, "Oh yeah, but I know what's wrong already." No, you don't know what's wrong. You haven't earned the antibodies. You haven't earned that, and you need to actually experience it first.

[00:24:38] I really want everyone to go away from this talk and proudly seek out the cringe. Proudly, as a team, pull in people that might not actually ever want to be in an interview, but proudly pull them in to develop those antibodies for your team, for your product, to make it better. For everyone here today, I want to offer you 50% off our product. This will work for 30 days, or you can search for us on the Facebook [?] community. I thank you very much. Go and embrace your cringe. Thank you.

Q&A

[00:25:11] Host: Excellent. Thank you very much, Kevin. Hope everybody out there is cringing right now. We do have a couple of comments. Joel is saying, appropriate name, maybe. You can fill us in, Joel, if you thought it was appropriate. And Ganesh has asked, can you please relist all four book names? I took down The Lean Startup, Continuous Discovery Habits, but you had Lean something else.

[00:25:42] Kevin: The Lean Startup, Continuous Discovery Habits by Teresa Torres, Escaping the Build Trap by Melissa Perri, and Lean Customer Development by Cindy Alvarez. And there's another one as well, Running Lean, that should be on there. Those are the only books I think anyone needs to build a product nowadays.

[00:26:08] Host: Excellent. I'm going to ask you a question about another book that you put up there, and that was around Min Specs. You ran over that really quickly. Can you elaborate on that?

[00:26:20] Kevin: Liberating Structures is a canned set of workshop structures to help you through any workshop environment. I absolutely advocate everyone to check out Liberating Structures online. It's all free. There are lots of recipes there. If you're ever going to be in a workshop situation, as fast as you can you can get a structure to have a great outcome out of any situation, one that's been tested hundreds of thousands of times. And Min Specs is a great way to get to a minimum specification without even knowing anything about the product.

[00:27:12] Host: Great, I'll definitely check that out. Just doing a time check: we've got 40 seconds. The only other one I noted was around RICE. Is RICE not a bit risky, because you're baking in assumptions without talking to your customers? You said you did your RICE prioritization ahead of your tests.

[00:27:39] Kevin: I think all of these things are a moving target. They're an Overton window. You'll do one thing one time, but it's not the definitive time. You have to revisit, revisit, revisit. I'm never scared to do the best with what we have. You've just got to go with it. It might be that we had to initially do estimation before we had enough evidence. But again, analysis paralysis: just move with it, and then re-estimate when you know more.

[00:28:12] Host: Excellent. On that, I just want to thank you once again, Kevin. That was a very cringy talk, so thank you for caring.