Marketers don’t use the F word very often. It makes them peevish and erodes their self-esteem.

No, no, no, I don’t mean that F word. Marketers use that one a lot. Like omigod, like verbal hot sauce they sprinkle over everything – more frequently than “and” or “the”. Oh wait, that’s me. But I digress.

I’m talking about F for failure. Failure is a dirty word in some organizations. You’ve all heard some of those old canards at some point in your careers:

“Failure is not an option.”

“I don’t want to hear about any problems, only the solutions.”

“The success of this project is critical to our ________ (financial goals, department’s ability to get budget dollars next year, new product launch, long-term strategy, next bonus payout, continued employment, yadda, yadda, yadda.) ”

“I can’t go into that conference room and tell my _______ (team, boss, department head, rival department head whose project was deep-sixed for this one, Exec VP, C-Level, board, shareholders, blah, blah, blah) that _________ (it’s too buggy to go to market by the launch date, we worked feverishly on a flawed assumption, the strategy was sound but we fell down on execution, the consultants recommended scrapping the project and starting anew, yak, yak, yak.)”

“We’ve spent too much ___________ (money, time, resources, political capital, wah, wah, wah.) on this project to cut bait now.”

Failure is part of nature and part of life, but you’d never know it in some of these misguidedly rah-rah organizations that banish anything that doesn’t smell like success. People in these business environments learn quickly what’s required for self-preservation. They won’t say out loud that they tried something that didn’t work. Why is that?

Fear.  They’re afraid they’ll look stupid among their colleagues, and that will make them vulnerable. Ironically, they end up throwing stupid money at doomed efforts just to avoid looking stupid.

So they deliver an app that’s already obsolete by its release date instead of regrouping and redirecting the money and resources toward the app the company really needs.

Allowing people to admit failure is critical to success. It isn’t an excuse to be lazy, to embark on half-baked or vanity initiatives, to avoid accountability. The person in charge of a failed project is accountable to figure out what went wrong and how the business can use that learning to move on to better things. One never sets out to fail. In fact, if you have nothing but string after string of failures without a winner every so often, there’s a systemic problem. Maybe it’s a resource issue, maybe it’s politics, maybe overall company goals need some realignment. But if you’re never failing, you may be playing it too safe. There’s an old adage in auto racing “If you’re not crashing once in a while, you’re not racing hard enough.”

Some thoughts on avoiding this no-failure-allowed trap:

Be realistic about your odds of success – most businesses don’t have enough time or people to bring everything they want to do to fruition. Working smarter has its limits. When you can only push out a finite amount of product, every initiative becomes critically important – and it’s an easy mistake to mandate that each has to be a winner. That’s just not reality. Some will be black truffles, some will be turds. Making your people call the turds truffles… well, you don’t really want to go there, do you?

An Agile development environment will help you. Its iterative deliverables can help you discover that you laid an egg faster than other development methods – allowing you to rethink, retool, or move on.

Test. Test. Test. You engaged in initiatives on the hypothesis that completing them would improve some business results. Robust and disciplined A/B or multivariate testing will show quickly if your hypothesis is true or false. User testing (real users – not your lunch buddies) will tell you if you got the architecture and design right. Of course, you determined what the success metrics would be before the initiative began, right? Right? (tap, tap – hello, is this thing on?). And you would never be that guy who agrees on the success metrics, and when the test doesn’t support his hypothesis, attempts to discredit the test, right? (tap, tap, tap…)

If the testing shows that the initiative makes things worse and not better, then yes, you may have to throw out some completed work. Yes, it means your idea wasn’t a clear winner. Yes, it means that your development team may not get the validation of seeing their code come to life in production. We’re all grown-ups. If we didn’t have to make tough choices, it wouldn’t be called work and they wouldn’t have to pay us. Okay then. Let’s learn from this and try another idea.

So you didn’t find the black truffle this time. The truffles are out there. And you won’t find them until you pick another tree.