Junked crts computer monitors, tvs and old printers for recycling or safe disposal recycling -better technology deployments concept
PHOTO: Shutterstock

Are you continuously deploying junk?

  • How often does your team or company deploy a release that you know includes technical or UX debt?
  • How often does someone on the team proclaim that it’s OK to do that because they’ll fix it later?
  • How often does someone prioritize fixing that technical or UX debt (vs. moving forward with new stories and features)? Not very often, right?

We must stop telling ourselves and each other the fable that it’s OK to release something with technical and/or UX issues because we’ll do “fast fixes” or put improvements into the backlog.

Related Article: Agile vs Scrum vs Kanban Weighing the Differences

Put Yourself in the Customers Shoes

When you are the customer in that same situation, are you grateful for that flawed release? Do you wish you could go back to an earlier version? Do you dump that company and check out competitors? When you imagine yourself as the frustrated customer, especially a paying customer with high expectations, it’s easy to see why releasing something knowingly-flawed is never a good idea.

customer problems graph

When I deliver my “DevOps ICU” presentation to non-UX roles at engineering and Agile events, one of the live attendee polls asks the audience to consider five problems and rate them from 0 (the customer doesn’t care) through 10 (the customer is so furious they might cancel or stop using your service).

Every conference audience votes nearly identically. The problem, “Agile teams were inefficient and ran over budget,” is mostly invisible to the customer and unlikely to inspire them to abandon your company. Customers might wait a little longer for the next release, but they’ll probably stick around.

The first four are always voted higher on the scale as they are easily recognized as debt and problems that could make a customer dump you. They are:

  • Slow site or app, poor server response times.
  • Feature is hard to use and not intuitive.
  • Screens are cluttered or complex.
  • Confusing navigation, can’t find what I need.

What these four have in common is that they are all part of the user experience. Your UX team might not be able to fix server speed, but this poll reminds attendees that technical problems are seen as poor user experience and can drive customers away.

And yet, teams keep shipping these problems to their customers.

Pirates of the Caribbean: A Walk-Through New Orleans-Themed Wax Museum?

Many may not know that the “Pirates of the Caribbean” boat ride was not originally conceived that way. Disney’s original idea was instead a New Orleans-themed walk-through pirate wax museum. They started building it but when they saw how popular the, “It’s A Small World,” boat ride was, Walt demanded that Pirates be redesigned.

Disney’s workers were against it at first; they had already spent time and money building that earlier approved wax museum idea. The story goes that Walt didn’t care. He wanted to build what people would love the most and that’s a boat ride.

The Cost to Change Your Mind

The same is true for your software project. Don’t release something knowing it’s broken or not quite right and imagine you’ll fix it later. It costs less to change your mind or change product direction before the public sees it. It costs even less if the flaws are UX’s responsibility and discovered during UX testing since at that point, engineering will have done little or nothing on that feature yet. Just change wireframes or prototypes, retest and zap that debt.

Compare the cost to make a change before release to the cost of these disasters:

  • Customer support, call centers, marketing, PR and social media managers have to clean up a huge public mess if customers, potential customers and/or media perceives your product as a failure.
  • Dev teams rebuilding and QA testing again will cost you a great deal in both time and money.
  • Public opinion will hurt you. Most people don’t go back and change their app reviews. They don’t remove an angry social media post when they feel better. They are unlikely to re-install your app or return to your website if they feel done with your product.
  • Customer support and call centers will become overwhelmed when people can’t figure out how to use your new product or feature — because it’s not “user friendly” or is perceived as “broken.”
  • Explaining a public disaster to shareholders or the board.

Every Feature Counts and Is Worth Getting Right

Even if you’re not doing lean, take it from Eric Ries, who wrote, “What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?”

When measuring productivity, efficiency, or another internal aspect of software development, none of it matters if you are building products that drive the customer away.