Enough with ‘Fail Fast’ already
And other platitudes to abandon in 2019.
In the age of Ted Talks, Youtube, Medium (hey-o), and entrepreneurs with cult-like followings, there’s no shortage of wisdom that can be turned into a soundbite. These pithy statements once helped us succinctly grasp an abstract concept and readily share with our colleagues and peers. They helped move us forward and evolve our thinking. They made great wall-art around our offices. But like all games of telephone, the original message was lost long ago, victims of misinterpretation. Now rendered devoid of true insight, we find ourselves feeling emptier and emptier each time we repeat them. So I’m kicking off the new year by kicking three of the most overused and abused phrases out of my vocabulary.
1. Fail Fast
How it was intended: Fail Fast was adopted by startups, large corporations, and product R&D teams near and far with the goal of minimizing cost while still gaining valuable feedback on the potential viability of products. The idea of building* quickly, showing your product to users, and gaining feedback so you can pivot sooner sounds noble, right?
What it’s become: What product teams, managers and execs say when something has failed but no one really knows why. Pressured to deliver quickly, teams are often required to forgo reasonable product discovery, testing, and other forms of validation in order to deliver the thing. What’s worse, this approach is absent iteration. Meaning, it’s absent mile markers that could have signaled when and why your approach wasn’t working and afford you the opportunity to correct-course. Instead, you get to the end (having still invested probably months of work) and you’re left with something unsalvageable because you don’t know any of the specifics surrounding its failure. It’s the antithesis of failing fast. Sadly, we don’t even realize we’re guilty of it most of the time.
What your team needs instead: Honest dialogue and early alignment on what failure looks like, how you’ll measure it, and how you’ll address it throughout all phases of the product development lifecycle. We naturally love to dream big and envision all the ways we’ll be successful and change the world. Unfortunately, when it comes to discussing all the things that could go wrong we get scared and avoid it because it’s uncomfortable. But, this is a crucial step in fleshing out your overall product strategy; one that empowers you to see red flags early and mitigate as needed. Engage your UX team — armed with a number of research tactics and tools, they can help you develop a plan for gaining answers to the scariest questions before a single line of code is ever written.
*One of the biggest misconceptions I’ve seen is our shared understanding of “build” i.e. it doesn’t exist. Too often, “build” comes to mean someone is writing lines of code. This is legacy thinking, as it could (and should) now refer to any artifact that illustrates thought given to how the product should work. This could be rough sketches from a Design Studio, a paper prototype, wireframes, or a high fidelity prototype. Anything that you can show users and get feedback on is “build” work. So when you hear “Build, Test, Learn,” you can see how that would result in very short iteration cycles that supply continuous feedback.
2. Work smarter not harder
How it was intended: Boost productivity without boosting burnout by eliminating redundancy and churn, focusing on what matters most, and delivering against those objectives.
What it’s become: Teams’ go-to excuse for taking shortcuts. You can justify skipping entire phases of the product development lifecycle as long as you deliver something that sounds sort of like the thing you were contracted to deliver. You eliminate stakeholder check-ins if you think their feedback will derail your progress toward delivery. Don’t feel like scheduling that meeting? Just send a lengthy email in the hopes that each person you send it to will take the time to read it, interpret it exactly as you intended, and walk away with a mutual understanding of the thing. Smarter! Not harder! Except, you skipped an important phase in the product development lifecycle and it created issues farther down the line that you now need to correct. This results in nearly twice as much effort being expended as you would have if you had just done it right the first time. The stakeholder you were trying to exclude bungee jumps in at the worst possible moment because they haven’t been kept informed about the progress. That email you sent? It further confused your team and so you have to schedule the meeting (the one you didn’t want to have to begin with) and spend the first half hour discussing the email before you can even discuss what you really needed to.
What your team needs instead: By all means, eliminate redundancy. Create enough process to support people in their roles; enough that they don’t have to do endless amounts of invisible work (like chasing down stakeholders or scheduling meeting after meeting because they’re not sure who needs to see what and when). That type of work only prevents them from doing what they were really hired to do. But, also cultivate an environment where people come first, where team members have empathy for one another, and where their time and contributions are respected and valued every day. Be an efficient machine without being machines.
3. Don’t let perfect be the enemy of done**
How it was intended: Perfect is an elusive, ever-changing target. If you focus on perfect, you will never feel ready to launch your product/site/business and will be trapped in a vicious, perfectionist cycle. Be brave, launch sooner.
What it’s become: Another attempt to thwart necessary steps in favor of short-term gains via shortcuts. I’ll be candid, I’ve heard this one directed at designers a lot, though not exclusively. It usually comes from some well-intentioned individual who doesn’t quite understand or appreciate the value UX designers bring to the business. What may appear to be a pretty color swap on a button when tapped actually provides valuable feedback to the user that they have successfully performed that task. Providing inline form errors with microcopy shows users where the error is and tells them how to fix it. It’s these “little” design decisions that, when needing to be developed, often get negotiated away because they would take too much time to implement the way it was designed — but the consequences are an interface that is often a lot less usable. And these “little” negotiations can really add up to a product that’s wholly unusable.
What your team needs instead: A different definition of “done”. Oftentimes, you hear this phrase in the same sentence as MVP, which has somehow come to mean that an incomplete experience is totally fine. It’s totally not fine. If your user can’t use your product, i.e. complete the task they want to in a reasonable amount of time, then you’ve failed to deliver value to them. Use metrics (task success, time on task, satisfaction score, etc.) to evaluate how your solution performs. Then, hold yourself accountable to them in your definition of “done” (see: 1. Fail Fast).
**Variations include but are not limited to: don’t let perfect be the enemy of good, don’t let perfect be the enemy of good enough, perfect is the enemy of good.
Those are the top three that I’ll be on the lookout for this year. What are some of yours?
Happy 2019!
