Are you shipping quick wins or quicksand?
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
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
