Turning a reporting bottleneck into a self-service feature

📚 Overview

FusionGrove was an enterprise B2B sales platform helping teams identify whitespace, cross-sell and upsell opportunities across data from more than 50 million companies.

I led the product and design functions as the company scaled beyond its MVP and worked with enterprise customers including Cisco, Citrix and Tech Data.

I was a hands-on lead at the time, but also was responsible for leading a team of two designers and a Business Analyst to deliver every feature & design that was in the platform.

This case study focuses on one part of that work: turning reporting from a manual internal bottleneck into a self-service product feature.

⚠️ The Problem

Reporting had not been a priority in the MVP, which was fair enough. During the early days, core adoption was most important and Customer Success Managers were handling reports manually.

But, as the company grew, reporting became a proper bottleneck.

Customer Success had grown, on average, to spending 40% of their time on reporting. Engineering had tickets in every sprint for ad-hoc requests, taking focus away from core value development.

The awkward part was that growth made the problem worse. More customers meant more reporting, and more reporting meant less time for the team to support customers properly.

🧭 The Product Call

Reporting sounds simple enough, until you get into it.

One customer wants a live dashboard. Another wants point-in-time snapshots every Monday at 8am. Someone else needs quarter-on-quarter comparisons for the North American financial year. Then you add permissions, currencies, timezones, regional calendars, exports, drilldowns and different expectations across customer teams.

The list gets long pretty quickly.

My job was to find the simplest version of the product that was genuinely useful, safe to ship, and flexible enough for us to grow with.

We spent a lot of time with customers and our internal Customer Success team, looking at reports, cadences and repeated requests. Some reports were basically the same thing wearing a slightly different hat. Others were genuinely specific to a customer, region, role or workflow.

From there, I organised our Product approach around a list of key themes. Some of them are below.

🗺️ Roadmap and Phasing

Once we understood the shape of the problem, the next job was deciding what belonged in the first release and what could wait.

Reporting was important, but it was not the company’s main revenue driver. So, I aligned stakeholders around a deliberate approach: ship the smallest valuable version as quickly as we could, learn from real usage, and keep the broader roadmap grounded in what customers actually did next.

The first release needed to remove the biggest manual reporting pains, plus build trust and immediate usefulness for customers. We used this as our chance to build a solid foundation, before layering on more complexity in following releases.

Below is a very light summary of the initial roadmap we took.

🛠️ From Roadmap to Release

With the roadmap in place, the work became much more practical - to turn the reporting strategy into something the team could actually build.

I spent time working through the requirements behind the experience, not just the screens. The module needed to reduce Customer Success effort, support self-service, and still respect the complexity sitting underneath the platform.

A good example was instance-level settings. Reporting had to connect into each customer instance’s geography, currency and calendar settings. Something that sounds simple, like “quarter-on-quarter reporting”, can mean different things depending on whether a customer operates on a North American financial year, reports in USD, or works across different regions and timezones.

From there, I broke the module into the core jobs users needed to complete: creating reports, starting from templates, filtering data, saving views, exporting, etc. I translated these into requirements, user flows and the beginning of design directions, which you can see previews of below.

🎨 Bringing the design to life

Once the product shape was clear, I led the design team in both a hands-on and team leader capacity to bring this reporting logic into an experience that felt simple enough to use.

We knew the product had a fair bit going on underneath: templates, filters, saved views, permissions, export settings, currencies, geographies and so on. We needed the interface to carry and interpret that complexity, without dumping it all onto the user to figure out.

To do this, I brought the team together around a few principles — familiarity, progressive detail and trust. As we explored different design directions, critique the trade-offs and align around a shared decision-making framework. We looked at what each approach made easier, what it made harder, and whether it supported the roadmap beyond the first release.

You can see some examples of the initial sketches of this below.

🏗️ Implement

With designs finalised, I led the implementation process which included:

• End-to-end mockups and prototypes: Building detailed screens for the team to understand the flow and states of each screen & interaction.
• Documentation: Writing detailed product requirements for the engineering team.
• Agile collaboration: Acting as Product Owner to guide development, manage sprint goals, and conduct UAT before release.
• Content creation: Drafting help articles for the new Reports module to support customer onboarding.

I worked closely with the front-end team to ensure pixel-perfect execution and addressed any visual bugs as they arose.