There’s a meme floating around the internet depicting scenes of 80s and 90s TV and movie characters sinking in quicksand. Over the image reads, “When I was a kid I thought that quicksand was going to be a much bigger problem than it is.” Wesley and Buttercup, the Ninja Turtles, Larry and Balki, Atreyu and his horse Artax — in a scene I still can’t watch — all tell the perils of encountering this colloidal earth. The hero unknowingly stumbles in and is nearly consumed by the ground. Without some MacGyver-like savvy, they become trapped and will surely perish.

Lucky for us, quicksand is not as ubiquitous as popular TV made it out to be. I rarely worry about coming across such deceptive and treacherous terrain, with one major exception. And not to be dramatic, but that exception is in product development.

The product trap

Early in my career, I worked for a company with a product that had a large amount of inventory and content to manage. A member of the marketing team had come to us asking for help: they wanted to increase traffic to a page because customers couldn’t find it. They asked us to add the page as a top level item in the navigation. This seemed like a fair hypothesis: if we made the page easily accessible and visible from the navigation, more customers would go there. It was a quick win, except it wasn’t. This product was already bloated, and there were three different forms of navigation trying to route customers to the right content. There was a top navigation where each item had a subnavigation. There was a left navigation used for “quick links” to commonly visited places, of which there were many, and a utility navigation in the footer. All told, there were over 100 items in the navigation our customers had to parse through and choose from.

It was pretty clear that even by adding this page to one of the three navigations, we would not solve the problem of too little traffic. We would, however, add to the cognitive load of customers already struggling to find their way through all the noise. Instead, we decided the best path forward was to add a cross-sell promotion into an existing email campaign that would direct customers to the page. It was still a short-term solution, but one that wouldn’t contribute to the existing problems with our navigation, and it would give us time to solve the harder problem: the information architecture of the site. And it worked, we increased the number of customers visiting that page.

Quicksand happens when well-intentioned teams are trying to move too quickly or do too much. In their effort to make progress, they look for the quick win. A quick win is a problem that is easy to identify and solve, giving it a high ROI. Looking at a 2x2 of effort and value, they sit in the ‘low effort, high value’ quadrant. Quick wins are appealing for obvious reasons: they enable teams to achieve a specific goal relatively easily and cheaply, and who doesn’t want that? In reality, however, quick wins are much rarer than we think.

Product quicksand, on the other hand, is everywhere. It’s a dubious solution masquerading as a quick win. It creates the illusion of solving a problem without the result of actually doing so. In fact, the result can exacerbate the problem, leaving you more entrenched in the status quo than when you started. Not only does your team become trapped by quicksand, but so does your product, and worst of all, so does your customer. In the end, you’re left vulnerable to encroaching and nimble competition while your team tries to wrestle your product free.

In order to provide your customer with a good experience and keep your product running smoothly, it’s important to be able to identify it. Here are a few different things to consider when evaluating if you’ve got a quick win or quicksand.

Quicksand

1. Relies on shortcuts. Teams often have to cut scope, ship incomplete experiences, or shoehorn a solution into an existing, but incorrect, pattern or component in order to make it cheaper to implement.
2. Values output. These teams derive their success from shipping something vs. solving the problem. What’s often missing is an incentive to measure the impact, without which they have no way of understanding how effective the solution was. Absent tangible outcomes, teams have nothing but the launch to celebrate.
3. Is expensive. This is because it is often a deviation from the long term strategy, or maybe there isn’t a very solid long term strategy to begin with. The result is a reactive strategy with little detours to the roadmap; time that is taken away from solving problems meaningfully. And, since quicksand relies on shortcuts, it’s probably adding tech and UX debt to the product that will add to overall maintenance costs. And, because the impact is not measured, well, there is no ROI to bank.

Quicks wins

1. Use experience as an accelerator. Teams solving a quick win do so because the problem is familiar, which means there are fewer unknowns to derail the team. They are able to leverage past learnings, existing patterns, and the right components to expedite its resolution.
2. Value impact. Teams that are solving problems well need to know they are solving problems well. They invest time in understanding the problem and identifying the signals, quantitative and/or qualitative, that will tell them they are on the right track. If they aren’t on the right track, they correct their course.
3. Pay dividends. Quick wins often buy the team time because they align with the overall strategy and get teams one step closer to realizing it. They are often short-term fixes in service of the long-term goal.

Product quicksand is everywhere and we all find ourselves stuck from time to time. The best way to stay out of it is to never fall in. But, if you do find yourself sinking, take a page out of a quicksand survival guide: stay calm, move slowly and deliberately to break free.

Sarah Babetski is a Product Design Leader at Gusto. She thinks and writes about the humans using digital products to live their lives. She is not a wilderness survival expert.

Are you shipping quick wins or quicksand? was originally published in Gusto Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

Enough with ‘Fail Fast’ already was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tell me if this sounds familiar:

A new idea for a product starts making the rounds on your team. The idea sounds smart. You have alignment from stakeholders. The team is excited to work on it. The best and brightest are put to work for days, weeks, months designing and building this new idea. You can’t wait for the world to start using it. Launch day comes and goes. You celebrate all the hard work and late nights that went into getting to market so quickly.

Then something doesn’t happen…the numbers don’t show up; adoption isn’t growing, you’re not hitting your targets and people aren’t using the features you’ve invested months developing. The product must be a flop; logically, you start phasing out support. You may even discontinue the product and move your best and brightest onto the next and newest. Silicon Valley has been telling us to fail fast for what seems like ages now, but did we? And what did we learn?

The problem

Countless organizations jump directly from project kickoff to a fully fleshed out design of a new solution without researching user needs or validating ideas. But when you don’t know what your users truly need to do, you end up building for everything they might ever do. Or worse, everything they might never do. The result is often an over-architected solution that took months and even years to develop, only for it to never really take off. Quantitative data is compiled and analyzed, but we’re still left scratching our heads asking ourselves “where did we go wrong?” Without proper user research, you can’t really understand why your product failed, only that it has.

Let’s think about this another way using a well-known analogy. Imagine that you need a new car, what would you do first? Well, you’d probably figure out what you needed it for. Do you have a long commute? A family of four it needs to seat comfortably? Pets? Gear for sports and recreation? Once you’ve figured that piece out, you’d ask yourself what’s important to you: reliability, reputability, flashiness, new or used? From there you’d likely start to research your options online. You’d talk to friends and family about their experiences with their cars. You’d ultimately find an option that meets your criteria but also fits your budget. You would test drive it. On the contrary, you would never walk onto a lot and drop even $10k on a car you’ve never seen or done any research on and hope that it just works out. So why drop hundreds of thousands of dollars on a product when there’s little understanding of its viability?

Design thinking fills fundamental gaps that many organizations have: it helps teams better define the problem they are solving for, sheds light on what their audience truly needs and relies on user-centered design practices to make sure the right solution is created. Design thinking offers tremendous value by de-risking products and empowering teams to make a go or no go decision based on empirical insights — so why aren’t we all using it? Many of us are pushed to deliver faster, meet increasingly shorter deadlines and get to market quickly for fear of being left behind — all the while short on resources and budget. And even though the long-term benefits of design thinking are indisputable, the upfront time and commitment needed for research, testing and iteration can seem daunting for those of us feeling pressured to deliver.

The Solution

Tendril embraces experimentation at all levels of the organization, so to ensure we’re doing our due diligence for users while working quickly, we’ve started using Design Sprints — a process that is meant to capture all of the wonderful benefits of design thinking in just one week.

Developed by a few folks over at Google Ventures, a Design Sprint is a five-day exercise that helps companies solve big challenges in a small amount of time. Their findings and step-by-step instruction for running a Design Sprint can be found in their book, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.

Photo credit: http://www.gv.com/sprint/

With Design Sprints, we’ve been able to identify things like what product features are must have versus nice to have and how to mobilize our teams around the right initiatives. And don’t let the term ‘Design Sprint’ fool you — this method can be used to solve just about any business challenge. And, bonus, you don’t need to be a designer to participate.

At Tendril, we often hear about how our utility partners want to find new ways to engage and delight their customers, but keeping up with customer expectations is often a challenge. For utilities looking to quickly prototype and test new engagement strategies, Design Sprints can help answer a lot of important questions without being delayed by regulatory, time or budgetary constraints.

How it Works

Your Team

To run a sprint, you’ll need a small (no more than seven people), cross-functional team. There are a couple of defined roles you’ll assign, such as the Decider — any time a decision needs to be made, they make the final call — and the Facilitator — they keep the team focused on the process. You’re encouraged to include experts from varying facets of your company: marketing, customer service, finance, tech, creative, etc.

One of the best people you can and should include is the person most likely to pushback against your project. Sprint refers to this person as the Troublemaker. Including them will make it easier to get their buy-in and may even give you valuable, contrarian insights to the problem that the rest of your team wouldn’t have come up with.

Your Schedule

The sprint is scheduled across five days, concentrating on a new initiative each day.

Monday: Goal Setting

You’ll start by setting your short and long term goals, identifying a specific target to focus on and turning potential risks into questions. For example, “Customers may not understand how to use our new mobile app,” becomes “How do we make sure customers understand how to use our app?”

You’ll also conduct expert interviews that can vary from internal stakeholders to partners, customers and other third party players.

Tuesday: Research and Sketch

You’ll spend the second day looking into how other companies are successfully solving for your challenge. This could include companies both within and outside of your industry. For instance, if your utility is looking to help customers better understand their bills, you might look into how other usage-based services present billing data, such as mobile and internet companies.

Next, your team will sketch out ideas to solve to your problem. Using a multi-step approach, you’ll look at all of the notes taken during your expert interviews and inspiration research, jot down initial ideas and perform a few iterations of sketching. You’ll end up with fairly concrete ideas to vote on the next day.

Wednesday: Vote & Storyboard

The team votes on which sketch or sketches to move forward with and storyboards them into a solution. Storyboarding helps find points of contention and questions that need answering as you head into prototyping.

Thursday: Prototype

Since you have one day to do this, the goal is to make the prototype is realistic as possible without spending too much time developing it. The authors of Sprint refer to this as “Goldilocks Quality.” For instance, let’s say your solution is a better way to show customers their energy usage within your customer portal. Instead of trying to get something coded and operational within a day, you can simulate the experience using slides. And don’t be fooled into thinking this is a designer task, every member of your cross-functional team will play an important role in prototyping.

Friday: User Testing

You’ll use a small sample size to test your solution with real customers. Consistent with Nielsen and Landauer’s testing methodology the Sprint authors recommend testing with five users to find the major flaws and strengths of the solution.

Keep in mind that your job this week is to be wrong. It’s not a good feeling, but it’s something you need to become accustomed to. The first thing you build is going to be somewhat wrong, and the user feedback you receive Friday will give you the direction you need to keep moving with minimal investment. You’ll walk away with invaluable insights, immediate next steps and action items for your team.

Lessons Learned

Every sprint we’ve done so far at Tendril has been a flawed success. Sometimes our ideas are proven to work, while others fall flat. Either way, we gain insights and learnings that would otherwise take us weeks or even months to uncover. We recently ran a Design Sprint to improve our Engagement Portal. In this particular sprint, we had three big feature ideas. After our one week Design Sprint we discovered that two out of three ideas completely bombed. And that’s great for us because it’s two fewer features to build only to never be used.

Since we’ve started running Design Sprints, we’ve noticed something else change in our organization. There’s a greater sense of team camaraderie. Having gone through a rigorous design thinking process, Sprint teams are more confident in their solution and are proud of the outcome. There’s greater alignment since they have all met with stakeholders and experts, been instrumental in making strategic decisions and have heard from the users themselves. It’s a less quantifiable outcome, but no less meaningful for an organization.

Conclusion

Because you have the focus time and the right people in the room, Design Sprints condense what could take weeks of many meetings with many of the same stakeholders into five days.

A Design Sprint takes every potential weakness of traditional product discovery — not asking the right people, having the wrong requirements, going off on tangents, overthinking a solution — and turns them into strengths. The structure ensures experts are consulted, the problem is well defined and there is no time for tangents or over-analysis. So the next time you’re faced with a new challenge, take five days and run a Design Sprint, you’ll be amazed by what it could save you.

Turning Challenges into Opportunities with Design Sprints was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.