From Competing Ideas to a Research-Driven Roadmap
How research helped a team move from several competing ideas for a new reporting product to a roadmap grounded in how clients actually needed to use it.
The team knew we needed to improve reporting, but there wasn't agreement about what we should build.
There were several ideas about what the new product could look like, and we had reason to be cautious about simply choosing one. An earlier product had been developed largely by putting something into the market and seeing what stuck. It ultimately wasn't widely used by its intended audience.
This time, the team wanted to understand what users actually needed before committing to a solution.
Before deciding what to build, I wanted to understand what reporting needed to do
The initial conversation was largely about reporting functionality. Before evaluating individual ideas, I wanted to understand the larger workflow those features would need to support.
I spoke with the clients who would ultimately use the product, focusing on how they handled reporting today: what information they needed, what they did with it, who they shared it with, and where reporting fit into their existing processes.
That shifted the question from "Which reporting features should we build?" to "What does reporting need to make possible?"
We weren't designing for a single reporting workflow
One of the clearest findings was how different clients' existing reporting environments were.
Some already had elaborate systems, including tools like Tableau. Others had very little reporting infrastructure and would be much more dependent on whatever we provided.
Whatever we built needed to work for both.
Reporting wasn't just for the people using the product
Clients also needed reporting that showed the health and financial performance of their programs in a format they could share with executives and leadership teams.
That meant we needed to think about both the people working directly in the product and the people elsewhere in their organizations who would eventually see the information.
The research became the roadmap
I synthesized the research into a set of user needs and presented them to the product team and leadership.
The product manager incorporated those needs directly into his roadmap, and leadership agreed that each should be addressed.
We had started with several different ideas about what to build. The research gave us a much clearer understanding of what the product actually needed to do.