G2 is one of the largest software marketplaces where users can compare and purchase the right software. In this project, we will talk about a sub-division of the platform that helps manage your purchased software.
G2 Track is the sub-division of G2 where we offer an online platform that allows companies to connect their software purchases get a financial overview. It also allows users to see when purchases are coming close to renewal, employee satisfaction, and how many employees are actually using each software product. However, one of the biggest need that the platform did not answer to was getting a view on software products that might be duplicates of one another (ie: similar use case). In this project, we will discuss the Overlapping Product experience where we develope a new feature that allows users to not only manage exisitng products but compare similar products. This is perfect with G2 as we can utilize the G2 API on category assortment to determine which products may fall under a similar umbrella.
The Problem
A financial tool isn’t just to see a high-level overview or help plan for future spending, but it is also necessary to help cut spending where possible. That is exactly what is missing from G2 Track. We were able to gather a lot of feedback from user satisfaction surveys as well as internal channels that a big pain point is that there is no way to efficiently cut overall spending. Over 65% of our total accounts have mentioned similar issues and close to 90% of those accounts mentioned the need to pull data from G2 Track and somehow find their way of identifying areas of cost reduction. In addition, we were able to gather internal data that accounts were only NOT reducing in spend, but rather increasing spend over time.
To us, the problem was spot on. So how might we…
Help users accomplish the goal of cutting costs (aka company spending)?
Make it so that users do not have to use a third-party platform to perform these financial discoveries?
Improve cross-team communication so that teams may avoid purchasing similar products?
Business Goals
As a well-rounded financial tool, we wanted to make sure users utilize G2 Track from the beginning to the end of their financial analysis journey. However, in order to do so, we will need to consider ways that we can answer the three HMW statements above. A strong idea that we landed on was the concept of comparing products that may be similar. Especially with G2 having a strong presence in the software marketplace, it is almost without a doubt that we must utilize the data that already exists as means to help differentiate if software may fall under the same umbrella.
Goals:
Improve overall usage /engagement
Improve ourselves as a financial tool by being proactive with financial decisions
Enhance cross-team communication
Help companies reduce spending over time to then help increase user retention
Business Challenges
Now that we have a stronger sense of what needs to happen, we did a high-level feasibility discussion to understand roughly what it will take to make this project happen. Some challenges that we noted:
Product categorization accuracy
Large data structure
Building on top of old codebase
Competitive Research
Before diving into any concepts or solutions, I researched some of our top competitors and how they designed their version of spend tracking and the way they organize/display data.
Figure 1: Competitive analysis of top competitors, Zluri, Zylo, and Productiv.
User Goals
The business goals are simple, we want users to stay in-app so that we can be their one-size-fits-all financial tool. However, on the user side, the goals are much more complicated. Especially when it comes to money, we have to ensure we are providing accurate data that users can rely on.
User Goals:
Ability to accomplish the goals in-app efficiently
Ability to understand what the impact of independent software has on the team using them
Understand the way products are categorized to know what is for which team(s)
Know who the point of contact is
User Research
Now that there is a stronger direction on how we want to design the product spend comparison experience (now named Overlapping Products), let’s jump into user research to better understand the current user journey. I partnered directly with my internal teams (sales and customer success) to set up six 30-minute interviews with various accounts to discuss some of the following points:
Tell me who are the primary members that review/analyze spending on software products.
Tell me what the current process is in evaluating the company’s finances.
What would you say are the benefits of using G2 Track as a spend management tool? Pain points?
What would you like to see more of in G2?
“I like how G2 Track shows all possible software that we have in our system. It helps get a high-level sense of our finances. But when it comes to digging into the details like if it is beneficial to other teams, that’s when things get time-consuming. ”
“G2 Track isn’t a very proactive tool, it just shows information.”
“Would be amazing if G2 Track could help me figure out where I can cut costs, I’m sure we have software that no one uses.”
Personas
Nathaniel Batz, 34
Finance Manager
Manager Type
Watches over the company finances across all functioning teams
Objectives and goals
Manage the company’s finances
Reduce overall spending
Budget plan for all teams
Frustrations
Not enough budget to allocate across all teams
No clear way to determine possible areas to cut spend
Erma Parisian, 35
Engineering Director
Manager Type
A multi-level manager where I have 4 direct reports and a total of 138 reports.
Objectives and goals
Enhance efficiency within the team for strong product launches
Reducing spending within the reporting teams
Provide team with tools as needed
Frustrations
No clear reasons why the finance team rejects purchase requests
Fight for more spending
Product User Challenges
The problem is simple, users who manages company spending is spending way too much time trying to figure out ways to cut back on spend. But it is clear that there is simply no easy way around this besides the traditional methods of asking the team directly or just ignoring the spend altogether.
It is clear what we must do to help solve the user problem of needing a way to make cutting costs easier; design a method that allows users find potential problemed areas and be more proactive as a financial assisting tool.
Current User Flow
Review the figure 2 below to understand what the user journey is when we did not provide any comparing/”proactive“ tool.
Figure 2: Understanding the current pain points of a user finding areas to cut cost
As you can see, a user needs to browse through at least 5 different tabs to analyze the data provided. Unfortunately, it does not guarantee that the user will get everything that they need to make a financial decision. At times, user will have to consult with individuals separately or use any other platforms to help make their next decisions.
Feature and Functionalities
To solve the user needs, here is what must be done:
New data structure that caters to the information that users need to conduct a financial evaluation
Proposed User Flow
A communication tool to improve the clarity on product ownership
Basic product knowledge to help with product comparison
With the new proposed experience, the goal is to make it so that users do not have to browse through many pages to try to see if they can get all the information they need to make a financial evaluation. We also want to eliminate the manual need where users have to contact individuals to get a story of why certain products need to be kept or not. All of that takes so much time, delaying the time for the actual decision.
Looking at the proposed user journey below, we are eliminating:
The need to analyze 5+ software product-related pages to get information on the company’s financial standing
The need to do discovery with individuals separately (outside of the app)
The need to use third-party apps to investigate potential areas to cut costs
Figure 3: The new proposed user flow, eliminating the need to leave the G2 Track platform
Initial Design Explorations
The idea of the new experience is simple. We will simply be adding onto the existing pages within the Dashboard view. In addition, the goals of the users are to compare and find potential areas to cut costs, which shouts dashboard to me. Taking the idea and getting some internal review and buy in, here some well-liked wireframes.
Dashboard Home
Figure 4: The top 3 most well liked dashboard wireframe styles
Product Page
Figure 5: The top 2 most well liked product page containing all data related to one particular software product
User Feedback
After getting good feedback from my internal teams, I reached out to my customer experts again (sales and customer success teams) to organize some user interviews. In this round of interviews, I reached back out to the 6 accounts that I previously conducted user research. The reason for this is so that I can ensure my direction is answering the pain points that have been mentioned. Finance needs to be accurate and I believe speaking to the same group of users will continue on the storytelling rather than create unnecessary knowledge/understanding gaps between us.
We successfully scheduled with 6 of the same accounts, primarily speaking with the financial experts. Each session was about 30 minutes, discussing the initial design direction at a high level and whether or not they think the product comparison concept brings clarity to their needs to discover areas to cut costs.
“The graphs are great, I especially liked the one where you can compare multiple products at once. I think 3 is a good number, maybe 4 at a time could work too.”
“Is it possible to customize the graphs? Adjust time or if I only want to compare 2 of the 3 at once vs all at once?”
“Notifications and alerts are good but not as important as the hard numbers. Does it also give suggestions, for example, out of the 3 which would be the most ideal to keep or end?”
The Prototype
Continuing with the feedback and iteration loop, I finally reached a prototype-ready state for usability testing.
Overlapping products walkthrough
As you may notice, there are 2 distinct entry points that allow a user to get into the overlapping products page. Using the G2 API, we were able to properly categorize different software products into similar categories (ie: Product Management) so that users can easily investigate one category at a time. It shows out of all the potentially similar products, which one costs the most. It also takes into account all the similar software in a particular category and sums up its total spend. A user can then click into the category and activate the modal to select up to 3 products to compare at a time.
We landed on the magic number of 3 by going through psychology research articles and user feedback, the optimal number for comparison that our brains can easily process at once is about 3 items. From there, the platform takes the user to the comparison page where we offer various graphs and data that help our users understand how it’s being used and whether or not it is worth keeping. One of the key datasets that users liked was the employee sentiment section. The idea here is that if people liked using the tool then it is worth keeping more than a tool that isn’t well used even though it may more flexible in usability.
At the MVP, we offer the following datasets for users to conduct a financial evaluation of software products:
High-level comparison cards
Spend over time
Employee usage
Employee sentiment
Ownership matrix that also connect to the email for quick messaging
Usability Testing
Finally coming to the point where we are now ready for customer usability tests. Again, gathering users to interview by partnering with my internal teams where we scheduled 10 users to conduct a 30-minute interview. All of our users that we were able to schedule time were with part of the financial team. Let’s see what some of the key highlights are:
““ love that i is categorized, makes it much simpler to investigate. Would be great to receive suggestions from Track as well.”
“The messaging tool is great, helps me skip a step trying to figure out who to connect with. Would be even better if we comment in-app and see the decision history.”
“This is going to be so helpful! How possible do you think it would be to see what other companies that are similar size as us choose for certain categories?”
Final Designs
Coming to the finale of the Overlapping Product MVP, let’s revisit the importance of this project. The initial goal discussed for users is to essentially remove the need to do financial analysis outside the G2 Track app; specifically for the goal of cutting company spending.
User Goals:
Accurate data on product spending and how it relates to the day-to-day tasks of various teams
Insights on product knowledge to understand which products are categorized as similar
Know who to contact on certain purchased software products
Did we accomplish this? The short answer is Yes. Let’s take a look:
Rather than having to browse through 5+ pages around the entire platform to gather data, we combined a lot of that data into a single dashboard, allowing for a quick and concise investigation
Visuals and summary cards are created for ease of use
Time customization for comparison (ie: This Quarter vs All Time)
Team ownerships are also prominent where users are able to quickly see who is in charge of which software product so that they can communicate as needed
Each software product is categorized in a way that is easy to understand (ie: Spend Management vs Productivity) and the product page of individual products has details so that users know what it is used for
Single Product Homepage
Overlapping Product Dashboard
Comparison Modal
Product Categories Page
Owner Email Invite
Engineer Handoff
The engineering handoff was quite smooth! Since we had biweekly PDE (product, design, and engineering) syncs, it really made the final handoff a breeze in the park. I spent about 3 days presenting my new designs to the engineering team and diving into all the details of each component, prioritizing what the must-haves vs nice-to-haves are. All in all, engineering accepted all of the components in the mock-ups and began development while I continued on as the design consultant.
Launch and Metrics
The engineering handoff was quite smooth! Since we had biweekly PDE (product, design, and engineering) syncs, it really made the final handoff a breeze in the park. I spent about 3 days presenting my new designs to the engineering team and diving into all the details of each component, prioritizing what the must-haves vs nice-to-haves are. All in all, engineering accepted all of the components in the mock-ups and began development while I continued on as the design consultant.
How will we evaluate this project as a success or failure? Let’s take a look at our initial business goals:
Improve overall usage/engagement (increase time spent in-app)
Improve ourselves as a financial tool by being proactive with financial decisions (number of page clicks/logins)
Enhance cross-team communication (number of email invites sent)
Help companies reduce spending over time (decrease account spending and user retention)
Launch Plan:
We released the Overlapping Product feature using the A/B method where we randomized 50% of our total accounts to have the feature turned on for the first 2 weeks and then the rest after.
Results
The results were phenomenal and higher than what was predicted!
Results based on 3 months following the full 100% release (average per account):
Time spent in-app
Prediction = increase by 6 hours/week
Actual = increased by 10 hours/week (data showed that users clicked more on other pages as well)
Number of clicks into Overlapping Products
Prediction = 10 clicks/week
Actual = 17 clicks/week
Number of email invites sent
Prediction = 5 emails/week
Actual = 6 emails/week
Account spending (compared to the previous month without Overlapping Products)
Prediction = decrease by 15%
Actual = decreased by 21%
Next Steps
The MVP is just the beginning of Overlapping Products. As we continue to follow the direction of optimizing products and reducing company spending to essentially give the budget back to the teams, there is still plenty of room to improve. Some of the important areas to consider for version 2 are:
Allow further customization of the datasets that users use to compare (ie: tool use vs team size ratio and renew price compare)
Offer recommendation
In-app messaging/comment system to keep track of past decisions
Message tagging (mentioned a handful of times, similar to Google Sheets/Doc)
If I had to prioritize, offering recommendations and/or showing how G2 Track would analyze and choose would be a very helpful tool. This would be a closer representation of how we can be more than just a tracking tool but rather a financial assistant that is proactively helping you reduce costs.
What I Learned
Our platform had a lot of old code that was previously ignored causing a lot of difficulties when we tried to pull certain data out and recreate it until what we see now in the new dashboard experience.
Another really important fact that I discovered was that investigating company spending isn’t as simple as pushing in the numbers or analyzing which tool has the most sub-tools to make tasks easy. It also encompasses the habit of how users have incorporated the tool into their daily tasks. The saying “as long as it gets the job done” can be quite true at times even if in the naked eye, it may be deemed as a lesser tool.
By offering a more direct communication method within the app and the ability to clearly see who is the owner of which software product, users were able to reduce almost 2 hours used just digging for this information.