Strategy & research
Roadmap: Turning two years of feedback into five features that actually shipped
Two years of feedback had been collected but never connected. The roadmap needed a problem space, not more feature requests.
Context
Over several years, a B2B SaaS product had accumulated a large volume of user feedback. Features were shipping, stakeholders were satisfied, and nothing appeared fundamentally broken, yet the product was quietly failing to deliver on its core promises. The outputs did not match the expectations the product had set for itself.
Challenge
Feedback was being treated as isolated requests rather than symptoms of deeper issues. Without a clear problem space, teams were optimising locally, decisions were reactive, and the roadmap reflected stakeholder requests rather than user or business outcomes.
Approach
I mapped years of user feedback against the product's core promises, identifying where it was failing to deliver on essential expectations and whether issues stemmed from design, engineering, or data constraints. Pain points were clustered under each problem area and synthesised into clear problem statements, first drafted by me, then co-written with product and the business to ensure the priorities that emerged had genuine organisational ownership. This reframed the conversation from "users want feature X" to "we are not meeting the product's core commitments" and fundamentally changed how the annual survey was used: from asking users to predict what they wanted, to validating which proven problems to solve first.
Outcome
The work aligned product, engineering, and the wider business around a new outcome-led approach to the annual survey. Five long-requested features were finally prioritised and delivered within a year, each addressing a validated user problem. Commercial performance strengthened as a result: revenue targets were reached ahead of schedule, churn dropped to minimal levels, and lapsed customers returned quickly.
Reflection
This work showed the value of stepping back before stepping in. The framework was not academic. It was a practical tool designed to make complexity legible to people who were not close to the research. Bringing product and the business in to co-write the problem statements was deliberate: shared authorship created shared belief, and that belief is what turned analysis into action. The clarity did not just improve decision making, it created the conditions for meaningful delivery.
Selected working artefacts from the project. Blurred intentionally to protect business context, shown to demonstrate the depth and shape of the work, not as polished deliverables.