As individuals, we notice that a lot of products that we use undergo a complete makeover from time to time. As Product Managers, sometimes we propose that makeover and execute it as well. This is more frequent than we realize. In this post, I want to share some learnings from the time when I got the opportunity to do the same for our most used product area - Reports and Dashboards in Gainsight.
Typical product makeover can be either a
“Redesign” or a “Refresh” - Where we change the design and user experience of a product or a
Complete “Revamp” / “Reimagination” - Where we change the core constructs that make up the product
As a Product Manager, this is often the first decision you have to take if you want to do a makeover. The path we took was a complete revamp. Why? Well, let me list down the problems I wanted us to solve with this initiative.
Problems:
Dated UI and Charts - Report Builder and Dashboard Builder were some of our earlier products. At Gainsight our design improved leaps and bound in recent years. We have unveiled our new design system early last year (and open-sourced it at Horizon design system). And these earlier modules do not look modern or consistent with our design ambition. We definitely wanted to refresh the builders, but we also wanted to modernize the default chart colors. (Example - Google logo)
Market Standards - BI is a well-understood and common domain (Check G2’s BI grid to see how crowded it is). Having a product in this domain means we had a lot of comparison from prospects, customers on some key standards such as - Responsiveness, Drag and Drop Report Design, Narration via Dashboards, More control over chart elements, etc.
Engineering Reasons - Tech debt accumulated over a period of time means that multiple teams need to sign off even a small bug fix. Architecturally, the team wanted to build a microservice with zero-downtime deployments and re-do the UI on modern UI tech which will enable us to leverage “horizontal components” in a bid to improve the velocity of the team.
Performance - We were running all the logic to generate a report in the customer’s browser in UI. This massively impacts customers who do not have modern machines or machines with poor CPUs. Often the experience is freezing of the system. Modern browsers help but are definitely not kind to this.
As you might have noticed, we needed a pretty big overhaul to move the needle in all the above areas. A series of incremental steps would not have been efficient. Hence despite the common wisdom (Joel’s post ), we decided to rebuild our reports and dashboards from scratch. Undoubtedly, this means there is a huge onus on the PM to get things right.
Pre-development:
From the PM point of view, there was a lot to be done here. I heavily leveraged the Kano model where we took all the features from various sources detailed below. A lot of features we already had automatically became must-haves, but we removed certain features which have very low usage / no longer make sense (B2B folks be careful on this). There were over 1000 product decisions for this multi-quarter initiative and hence having a framework really helped.
Product Vision - Every product team in Gainsight has a vision statement for what problem we are supposed to solve (what the product is supposed to do). We keep on iterating it based on the market, customer needs, and on our leadership’s inputs (Company Strategy, OPSP, etc.).
Market Research - I started researching the direction of BI tools (primarily BI platforms, other SaaS reporting tools, etc.) based on their past releases, current capabilities. Because we are a market leader, typical competitor analysis yielded little inputs compared to analyzing a completely different industry.
Customer community - A lot of customers leverage our community https://community.gainsight.com/ to post their feature requests and enhancements. During the ideation + design phase, this was the biggest pillar I leveraged. In the end, we were able to close around 50 feature requests. Interestingly, a lot of these requests do align with 1,2.
Design Validation - Work with our design team proceeded on two fronts. One was aligning the product to the new design system, this quickly made sure that all the auxiliary areas (such as settings page, etc.) were aligned with the rest of the product. The second and more interesting one was identifying problems + ideas for core builder screens, prototyping them quickly, testing them with internal and external users, refining them based on the feedback.
Engineering Innovation - For some of the problems we identified during our research stages, I involved our Engineering team, especially senior folks while the design is in progress to get their inputs. Also, this helps a lot with the engineering architecture as well since they know the problems to solve for. For example, we cache our reports only once a day per person. Sure, we can improve performance by more aggressive caching, but it reduces the promise of the tool.
Armed with the above requirements, mocks, and architecture, we started the development. I’ll not go too deep into this, apart from highlighting the fact that, we had a dependency on a lot of teams.
Release planning
This is the part where I felt we did quite well, but in retrospect, I can think of some improvements.
Beta testing - Even before all the dependent teams have finished their development, we ran a Beta program with stand-alone reports and dashboards. Initially started beta with 2 customers and progressively increased it to 80 customers. This phase helped us identify some key feature gaps, some new enhancements to round off the value prop.
Phase wise rollout with a Preview period - Once all the dependent teams are ready, we could not just turn it on for all customers. We started rolling this out in phases (the first 3 phases consisting of Beta customers mostly). For every customer, admins can experience both old and new reporting for 4 weeks. The expectation was to raise a red flag if you see any and we will work together on this. This is because of a few reasons,
Bandwidth reasons - Rollout involves migrating existing reports and dashboards to the new system. We can only migrate x customers in one go and we can only support y tickets every sprint given the infra constraints and team size.
We started from scratch - A lot of corner cases / organizational knowledge was lost. And in B2B, since every customer’s configuration is unique, there were instances where a scenario did not work for ~5 customers. 5 customers only seems small, but they might make up 30% of revenue, etc.
Dashboards are the most used - Executives, leaders, managers and CSM’s all use dashboards very frequently. An admin would want the best possible experience for their internal users - with no bugs or downtime. We want to help them achieve this by giving them an opportunity to compare Old vs New (and some content on how to improve dashboards taking advantage of new features)
Preparing the rest of the organization - If you worked in any B2B organizations, you would understand that as a PM, we are not alone in initiatives such as these. Of course, this comes with additional work of enabling and preparing the rest of the organization.
Release enablement - We at Gainsight typically have webinars focusing on the new features, demoing the best practices. For this initiative, since the rollout was nuanced, we also focused on the rollout plan and had multiple open offices at various timezones repeating the same content every week for one entire month. It’s alright if it’s boring for some audience, my focus was on making sure everyone understood the rollout.
Enabling Support - During the beta program, I was the main PoC, working with customers on Email, calls. But as the number of customers increased, we need to scale this. For the support team, in addition to the above enablement, we also did deep dive engineering enablement. This is added because the entire debugging flow now changed.
Product Marketing - We did something cool, we want to announce it too. Working with the marketing team on the right features, value prop, and an amazing product launch webinar.
Working with the Customer Success team - phase-wise rollout means the CS team wants to know who goes in what phase. Also, nominate their customers based on their sentiment/discussion with customers. For some enterprise customers, our CS team worked with customer admins to formulate an end-end plan to involve their internal change management/enablement team, create videos for their 1000+ end-users working with us to increase the 4 weeks preview window to 8 weeks, etc.
Weekly Cross-functional Sync - We had a weekly cross-functional sync with CS, Support teammates to see if there are any issues/uptick in incoming issues. Support would categorize the tickets by priority and we would often go through all blockers in this sync. CS team would highlight any escalated customers along with their problems in this call. This short-circuited process helps reduce the average bug duration and makes sure our customers feel that we are with them in this transition.
- Loading comments...