Case Study
Improving Market Fit: From the Field to the Roadmap
I built and owned a process for turning recurring customer and prospect friction into product proposals that could be challenged, prioritised and moved into Engineering.
- Product & Market
- Technical Sales
- Communication
The Problem
Sales and Engineering naturally saw different parts of the product.
The commercial team saw prospects hitting it for the first time: where they got confused, which requirements kept coming up, what slowed down a trial and what could stop a deal completely.
Engineering had a different view. They understood the architecture, dependencies, development effort and everything else already competing for roadmap space.
Both views were useful, but a lot could get lost between them.
A feature request mentioned in one call could disappear. Another could get repeated loudly without much evidence behind it. Sales often had little visibility into why something had been rejected or pushed back.
I was already sitting between those two groups, so I built a better route between them.
Why It Mattered
Repeated friction in a sales cycle can tell you something important about the product.
A missing API method might block several implementations. A confusing workflow can make a trial much harder than it needs to be. A fairly small product change can sometimes unlock an entirely different way of using the platform.
But a prospect asking for something doesn't automatically make it a good product decision.
The useful work was figuring out whether the issue kept appearing, what commercial effect it was having, whether the proposed change actually solved the underlying problem and how it fitted with the rest of the product.
The Insight
The field shouldn't dictate the roadmap, but it should inform it.
I didn't want to forward feature requests into Engineering and call that product feedback.
The proposal needed enough context for someone who hadn't been in the customer conversation to understand what was actually happening.
That usually meant answering a few basic questions:
- What is the problem?
- How often are we seeing it?
- What is the commercial impact?
- Is the product actually the thing that needs to change?
- What would a useful solution look like?
From there, the idea could be challenged properly.
What I Did
I created and owned an Asana Product Board specifically for improvements coming out of the field.
It wasn't a bug tracker. Bugs and routine technical issues kept going through the normal Engineering process.
The board was for deliberate product changes.
For each proposal, I documented the problem and why I thought it mattered. Depending on the case, I added prospect feedback, examples from trials, commercial context, screenshots or HTML mock-ups showing how I thought the experience could improve.
I also tagged proposals by things like impact and effort so we had a consistent way to discuss priority.
I reviewed the board with the CEO every week.
Sometimes that meant making the case for something I thought was being underestimated. Other times the proposal got challenged and it became clear that changing the product wasn't the right answer.
The stronger proposals then moved into monthly roadmap discussions with Engineering leads.
At that point, the question changed from “is this worth solving?” to “how does this fit with everything else we're building?”
Approved work moved into GitHub for implementation and stayed linked back to the Product Board so we could see where it came from and what happened to it.
What Moved Through the Process
The proposals ranged from small API changes to work that supported much larger product initiatives.
Examples included:
- exposing capabilities through the JavaScript API that had previously only been available through the product interface;
- more granular programmatic role allocation;
- capabilities needed to support reusable Webfuse templates;
- one-click template importing, reducing the work needed to move from a pre-built solution to a working environment.
Some were small changes with an immediate effect on live implementations.
Others became building blocks for larger pieces of work later.
The important part was that there was a clear route from something we were seeing in the field to something Engineering could assess and build.
How It Worked
The process was cyclical rather than a one-way handoff.
I proactively collected feedback from my own demos, trials and customer conversations, as well as from the wider Sales team.
When the same issue started appearing more than once, I would turn it into a proposal with enough evidence and commercial context to make it worth discussing.
The CEO added the strategic and commercial challenge. Engineering added the architectural context, dependencies and implementation reality.
If something was approved, it became tracked work. If it was rejected or deferred, there was at least a reason rather than the request simply disappearing.
Once something shipped, I could take it back into real trials and deals and see whether it actually solved the original problem.
Then the loop started again.
Impact
Around 10 proposals per quarter progressed into Engineering, with more than 30 resulting GitHub tickets tracked back to the Product Board.
Some were small, commercially useful changes. Others supported larger pieces of work around reusable templates and one-click installation.
The bigger improvement was that product feedback stopped being a collection of disconnected conversations.
Sales had a proper route for raising recurring problems and could see why something had been accepted, rejected or deprioritised.
Engineering got more than “a customer asked for this.” They got the problem, examples, commercial context and whatever evidence I had collected.
This became a big part of my Lead SE role.
I was close enough to the deals to see where the product was getting in the way, technical enough to understand what was actually missing, and senior enough to get the right people into the decision.
My job was to collect the signal, frame the case and keep the loop moving.