Top 5 (Shitty) Excuses for Product and Service Failures

We fail often, we fail fast, and we fail slowly. We rarely figure out why because we think it’ll be faster to just try again with another idea. To justify that practice, we make a lot of excuses.?

And since we can make trendy and accepted excuses, our course of action is typically no action. Our failures are acceptable. If we believe popular posts and podcasts, high failure rates should be celebrated. There is no need for action or change because when we fail, we love it. It’s great strategy and product management to fail often! So, let’s cycle around and fail again.?

We don’t have to make excuses for successes.

We are rarely called into a meeting where we need to quickly tap dance, rationalize, or blur the truth about what caused us to have great success. We should post-mortem our successes so we can learn from them!?

But we are typically called into these meetings because we failed. We tap dance, rationalize, and blur. We often guess what went wrong?—?and why?—?because we rarely took the time to understand the failure.?

I recently spoke to someone from a Fortune 200 who told me a story about a project that was moving right along without any research with target users. $8 million into the project, they realized the hard way that this was all wrong. The project was scrapped.?

Was there a chorus of excuses and rationalizations? Was there accountability? Did meaningful, tough conversations happen? Did someone pretend this was failing fast or a wonderfully positive failure? Did someone trot out statistics on how much other companies fail, and decide the $8M loss was just fine?

Let’s look at the top five shitty excuses for product and service failures.?

When you hear these, you must move past rationalizations and excuses. Get to the root causes. Reduce risk and failure. Hey, maybe even aim for success!

Excuse #1: A high churn rate is normal or average for our industry, so why spend time or money trying to lower our churn?rate?

What percentage of your new customers stay with you beyond a trial? How many are still there after a few months? What about in year two? Many companies find that they have trouble retaining customers.

One startup I spoke to told me that he has had 100,000 new users over the last five years, but very few of them have stayed for more than one week. He didn’t want to spend more than $5,000 on this problem, so he will go into year six with this problem.

I spoke to a Product Manager who told me that his company’s churn rate was around 30%. This hurts them badly as they constantly work to find new customers, a third of whom won't stick around. Finding new customers doesn’t solve the problem of why the ones you already found don’t want to stay.?

The PM’s excuse was that a 30% churn rate is probably average or normal. It might even be similar to other churn rates from companies in their arena. They didn’t have a strategy or a plan to significantly reduce their churn rate because it was excused as normal and average.?

In a world of “go faster and innovate more,” we’re somehow happy to be normal or?average.

The true enemy of good isn’t perfection. The true enemy of good is that we’re actually not that good. We’re OK with being average and making excuses, even when it hurts?us.

When Airbnb announced a 92% failure rate for experiments in which they were highly confident, that should have made our heads explode. This should lead to people being fired. Consultants should be hired to examine processes and why we have such high confidence despite being proven wrong nearly 100% of the time.

Instead, we see these failure rates, we’re told this is a sign of good product management or strategy, and we add it to our quiver of excuses. Hey, it’s fine if we’re failing a lot. So do Airbnb, Microsoft, and Google! OK, but are you also succeeding as much as Microsoft and Google? How much can you afford to fail? Perhaps you can’t afford a high failure rate, and you’d like to finally stop excusing frequent failures, waste, risk, and losses.

Excuse #2: We had a deadline to?meet.

Small and large failures often happen because we prioritize getting it done soon over doing it well. It sounds cool to be fast or fail fast, but we don’t exist in a corporate bubble. We live in a world where customers expect quality. They rarely know about our deadlines or internal processes. They just want good things that work as they expect.

If you meet your deadline but the outputs and outcomes are poor, should we still celebrate that we met a deadline? Do paying customers care if we meet our deadline? Do unhappy users say, “Aw, this is probably good enough!”

Customer experiences are the outcomes we are supposed to care about and?measure.

Instead, we believe that it’s better to finish something fast or on time than to finish it well. We believe in speed over quality, even though our customers nearly always prefer quality over speed.

You’re a customer and a user. How often have you thought (or shouted), “Who rushed this broken shit out?” Now consider how many people are yelling about your company… or at your company and your Customer Support reps. Customers know you suck !

Excuse #3: We’ll fix it?later.

This is the monotonous chant of the team with low quality standards. Our Definition of Done probably checks that it functions for at least some users. We might not even check the product on all browsers or devices. We might not check if it’s accessible for people with various disabilities, diagnoses, and conditions. Just ship it!

We want to meet those deadlines, so we don’t mind delivering something we already know is broken.?

There are many methods and processes designed to keep teams from shipping something they already know is broken, unfinished, low quality, or not quite what our customers need.?

• Agile Manifesto principles remind us that design matters, customers expect quality and value, and we shouldn’t waste our time (on guesses or bad ideas).
• Lean reminds us to change our internal processes if we notice risk, waste, and poor outcomes. We’re supposed to map the value stream, look for leaks and waste, and fix it.
• Service Designers, Strategists, Business Designers, and consultants try to find the sources of our problems, poor processes, and failures, and then help us improve, if not fix, these.
• Endless courses and books teach us how to create more business success by being value-led: leading with the value we can deliver to customers.
• For many years, the biggest consulting companies have advocated for CX/Customer Experience departments and programs. These are user-centered and experience-led at every step of the process.
• We quote famous and successful people, but we don’t do anything like what they say.?
• We say “outcomes over outputs,” but we have low standards for both.

Teams should rethink their standards.?

Consider our quantitative and qualitative measures. Consider which metrics measure outcomes for the customers and users in our experience ecosystem. Consider how we measure business outcomes.?

Do we have high standards? Low standards? No standards? For both customer outcomes and business outcomes? Do we only care about business outcomes?

You already know the answer for your team, project, or company. But if you want to pretend you’re not sure, check success rates. These are your outcomes. More importantly, check how often you’re making excuses for those outcomes.?

Excuse #4: That’s what the stakeholders/executives wanted.

We all knew it sucked, wasn’t quite right, or needed more research before we decided on a solution. But we might have said and done nothing. The high-paid people have spoken, and we’ll take those orders.

The world changes quickly, and what people want or need evolves. If we aren’t constantly researching those behaviors, tasks, decisions, motivations, and more, it’s easy to ignore what we don’t know. It’s easy to run with what someone above us asks us to do. Just take orders and make your job easier.

But this doesn’t match:

• Job descriptions. We were promised a workplace with empathy for users, where we would create something that delights them, and focus on their needs. We were told we would be strategic and empowered.
• All the books and methods that said we would delight customers and really meet their needs.
• All the books and methods that said you need to research early with target audiences to understand them before you try to solve problems you might not understand.

“But the stakeholders asked for this” is a sad excuse for why we delivered something that failed. Customers didn’t like it or want it, and some might have refused to use it.?

Job descriptions rarely say you will spend every day making what a stakeholder demands, even when that’s a bad idea. Your project will lack strategy, and will be a feature factory of crap we push out even when we know that the product is incomplete or broken.

Yet that’s the reality for too many jobs.

Excuse #5: We will fix it with more instructions or training. Or it just needs some tooltips and how?to’s.

These are common excuses masquerading as solutions for an interface that is failing or likely to fail. Intuitive and well-designed interfaces don’t need teaching. You don’t need a manual that people are unlikely to read anyway.

Adding the clutter of tooltips and instructions to an already difficult interface can worsen it. How often have you clicked on a tooltip, read the instructions, or watched the training video?

If your product isn’t a military system, it shouldn’t have the complexity of a military system. It shouldn’t require training. We love to say, “Don’t make me think,” which means it shouldn’t require thinking. It’s that easy, obvious, and intuitive.

We expect interfaces to be clear, logical, and easy to learn and use without instructions or training. So do your customers.

Conclusion?

These excuses never have to be made when we reduce the size and frequency of our failures. We reduce those when we plan for proper time and money for the desired customer and business outcomes.?

Can your project take four months instead of three? Probably. If your competitor already has something out, rushing to release something low-quality won’t help you compete. If your competitor hasn’t released this feature yet, rushing out your low-quality version might not improve customer experiences, your ability to compete, or your reputation.?

You might even find yourself at the center of a PR nightmare when you have to roll back to a previous version, quickly fix something the media is laughing at, or shut off a feature completely while you figure out why it’s so bad.?

If you released it knowing it was that bad, why did you do that? If you released it and didn’t realize it was that bad, why didn’t you know that? Both deserve investigation and improvement.

Internal teams can pretend they welcome failures. They can make endless excuses and avoid accountability and responsibility. But our experience ecosystem cares. Resellers care when it’s harder to sell what we offer. Customers and users care when they spend their time and money on a product that doesn’t meet their needs or feels broken.

Notice when you are making excuses or hearing excuses. Instead of buying the excuses and nodding along, try pushing back. Why did we have the failure? Not a guess; evidence, data, and knowledge around why and root causes. What can we do differently to avoid failures like these in the future? How much time and money would we have saved if we had spent a little more time and money on avoiding failure?

Connect with me outside of algorithms, absorb more info, or hire me !