---

The Right Way to Approach Custom Development

---

---

Everybody thinks they’ve got custom development figured out. They don’t.

They just opened a new Rec Center here where I live in Colorado. My family was excited to try the place out. And when we finally did, it was gorgeous. The pools were fantastic, with a really slick little slide area. The workout area was well laid-out. The grounds were incredible. For a small town like the one where I live, it was beautifully designed. We were so impressed that we decided to immediately sign up. As we were leaving, though, I ran into a problem. Literally. I couldn’t get out of the building. My kid started laughing at me. Now if you’ve had a 16-year-old, you know they have the world figured out. The rest of us are dumb and just need to get out of their way. But in this case, my wife joined them in laughing—she’s supposed to be on my side!

So how could I not get through that door? What was my problem? Well, whoever designed the door had never read The Design of Everyday Things by Don Norman. The term Norman Door was coined after him to illustrate the concept of good vs bad design. A Norman Door is a door that is difficult to determine how to open or close because it’s not designed in the way that you think doors should be. There are policies and principles that work within cultures and with the way human beings function. And one of those is this: if you’re approaching a glass door with a handle that goes across, you push. If the handle is tall and on the side, what do you do? Right, you pull! Well, the handle on this door was tall on the side, so I was pulling. Right next to a sign, that my hand was literally touching, that said, “Push”. And that’s why my family was laughing at me. Because, Dad, you’re an idiot. Can’t you read? It says “Push”. Well, no, no this was not my fault—it was a Norman Door!

That’s terrible design. Terrible customization. And it’s a real problem to look out for when creating custom development. Because in my experience, customizations built with the best intentions often don’t achieve the intended results. In fact, they can even be harmful. My first advice is to not even go there. Ask yourself, “Do I really need this customization?” Chances are, you probably don’t. Of course, that’s not going to stop everyone. And you might have a legitimate reason to justify custom development. So how do you do it right? How can you avoid a Norman Door and instead use good methodology to improve your systems and actually get results? Here are 4 rules for getting custom development right.

Rule #1: Don’t Try to Predict the Future

When we custom develop something that we’re standing up for the first time, we’re often envisioning a future that is a direct amplification of today. That’s not how the future works. It never has been. Go back and look at a 1950s magazine and its predictions for the year 2000. They got a few things right, but for the most part? Not even close! When you’re customizing an implementation, typically what you’re doing is thinking of all the friction points you have today and then you’re amplifying those. You’re trying to customize around that.

Think about your experience. How many times have you stood up a customization only to use some—or maybe even none—of it? Was it because you did a bad job developing it? Were the developers bad? No! The problem was you couldn’t see the future, shame on you.

We call this roadblock “overfitting the solution”. Overfitting is a term used in machine learning that gives perfect outcomes in a narrow training environment but doesn’t work in the real world. You might be able to work a solution that solves all your perceived friction points, but if one real-world variable changes, it breaks. Overfits are fragile and only work if everything else is true. The problem is that the future is random. Instead of overfitting, you want to build a system where you can exploit the positive and mitigate the negative. Custom development often targets those negatives. And that’s fine. But proceed cautiously. Why? Well, my guess is that the negative ones that you’re thinking of aren’t even really a thing anymore. Things have likely changed and they’re probably not impacting your business like they were five years ago. So why fix problems that aren’t even there?

Rule #2: Always Keep the End-User in Mind

When we customize all these products, we’re very rarely doing it with the end user truly in mind. For example the end user often isn’t part of the design or customization process in a significant way. Sure, there might be a little bit of User Acceptance Testing (UAT), but I’ll tell you, UAT on its own is junk. It’s in a test environment, the user is not actually using it where they have the pressures of “you’ve got to get this done and you’ve got to get so many done in a certain amount of time”. So, they’ll say its fine, but as soon as they’re actually in the real-life environment using it, it starts to fall apart. You can’t rely on UAT alone to give you good real-world experience.

In the contact center world, customizations impact the Customer Service Representative (CSR) the most, yet the CSR pool almost always has the smallest voice if they even have a voice. So, everybody in upper management, design, IT, and development wants CSRs to just do their job. But they’re not able to do their job because what we’ve designed doesn’t work for them. It doesn’t work for the interaction. It’s not intuitive. It doesn’t take the human condition in mind. It’s counterculture to everything else you’ve set up to that point. The design has to account for the actual experience of the CSR, and you can only do that through observation. And typically, that doesn’t happen. What typically happens is this. We know people aren’t executing in a certain way and so we just ideate. “I know how it would work for me.” And we design it that way. Instead, you have to design for the everyday CSR.

Don’t get carried away, though. While observing your CSRs must be central to your design, they shouldn’t be part of the design team. Because whatever they think they need, they’re likely at least partially wrong. Before the iPhone, if you had asked a smartphone user what they needed, it would sound like this. Bigger screens. A better stylus. More buttons. Essentially, an amplified version of what they had. Then Steve Jobs introduced us to the iPhone, everyone was like, “Oh no, that’s it!” Not what they imagined, but exactly what they wanted. We didn’t need a better stylus. What we really needed was a completely different way to interact. You’re only going to get that through observation and watching what they’re doing. Have the development team start watching screens. Go tag the calls. Talk to the CSRs about why they’re doing what they’re doing. Then you’re ready to go ideate.

Rule #3: Observe and Watch for the Friction Points

Instead of trying to implement a bunch of customizations, deploy the product first. Then watch where the friction points are and customize around them. Think of this method for custom development as the Un-poured Sidewalk model.

There’s a college in Greeley, Colorado that decided to redo its grounds. It was beautiful except for one thing. They didn’t include any sidewalks. Ridiculous, right? Instead, they came back the next year and looked to see where the ware patterns were. And then poured the sidewalks there. Think about it. Most college campuses have these beautiful grounds; beautiful sidewalk patterns. And then all these stretches of dead grass where people are actually walking. If you have people who are working around a process and have developed their own systems, you have a broken process. Keeping folks off of the grass by playing whack-a-mole with your people isn’t the way to get them to adhere to the process. You have to observe, you have to watch. You have to pay attention. Without observation, it’s not going to work.

There’s an analogy I like to use for this. I think it’s the origin of the phrase “keep your nose to the grindstone.” This phrase goes back to when they used to grind wheat. You literally would have to keep your nose on the grindstone because you’d have to smell when the wheat would start to burn. When it would start to turn from grinding to burning, not only would you set the wheat on fire, which is a bad thing, but anybody who’s ever aerosolized flour and lit it on fire knows that that’s an explosive combination. You could kill people if you’re grinding wheat caught on fire. It was incredibly dangerous!

That’s what you have to do with good development. Keep your nose to the grindstone so that you can tell when that burning starts to happen. When a CSR starts to bypass the system? That’s the burning. They’ve got workarounds with the system or excuses on why they can’t use the system? Your wheat is burning. Increasing handle time or ACW (After-Call Work) or people are finding ways to do things outside of the call? These are signs that your wheat is on fire.

What do you do when you find those broken processes? Well, that’s when you tackle the customization. In Don Norman’s The Design of Everyday Things, he introduces one of my favorite concepts, Poka-yoke.

Poka-yoke is a Japanese term that essentially means “mistake-proofing”. Incorrect use leads to an invalid result. Let me give you an example. We’ve all gone to a fast-casual restaurant where they have a big open trash can with a sign that says please don’t throw away your baskets. I regularly throw my basket away by mistake! And my wife makes me feel bad for it. Either she’ll dig it out, she’ll get me to dig it out, or I’ll feel the guilt trip because I didn’t dig it out. Now every time I visit this restaurant, I’m stressed about throwing the basket away. Another similar fast-casual restaurant doesn’t have the signs. It doesn’t need them. The hole in the trash can is too small for the basket. I can’t throw it away because it just doesn’t fit. That’s Poka-yoke. And that’s a great solution. That’s a great customization that works with the human condition.

Rule #4: Use the Right Technologies and Methodologies

There are a ton of customization technologies out there. I’m not going to sit here and tell you which ones to use. The fact is it really doesn’t matter. Whatever technology your team is best at executing, that’s the one to go with. You don’t want a technology that’s so super-focused that only one person in your organization knows how to use it. I’ve run into this before, and it’s not fun. We were using a rare programming language—it was a great language—but when the one person who knew that language left our organization, we couldn’t find anybody else to do it. We had to start from scratch. So be careful!

More important than the technology is your methodology. In The Tipping Point, Malcolm Gladwell says, and the data is pretty clear on this, that a child in a troubled family, but a good neighborhood will do better than a child in a troubled neighborhood with a good family. Because it’s a system. When folks are highly disciplined, we think oh, man, they’ve got this great ability to just control their mind and make themselves do things. Nope. In actuality, disciplined people change the environment in such a way that that behavior is a default output. And that’s what customization is about. Custom development is about changing the system in such a way that the behavior you want is the default output. And that’s when you know you’ve done it right. There’s a reason why project management products like Agile, Sprint, Scrum, and Lean Six Sigma have been around as long as they have. They work. They’re not sexy or fancy. It’s not rocket surgery. You just deploy the system as vanilla and as simple and as basic as you can. If you have a customization that you really can’t live without, the first question is, “Are you sure?” And then if you’re sure, only do the critical few, the ones that you absolutely have to have. If you’re in an environment where the regulations require that you have this to be HIPAA compliant, for example, then yes, do that. But keep it to the bare minimum and then follow a hygiene of maintenance and updates.

There are a lot of models out there that will help you create a system that drives these kinds of results. If you’re looking for a simple place to start, I recommend the 4DX model from The 4 Disciplines of Execution by Chris McChesney, Jim Huling, and Sean Covey. I can’t take credit for it. I didn’t write it, I didn’t design it. I just use it.

Step 1:

Set a wildly important goal. It’s the big goal you’re trying to achieve or accomplish. What’s that big overarching umbrella thing? Is it becoming digital-first? Is it cutting your expenses down by 25%? Is it becoming the number-one seller in your market?

Step 2:

You have to measure, monitor, and act on lead indicators, not trailing indicators. What’s the difference between a lead indicator and a trailing indicator? Most people think that a lead indicator is a trailing indicator measured more frequently. Say you’re trying to improve your EBITDA from 20 to 25%. If you’re measuring it at the end of the year, people think the leading indicator of EBITDA at the end of the year is EBITDA quarterly or EBITDA monthly, or EBITDA weekly. No, that’s just a more frequent sample of a trailing indicator. Instead, look at the behaviors that lead to that result. Let’s say your company sells shoes. Well, what if one of your associates who sells shoes has a better rate of sale than another associate? What are they doing differently? Maybe they’re showing every customer 3 pairs of shoes and assuming the close on applying for a credit card. Those are leading indicators because they’re happening during the interaction.

Step 3:

You have to have a compelling scoreboard. That’s where you take the leading and trailing indicators and put them together. You can show that the change you made in the lead indicators moved the trailing indicator as you expected. If they did, great! Double down on it. If they didn’t, the lead indicators are probably wrong. Fix it.

And if you’re doing this with a team, make sure the people on the team are actually doing the work of updating that scoreboard. The idea is to get that as close to bare metal as possible. It can’t be a scoreboard that management owns. It can’t be automated. Trailing indicators? Yes, those should be automated. But leading indicators should be measured while people are doing it, and by definition, it’s typically not something you can automate.

Step 4:

And the last one. And this is the one that people tend to jump to first or not do at all. It’s cadence accountability. If your developers are not developing something that’s moving that trailing indicator like you expect, you have to hold them accountable, because either they don’t really know what the lead indicator should be or their solution for that lead indicator is incorrect. And it needs to get fixed.

Hitting the Tipping Point

So how do you know when you did it right? You hit the tipping point. The tipping point is when it just works. When you make the right small change and everything just clicks. You get that big lift with what feels like a very little amount of effort. That’s the tipping point.

Sarah Betts, Senior Accounts Representative at Alyce, is working on an article right now based on some of the lessons taught here and they helped her recognize what she needed to do. Her start-up company ran into a really bad issue and needed to get a bunch of outstanding tickets in quickly. Typically, the answer would be to just go chasing everyone around to try to get the tickets. Instead, she utilized the process described in The 4 Disciplines of Execution and built a compelling scoreboard that just showed people how they were doing. And she got immediate results. Sarah didn’t have to harass or beg or pester or bother or bludgeon or beat a single person. All she needed was a form of measurement that everybody sees throughout the day and could buy into. Why did it work? You’re giving people wins. You’re giving them regular wins. And nothing is more motivating than that inertia of success. That’s a system done right.

It will look different for you. Your culture, your organization, your workforce; they’re all unique. The important thing is to find a something that works. And then introduce changes that are natural and intuitive to your CSRs. Nothing drastic. Nothing that’s going to flip your organization around overnight. Just small executions that fit into the natural rhythm of your culture. And keep tweaking, always making the process a little better. That’s how to custom develop.

Want to learn more about the different methods for success? Just dive into the literature! In particular, Four Thousand Weeks by Oliver Burkeman, Deep Work by Cal Newport, and Atomic Habits by James Clear (besides the ones I mentioned above) are important resources you’ll want to check out. I’ve posted reviews of these (and many others) on my website. Each review only takes a few minutes to read with just enough content to encourage you to read it for yourself.