Implementing tools with Product Operations - Guest article with Melissa Southern
Read how the Product Ops team at WEX implemented aHa! at enterprise scale.
I have recently focused on product tooling and platforms as a theme for Practical Product Ops articles. So I was thrilled, having read those articles, Melissa Southern reached out to discuss her own recent successes in rolling out a new product tool at WEX, the enterprise-size B2B fintech company.
We quickly agreed this story needed sharing more widely, and so here it is. In this article, Melissa outlines how the business implemented aHa! as a Product Management tool, linked with Jira and the challenges, successes and learnings her Product Ops team took from the experience.
Enjoy!
Introduction
WEX, a global B2B fintech, completed a 7-month implementation of Aha as our product management tool. The Digital Operations team (recognized elsewhere as Product Operations) selected Aha to meet evolving reporting needs and support a product-led development process. With over 600 users and 130 workspaces connected to a corresponding Jira project, we now have a unified platform for roadmaps across 100+ business cases. As we move into “maintenance mode,” we're focused on allowing teams to adjust while planning future enhancements. While the list of things to do is a mile long, I’m excited to share what went well with our implementation and what we’ll do differently in the future.
The Challenge
WEX recognized the need for a unified tool to manage product development, moving away from multiple platforms and spreadsheets to a single “source of truth” for vision, strategy, and in-flight work. This shift aimed to standardize collaboration and decision-making, enabling consistent reporting and better connections between product investments and customer benefits. Like at any global operation with thousands of employees, we had to manage the change carefully and, even so, faced hurdles in user adoption, communication, and technical constraints.
Highlights
Any challenges we faced were surmountable, thanks in large part to the unwavering support of our Chief Digital Officer and the Digital Leadership Team from day one. Not only did they help us by recording videos about why it was important to centralize reporting and data in Aha, but they also were excited to log in and were active participants in building roadmap templates and dashboards.
Our entire Digital Operations team contributed, with seven members taking on key roles. One led the implementation publicly, while others became subject matter experts in different areas of the app. This allowed us to answer PMs' questions thoroughly, or quickly connect them with someone who could.
Our team also works in an embedded model, where each team member works within one of WEX’s lines of business. This allowed each of us to build on existing relationships and gave product managers a trusted point of contact. Additionally, PMs were less afraid to ask questions and give feedback when things weren’t going well.
Challenges
We gained valuable insights from this process that will be instrumental in shaping future Aha enhancements and other end-to-end tooling rollouts. Below, I've highlighted some of the key challenges we encountered along the way.
Building buy-in and excitement for Aha. Implementing a tool for 7,000 employees isn’t suited to a “build-as-we-go” approach. In hindsight, we could have built an even stronger implementation strategy with robust user interviews. This would have allowed for more granular clarity around PMs' daily tasks and identified how Aha could support them. Similarly, infusing each stage of the rollout with storytelling could have connected the WHY to the HOW and emphasized productivity improvements. It should be noted that developing this kind of strategy requires a longer lead time and should be complete before users have access to the platform.
Leveraging long-term Aha users to accelerate adoption. Deeper engagement with teams already using the platform would have created more internal champions for the tool, rather than leaving some PMs feeling that their voices were ignored or undervalued. A stronger partnership would have helped us make better structural decisions and ensure our communications were useful for both new and existing users, which would have accelerated adoption.
Building communications and training plans in advance. We used a variety of channels and formats to communicate requirements and best practices as they were determined, and while we got the right information to the right groups, it would have been better if we had preloaded the workflow a bit more with a defined tone, audience, and messaging priority by platform before we started.
For example:Email is for communicating requirements and hard deadlines. The audience for email is all of Digital and involved Technology partners. Each email should include a link to Confluence with supplemental information.
Google Chat is for reminders about deadlines and answering questions. This is a space where we can bring fun to the implementation and highlight the wins of specific teams and PMs.
Our training addressed pain points as they arose, rather than discussing key topics on a set schedule. A more cohesive strategy could have built additional long-term confidence in the platform. The most successful session was on Roadmaps, where we sent daily emails prior to the training explaining roadmap importance, required data, and steps in Aha. During training, we reinforced basics and used breakout rooms to address specific challenges in a small-group setting. This approach was highly effective but discovered late in the implementation timeline.
Auditing Jira setup beforehand to simplify integration and ongoing management. Since Jira and Aha are managed by different teams, the lack of a standard Jira project template made creating an enterprise integration template difficult. Beyond mapping fields, we recommend unifying templates across tools where possible. Fortunately, our Technology counterparts were invaluable, helping us configure integrations with over 130 Jira projects despite these challenges.
Determining a licensing process that aligns with user roles. After combining users on one instance of Aha, we quickly realized two things: 1) we didn’t have enough licenses and 2) PMs and TPMs often shared or overlapped work in the tool. By focusing on user roles and licenses earlier, we could ensure that the right people had access to the tool on day one. Additionally, having a plan for requesting licenses will lead to less confusion and one-off adjustments. (We use Jira Service Management for this — employees can request view or edit permission and mark which workspaces they need to access.)
Key Takeaways
In the future, whether it’s an enhancement to how we use Aha or a completely new tool, our team has committed to the following things:
As a team, set goals at the start of the rollout to maintain momentum and morale. Having a North Star metric will give the implementation team something to come back to when directions from leaders or feedback from users becomes confusing.
Having a clear timeline and plan from the start and publishing it somewhere that’s easily accessible by our audience. Must-haves for this plan include: communication strategies (tone, channel, cadence), mitigation plan for how problems will be addressed, and explicit roles, responsibilities, and expectations for using the tool.
Creating a detailed, consistent training plan the implementation. Whenever possible, schedule all training in advance and clearly state the topic and purpose of each training in the meeting invites, along with any prerequisites. Ensure training represents a variety of learning styles, including written materials, videos, and live instruction. And be sure to leave room for ad hoc training based on feedback received from users.
Identify a target user group and bring them along for the journey. Either create a workspace where a test group can view and react to the setup of different features within the application, or identify a specific team or department who can use new features in their day-to-day work in order to collect feedback and make changes before rolling it out across the organization.
Collect feedback throughout the process and have space to flex the approach based on feedback. Allow for both anonymous and identifiable feedback, but have a strategy for vetting anonymous feedback to understand if it is one individual’s concern or shared among a broader group. Determine in advance what kind of feedback will warrant a change, and when. This could be a scoring model, percentage of affected users, etc. When collecting feedback, clearly state these qualifications for users.
Take a top-down approach to the tool’s setup and ensure it matches the organization’s ways of working. Look beyond the obvious features and think about how to structure the application in a way that aligns with existing reporting and day-to-day processes. This will help with education and adoption.
Conclusion
In reflecting on our Aha implementation, we’ve gained valuable insights into what worked well and where we can improve. As we continue refining our approach, we’re committed to applying these lessons to future projects, ensuring a smoother, more effective rollout process for our teams.
About Melissa Southern
Melissa is a passionate product operations professional who thrives on seeing the big picture while pinpointing the details that matter. Her superpower lies in crafting actionable steps toward strategic goals, fostering strong relationships across all levels, and driving meaningful transformation. Before focusing on enterprise product operations, she headed operations at a seed-stage SaaS startup and spent 11 years balancing roles in product and project management within the digital agency space.