Spare project

FusionGrove provides sales teams with enterprise B2B sales teams selling technology products with a SaaS platform.

The platform provides salespeople with analysis of a customer's past purchasing behaviours (or lack thereof) against their actual technology usage patterns visible on their applications to uncover whitespace, cross-sell or up-sell opportunities. Recommendations are then made on which technology areas are most likely relevant to a customer, alongside which people within the organisation are the likely decision makers and hence should be focused on.

I joined FusionGrove as their first Product hire, working with the company for over 5 years – from their first MVP to market, right through to being used in over 5 countries.

While I worked on hundreds of projects during my time, one to show here is the introduction of the Reports module to the platform.

🎯 Objectives

During my time at FusionGrove, I spent a lot of time supporting our Customer Success team on product-related initiatives. A key issue within our internal workflows was the amount of time that was being spent preparing report for our larger enterprise customers, who each had very different needs and reporting schedules.

A rough estimate was that 50% of CS time was spent on reporting, as well as an endless stream of questions around customising or updating reports as time went by.

I pulled a range of insights together and pitched to leadership that we focus on two new problem statements:

Customer Success spend roughly 50% of their time preparing reports for customers. How could we free up some of this time for CS to focus on higher-value activities?

Many customers want to create or customise their own reports, without the need of contacting us to help. What would a self-serve reporting setup look like for customers?

After presenting my problem, strategy and thoughts to the leadership team, we eventually committed to discovery on the best ways to solve these issues.

🔎 Research

I did a lot of discovery on this topic via working in our Customer Success team for a few days on reporting tasks, as well as chatting with customers that came through email with report requests or queries.

Some key points that I discovered were:

• Reports needed to be sent out on a set, periodic basis to meet our customer's business cadence needs – for example, every Monday a customer might want report A, but on Friday they wanted report B.
• Customers often asked to update or change who receive reports – more often than not, more than one contact wanted to receive a report! Managing distribution lists became a tricky task, especially when requests often went to a CSM's direct inbox.
• Customers wanted point-in-time reports, but frequently asked for "live" dashboard-style reports – this was a technology barrier we faced and struggled to solve for due to disparate databases
• Every report, and every customer, was different – some customers wanted a Salesperson-based report, some wanted a Campaign-based report, some wanted all fields and some wanted very little. This meant a cookie-cutter approach was hard!

I collated all of this information into a research report and made some key recommendations on areas to focus on, which were reviewed with leadership and slightly tweaked based on resources and timelines.

💭 Ideate

With the bulk of our research done and clear areas to hone-in on, I started to dive into how a Reports module might look in terms of its information architecture.

I referenced a lot of other popular Enterprise SaaS products in-market – Salesforce, Zoho and more – in order to see how they handled this. I put together a nice collection of inspiration and screenshots on how they handled key flows.

I did a few card sorting exercises internally to see how people arranged information, and used this to form the basis of the Reports skeleton to test with our users.

From there, I began to sketch out key flows and look at what considerations needed to be within that report. I decided to focus on all the considerations we found from our research, even though some may not be built on day 1, in order to show the skeleton could support these down the track.

After rounds of internal reviews and discussions, I wireframed key sections of the platform and made sure all of my research appeared within the skeleton ideas. I iterated on these wireframes through to higher fidelity designs that served as the basis for a clickable prototype.

🎪 Test

After landing on a place that I and stakeholders were happy with, I decided to pull my prototype into Maze and test whether my key user journeys could successfully be completed by some of our friendly customers.

For the large majority, the flow worked successfully – but, like any good testing, we identified a few minor tweaks to make to really bring some key functions to the surface to bridge that last 10% of usability. Such things included:

• The use of the word "schedule" instead of "subscribe" – we changed the name of the feature to be "scheduling" a report, instead of subscribing.
• Hiding detailed filters behind a single "Filter" button – some users found presenting all of the filters when landing on the page to be a bit much (given the degree of detail)

🛠️ Build and outcome

Once discovery and designs were complete, I led the process of documenting the product requirements documents and briefing the engineering team on what needed to be done.

I played the PO in the Agile process and guided the team from kickoff through to UAT and a smooth production release. I worked closely with the front-end team to ensure that designs were implemented correctly, and any visual bugs were ironed out.

While the team was deep in development work, I took the time to begin writing the Help module's articles on how to use the reports section for anyone that needed it.

Overall, the launch of this feature was a success. A month after launch, we saw:

• Customer Success were generating 80% less reports, allowing them to focus on higher-value activities
• A reduction in email requests for reports by 25%, thanks to an in-app announcement about the new feature for all users on their next login
• Around 65% of customers were generating at least 1 report per month