Topics
March 5, 2026
.png)
March 5, 2026
Picture this: It’s planning season, and your product and engineering partners already have a roadmap draft ready to go.
Meanwhile, you’re the sole product designer (sadly without much formal research support), trying to keep up with in-flight work. You’re focused on hitting deadlines, not running the kind of comprehensive research that shapes what comes next.
There’s plenty of opportunity to improve the user experience, but only a handful of roadmap projects truly address it. Your colleagues value UX input (thankfully), but time is tight, and the roadmap is already drafted. In the end, you squeeze in a feature or two, but the bigger opportunities will have to wait.
Sound familiar?
That’s been my usual experience during my organization’s planning cycle. Teams rush to finalize the roadmap while juggling existing deadlines, and when things move fast, critical user insights often fall through the cracks.
This planning cycle was different, though. Our UX team and I were able to re-center the user on the roadmap, significantly reduce user frustration in our product area, and ultimately reduce client churn.
Instead of scrambling to include user insights when the planning cycle is underway, this year we tried something different.
Approximately three months before planning, we began discovery research on a new internal platform.
I initially proposed collecting a SUS score on the current platform so we could measure our progress over time. Instead of just sending out a survey about hypothetical experiences with our platform, our principal researcher suggested we do a usability test with real tasks and follow- up questions, so users would reference a concrete experience with our platform before scoring it.
This was ultimately a game-changer for us. Collecting this qualitative, accurate feedback from our actual users paid out dividends in the end.
To run these studies, I took the lead with the actual testing while my product counterpart took notes. Her boss also joined for a couple of calls.
Then, instead of going back to our silos to implement this feedback, my product and research counterparts worked together in FigJam to cluster and theme user feedback from five different sources.
I also want to highlight that we involved our product partner throughout the entire process.
While it felt tedious and manual at times, I strongly believe that…
To inform these themes, we used prior research, both from discovery interviews and our usability testing, as well as the product team’s typical source of truth for the roadmap (Salesforce and bug reports).
This allowed us to cover both the admin and employee experiences in our feedback, since most employees only submit feedback through that last channel.
Throughout the process, all of the stakeholders were involved. Engineering managers, principal tech leads, group product managers, senior product folks, and UX leadership and research. What I found to be most valuable was one of our engineers interpreting some of the feedback, since he had a deep knowledge of the legacy platform most of us didn’t.
And what did we find in our very first UX benchmarking study of the current platform? The lowest SUS score I’ve ever seen. We received a D. 😂
Because of this (and the cross-team involvement in the usability testing), we didn’t have to convince product or engineering—both at my level and in leadership—to shift their roadmap proposals to account for this new data. Immediately upon seeing this abysmal score and reading real user quotes, they decided to shift the core focus of the upcoming year’s roadmap. We went from focusing on adoption to “stopping the bleeding.”
This meant retaining clients who were ready to leave due to their poor experience with our platform, as well as finally prioritizing tech debt that was causing the system to unpredictably time out or fail at critical points.
Because of these cross-team usability tests, we had so many user insights that our new roadmap went years into the future (when we normally only plan six months to a year ahead).
The team is currently working on delivering a better notification and error message process for our legacy platform and addressing tech debt. Meanwhile, I’m working on designs for the future state deliverable. We plan to work on a better consolidated dashboard experience in the next quarter that will work for both experiences, in addition to addressing numerous other themes from user feedback.
We’ve also gone our first month without losing any clients due to the old platform’s issues, which is a huge milestone for us!
When we carved out space for user insights, everything changed. Our roadmap shifted, client churn decreased, and the financial impact was immediate—and that was just from our initial wave of usability testing. Imagine how much more we can improve by implementing UX even more throughout our process?
I want to encourage everyone to continue to advocate for as much user research as you can possibly do—even outside of the planning cycle. Think in advance of how it might be able to impact what you work on in the future and why. You may not get to run every single study you’d like to help users prioritize the future roadmap, but you can still use a lot of the data you already have to inform it.
This single usability study over a few weeks shifted the focus of the entire team to center the user experience in future decision-making, not just for net new experiences. In some ways, compiling our research also shifted the team’s mental model to understanding the reason why we still needed to invest in our current software.
While that legacy experience may change in the future, there’s a lot of important work to do now, too. Together, we set a precedent for collaboratively creating a roadmap that actually prioritizes the users’ needs first.
Looking back, the timing was serendipitous. We couldn’t have predicted this impact, but it’s a valuable lesson learned. Making time at the beginning of a project for research beyond just your initial deliverable pays off exponentially over time. We won’t have to run another study before the next planning session because it’s already scoped, and we can instead continue to do research for our specific features we’re building.
This experience permanently changed how I think about when research has the most leverage.
Have any of you encountered similar difficulties with planning? How did you influence the roadmap? I’d love to hear it! Reach out to me on LinkedIn.
