B (1:55)

I mean, that is annoying, but isn't that just part of the job? Like, when I was doing client work, I had to do administrative stuff. I didn't love either. You just do it because it's what's required.

A (2:06)

But here's the thing. We act like willpower and discipline are unlimited resources, but they're not. Every extra step, every bit of friction, that's depleting a limited resource. And at some point people run out. So even if they start the day intending to update the CRM by the end of the day, when they're tired and they've got five other things to do, it just doesn't happen.

B (2:26)

So what did you do about it?

A (2:28)

We built an integration where they could just forward the email to a specific address and it would automatically create the CRM entry with most of the fields populated. And the adoption rate went from maybe 40% to like 95% within two weeks.

B (2:43)

Okay, that's pretty dramatic. But that also required, I'm assuming, custom development work. Not every company has the resources to build integrations for every little process.

A (2:54)

That's true. And honestly, sometimes the right answer is just don't use the tool. Like, if a tool requires so much custom work to make it usable, maybe it's the wrong tool. Or maybe you just stick with the informal way. People were already tracking things.

B (3:07)

See, I struggle with that though, because the informal way is usually a mess. Like, I've worked at companies where everything was in random slack threads and spreadsheets and you couldn't find anything. At some point you need actual systems.

A (3:21)

You do. But I think we get seduced by the idea of the perfect system. Like, we see this beautiful dashboard or this comprehensive tool and we think if we could just get everyone to use it, everything would be organized. But the organizing system that no one uses is worse than the messy system that everyone actually uses. Hmm.

B (3:40)

Okay, I can see that. So you're saying it's better to have a B system with 100% adoption than. Than an A system with 30% adoption.

A (3:51)

Exactly. And I think that applies to so many things in business. We optimize for elegance or comprehensiveness instead of optimizing for actual usage. And then we're surprised when people don't use it.

B (4:02)

Alright, so let me throw a different scenario at you because I want to see how this thinking applies. I'm dealing with this right now, actually. We launched a new project management tool. Everyone agreed it was good. We even did training on it, and no one's using it. What's your take?

A (4:21)

Okay, what do people have to do to use it?

B (4:24)

They have to log in, obviously, find their project, update the status on their tasks, add any notes or blockers. It's pretty straightforward.

A (4:35)

But where are they doing their actual work? Like what Tools. Are they in all day?

B (4:40)

Mostly Slack and Google Docs. Some people are in figma or Code editors, depending on their role.

A (4:47)

Right, so you're asking them to stop what they're doing. Context, switch to a different tool, update information that may or may not feel immediately relevant to them, and then switch back to what they were doing.

B (4:59)

When you say it like that, it sounds worse than it is. It's like five minutes.

A (5:04)

It's not about the time, though. It's about the context switch and the fact that it. It's outside their natural workflow. They're not in that tool anyway, so they have to remember to go there. And remembering is friction.

B (5:15)

Okay, so what's the solution? Just let chaos reign?

A (5:19)

No, but maybe you need a different approach. Like, what if instead of them going to the project tool, the project tool came to them? What if there was a Slack bot that just asked them at the end of each day, what did you work on today? Any blockers. And it logs that automatically.

B (5:33)

And I mean, maybe, but then I'm still not getting the structured data in the format I need. Like, I need to be able to see dependencies and timelines and all that.

A (5:44)

Okay, but do you need everyone to input that level of detail, or do you need that for certain people or certain projects? Because maybe your developers just need to say what they shipped and whether they're blocked. That's it. And then your project managers are the ones who maintain the detailed view.

B (5:58)

Huh. That's actually not a bad idea. So you're saying different levels of friction for different roles based on what they actually need to do.

A (6:07)

Yeah, and based on what they're actually capable of maintaining. Like, if you ask everyone to maintain detailed documentation of everything they do, that's a lot of overhead. But if you just ask for the minimum and then have specific people whose job it is to synthesize that into the bigger picture, that's more realistic.

B (6:23)

Okay, I'm going to push back on something, though, because I feel like this whole conversation could be interpreted as just make everything easier and accommodate everyone's laziness, and I don't think that's the right takeaway.

A (6:35)

What do you mean?

B (6:35)

I mean, there's value in having standards and expectations. Like, if we just constantly remove every bit of friction because someone finds it annoying, aren't we just racing to the bottom at some point? People need to adapt to the system, not the other way around.

A (6:51)

I think that's true when the friction serves a purpose. Like, if you're making a big decision, you probably want some Friction. You want people to have to think about it, maybe get approval, document why they're doing it, that friction is protective. But most friction in organizations is accidental. Nobody designed it, it's just how things evolve.

B (7:08)

Give me an example of accidental friction versus intentional friction, because I think that distinction matters.

A (7:14)

Okay, so intentional friction would be like you have to get two approvals before you can spend more than 10 grand. That's deliberately slowing things down for a good reason. Accidental friction is like those two approvals have to happen in two different systems and the second approver doesn't get notified until the first one completes. And there's no automatic reminder if it's been sitting there for three days.

B (7:34)

Okay, yeah, that's just bad process design.

A (7:38)

Right? So the goal isn't to remove all friction, it's to remove the friction that's just there because we never thought about it, and then be really intentional about where we do want friction.

B (7:47)

Alright, I'm tracking with you now. So how do you actually figure out where the accidental friction is? Because I think when you're inside a system, you get used to it and you stop seeing how annoying it actually is.

A (7:58)

That's exactly the problem. So what I do is I literally sit down and map out every single step of a process. And I mean every step. Like, open browser, go to URL, log in, click here, scroll down, fill out this field, hit submit, check email for confirmation, click the link in the email. All of it.

B (8:15)

That sounds incredibly tedious.

A (8:17)

It is tedious, but it's revealing because when you write it all out, you realize there are like 20 steps when there should be five. And then you can start asking, okay, which of these steps are actually necessary? Which ones can we automate? Which ones can we eliminate?

B (8:31)

Have you ever done this and realized the whole process is broken and you just need to start over?

A (8:36)

Oh, yeah, absolutely. Sometimes you map it out and you realize the process is trying to solve a problem that doesn't exist anymore. Or it's solving it in a way that made sense five years ago, but doesn't make sense now.

B (8:47)

What's an example of that?

A (8:49)

Okay, so I saw this at a company where they had this whole approval process for blog posts. It had to go through the content person, then the brand person, then the legal person, then the executive team. And by the time something got published, it had been through like six rounds of edits and taken three weeks.

B (9:04)

I mean, that sounds like every corporate content process I've ever seen.

A (9:09)

Right. But when we actually looked at it, the reason for all those approvals Was because, like three years ago, someone had published something controversial and. And it caused problems. So they added all these checkpoints. But the controversial thing had nothing to do with the blog. It was actually a press release. And they'd already fixed the press release process separately.

B (9:26)

So they were solving a problem that had already been solved in a different way.

A (9:31)

Exactly. But no one had ever questioned whether they still needed all these blog approvals. They just kept doing it because that's how it was done.

B (9:39)

So what did they do?

A (9:41)

They cut it down to just content review and legal review for anything that made claims about products or made legal statements. Everything else could just be published and their publishing velocity tripled.

B (9:51)

Okay, but didn't that create risk? Like, what if someone publishes something stupid?

A (9:58)

It could, but it didn't because the people writing the content were professionals who understood the brand. The risk was theoretical, the slowdown was real.

B (10:07)

I think that's a hard trade off for a lot of companies, though. Like, people are so afraid of the downside risk that they'll accept massive inefficiency to prevent it.

A (10:16)

They will, and sometimes that's the right call. But most of the time I think the risk is overstated and the cost of the friction is understated. Like, we'll do all this stuff to prevent a 1% chance of something going wrong, but we don't calculate the cost of everything taking three times longer.

B (10:31)

Yeah, that's fair. Okay, so I want to shift gears a little bit because we've been talking mostly about internal process stuff. What about customer facing stuff? Like, how does this friction thing apply to sales or marketing?

A (10:46)

Oh man, it's huge there. Like, think about your typical sales process. How many steps are there between someone being interested and them actually becoming a customer?

B (10:55)

I don't know. Depends on what you're selling for. Something complex could be a lot.

A (11:01)

Right. But every step is a place where people drop off. So if someone has to fill out a form, then get on a call, then review a proposal, then get internal approval, then negotiate terms, then sign a contract, that's like six places where the.

B (11:13)

Deal can die, but you can't eliminate all of those. For a complex sale. Like, if you're selling something expensive or technical, there's going to be a process.

A (11:23)

You can't eliminate all of them, but you can probably eliminate some. Or you can make the remaining ones way easier. Like, do they really need to fill out a 15 field form? Or could it just be name and email and you figure out the rest on the call?

B (11:36)

I mean, we ask for the extra Stuff because it helps us qualify them and prepare for the call.

A (11:41)

Sure, but how many people are dropping off at the forum who would have been good customers because you're optimizing for your convenience at the expense of conversion?

B (11:49)

Hmm, I haven't really thought about it that way. We just always ask for company size and role and budget and all that.

A (11:57)

Right. And maybe some of that is necessary, but I'd bet you could cut it in half and not lose any useful information. Like you're going to find out their company size in the first two minutes of the call anyway.

B (12:07)

That's true. Okay, what about pricing? Because I feel like that's an area where there's a lot of debate about how much information to give upfront.

A (12:17)

Pricing is interesting because there's two schools of thought, right? One is put it all out there, be transparent. People can self select. The other is hide it, make them talk to sales, customize it.

B (12:28)

And which do you think is right?

A (12:30)

I think it depends on what you're selling. But in general, I lean toward more transparency because hidden pricing is friction. It forces people to have a conversation they might not be ready for just to get basic information.

B (12:41)

But if your pricing is complex or varies a lot based on use case, you can't really publish a price.

A (12:46)

You can publish a starting price or a typical range, though. Like most customers pay between X and Y or starts at Z. That at least gets people in the ballpark, and they can self select if they're way outside it.

B (13:00)

What about the argument that if you show pricing, you scare people off before they understand the value?

A (13:06)

I think that's usually an excuse for being expensive. Like, if your product is genuinely valuable, you should be able to articulate that value clearly enough that the price makes sense. And if you can't, maybe the product isn't as valuable as you think.

B (13:19)

That's kind of harsh.

A (13:21)

Maybe. But I've seen so many companies hide their pricing because they're afraid of the sticker shock. And then they wonder why their close rate is terrible. It's because they're getting a bunch of people into the sales process who were never going to buy at that price anyway.

B (13:35)

So you're saying transparency filters better?

A (13:38)

Transparency filters better. And it respects people's time, including your sales team's time. Like, do you really want your salespeople spending hours with people who were never going to pay what you charge?

B (13:48)

No, definitely not. Okay, so bringing this all back together, because I feel like we've covered a lot of ground. If someone's listening to this and they Want to actually apply this thinking, where should they start?

A (14:01)

Pick one thing that's not working the way you want it to. Could be an internal process, could be a sales motion, could be a marketing funnel, whatever, and just map it out. Write down every single step that has to happen. And then look at it and ask yourself, where's the unnecessary friction?

B (14:15)

And then what? Just start cutting things?

A (14:18)

Start cutting things? Or automating things or embedding things into stuff that people are already doing. The goal is to make the right behavior easier than the wrong behavior. Or in some cases, make the wrong behavior harder.

B (14:30)

What do you mean by that?

A (14:33)

Like, if you don't want people to do something, add friction to it. Make it require approval, make it take more steps, make it inconvenient. We usually think about removing friction from good things, but you can also strategically add friction to bad things.

B (14:45)

Huh. That's an interesting way to think about it. Okay, last question. What's the most common mistake you see people make when they're trying to implement this kind of thinking?

A (14:56)

They try to fix everything at once. Like they have this revelation that friction is everywhere and they want to redesign the whole organization. And that doesn't work because now you've created this massive change management challenge.

B (15:06)

So start small.

A (15:07)

Start small. Pick the one thing that's causing the most pain, fix that, prove that it works, and then move on to the next thing. Because every time you remove friction and something gets better, you build credibility for this way of thinking.

B (15:20)

And then people start bringing you problems instead of you having to go find them.

A (15:25)

Exactly. Alright, I think that's probably a good place to wrap. Sarah, thanks for pushing back on some of this stuff. It makes the conversation better.

B (15:31)

Yeah, of course, I'm still not 100% sold on all of it, but you've given me some things to think about.

A (15:38)

Awesome. That's all I can ask for. Alright, everyone, if you got something out of this, let us know. And if you try mapping out a process and find some ridiculous friction, send it to us. We love hearing that stuff. See you next time on Business Lunch.