Skip to content
We’ve all been there…looking at a product that isn’t quite perfect, trying to decide whether it’s time to release & iterate, or, timelines and budget permitting, holding off until a few more kinks are ironed out.
It can be a tough feeling releasing a v1 that comes up well shy of the long-term product vision you’ve been imagining. But we all know the value of iteration: “release early, release often,” goes the adage. You’ve got to get that real-world data to obtain the best blueprint for your needs moving forward.
While we, by and large, stand behind this conventional wisdom, there are also some occupational hazards with the early-release model. The most common thing we see organizations run into is pressure to add more and more features with each sprint cycle following the v1 release, prioritizing these more exciting additions over less jazzy (but crucial) investment in the design’s infrastructure. They’re pushed to release something with serious experiential flaws they intend to resolve later on, but those UI fixes keep getting bumped down the list in favor of the shiny new thing that makes for a better press release or sells a new client. Over time, this adding and adding onto the flawed core infrastructure makes it extremely hard (and costly) to make those initial design fixes. Essentially, everything is balanced on a shaky foundation. They know they need an overhaul, but it’s only getting more daunting as time goes on.
This is design debt. And if it sounds familiar, you aren’t the only one.
We’re all sometimes forced to make tough product decisions, making tradeoffs with hard-to-anticipate implications. Figuring out what can and can’t wait, especially when it comes to less sexy usability features, is inherently difficult. We empathize with organizations in a sprint-based world, increasingly pressured to do more with less. If this is you, read on for our tips on navigating this environment while avoiding the kind of design debt that could put your product, or even business, at risk.
Tip 1: Include a fixed phase within your initial scope
Despite knowing that there’s always a need for a course correction after launch, it’s all too common to neglect including a “fix phase” into the initial project plan. This can turn even the smallest, most high-impact tweaks into a hindrance no one has budgeted the time or money for, and lead to the accumulation of design debt down the road.
Simply budgeting a week of post-launch problem-resolution time into the initial project plan will do a great deal to mediate this. Making corrections will feel like an expectation rather than an unwelcome surprise, and the most critical, infrastructure-related issues can be solved before more features are stitched into a framework that will need to change. You can also use that bug-resolution time to socialize the live product.
(Sidenote: it may be worth planning more than a week if you’re releasing something particularly new and unprecedented. And you may be able to get away with less time if you’re releasing something that’s more like a new flavor of something tried and true.)
Tip 2: Make sure you know which features will impress the stakeholders
The goal of every v1 release is different. Sometimes, it’s simply about gathering initial user feedback that will inform v2. Other times, it’s also important to impress important stakeholders — it may be the leverage point that’s needed to gain an investor, inspire some good press, or convince a key prospect to implement at their organization.
All of which is to say: it’s often the case that you need to think about more than just user needs with a feature set…you also need to think of who needs to be sold in order to get the funding to make it to v2. While an inspiring, detailed vision presentation can be helpful, there’s no getting around the fact that you’re most judged on what is. If your v1 doesn’t adequately help stakeholders see value in the vision, it may stall out before you can build on it. In addition to addressing the non-negotiable core user needs, it may also be a smart investment to build out a taste of something flashier and future-minded to help people see, tangibly, where you’re going and buy-in.
Tip 3: Don’t expect infinite patience from your users
Of course, it’s not just investors and strategic partners who will judge you based on what is — it’s also the users. Sometimes, an exciting-enough MVP can generate patience from your user base to resolve bugs and usability glitches along the way. But if you wait too long to fix their pain points, they’re at risk of finding some other way to address their need, forgetting about you, and not coming back.
It can help to stay in touch with end users about bug fixes and feature enhancements, but even the best expectation management in the world can’t negate the need for quick fixes, especially if your product is being used in a high-stakes industry.
Tip 4: Keep a detailed backlog, and share it widely
Another all-too-common way to accumulate design debt is by simply not appropriately logging all the intended fixes and enhancements to a product. Without good documentation of what needs work, you risk not taking full advantage of resources when you finally get the time to make improvements. Product development is a fast-paced world, and even fixes that feel completely unforgettable can get lost amid a new wave that requires your attention and focus.
A robustly detailed backlog may be one of those less exciting, dot-the-i-cross-the-t project steps — but it pays off. We recommend logging not just the fixes/enhancements, but also including a good deal of detail about what the fix would involve resource-wise, projected impact, and how this fix relates to anything else on the backlog (e.g. would implementing one fix change the resources/impact for another? could efficiencies be created by combining fixes? etc).
Once you have the backlog, it’s just as important to make sure everyone stays in the loop about it — your stakeholders, your users, and, critically, members of your own team. Folks who’ve been working hard for the release will typically be invested in its success. They’ll be helpful contributors to the backlog, and they’ll also benefit from the transparency of seeing when (and why) features important to them are liable to be addressed.
At Grand Studio, we specialize in helping organizations prioritize their product roadmap in a way that considers both their current resources and their longevity.
Want to learn how to prevent design debt, or mitigate the debt you already have? We’d love to hear from you.
