Retirement Web Experience

Step One: Understand

When I begin a new project, one of my first objectives as product manager is to understand the market need. How did we stack up to the competition? Who is our competition? What were they doing, and why? Generally, the retirement space is segregated by market size, with large players such as Vanguard and Fidelity catering to the largest companies. Transamerica is a mid-market and small-market retirement competitor, targeting companies under $100m in revenue. Competitors differ in how they offer retirement products; some focus on transactional capabilities, while others focus on holistic financial wellness. These strategies ultimately depend on how the company makes money. Were we setting out to cater to high net-worth users? Novices? Financial planners?

Another critical component to understanding what to build is identifying the problem. After all, as product managers our job is to “own the problem,” from two critical perspectives: the business, and the user. It has been debated which perspective is ultimately worth focusing on the closest. Naturally, many executives will tell you the business problem is that which is worth solving because the financial success of the company is directly tied to it. UXers will sometimes go toe-to-toe with such managers, asserting that it’s “all about the user” and that the user doesn’t care about business goals. Both of these perspectives are correct. A company cannot build a product divorced from the economic realities of earning enough revenue to outweigh expenses. Likewise, ignoring users occurs at the business’s peril. Disappoint them and they will flock to competitors. Simple as that.

Step Two: Plan

The planning for this project reached a key milestone when we were able to articulate with a degree of confidence what the business problems and user problems were. One convenient way to plan for what to build is to frame the problems a user story. The version I prefer to use is an extended one, factoring in the business problems and goals separately, because I think it helps explain things better.

“As [the business], I have a [problem], and want to achieve [goal], so that [reason].”

The nice thing about this framework is that it can be repurposed for the user’s perspective as well:

“As [the user], I have a [problem], and want to achieve [goal], so that [reason].”
In planning what to build, we made sure that each of these user stories tied to an overall theme. For example, if a user needed help deciding what actions to take in retirement planning, that problem would be categorized as personalization. This was done in concert with our UX team, who helped us refine this methodology.

Moreover, the user stories were tied to individual features in a product catalog. From there, we wrote epics tied to each of these components and tagged them in Jira.

Step Three: Build

Working with our delivery partner, McKinsey, we implemented the RTS “Reset, Transform, Sustain” methodology to achieve transformational change within the retirement business. Internal parties included: product managers, IT, design, research, and business stakeholders. External parties included: offshore IT, & BA. Essentially, we were funded for a period of under two years to completely re-build what a user sees when navigating to the online retirement portal.

When it was time to start building, we built customer journeys and a product roadmap. We implemented an agile methodology (Scrumban) in two week sprint cycles. Jira was the tool of choice for epic and user story capture, and Write was utilized on the design team. Miro was our tool of choice for sharing and ideating.

The design process posed some challenges at first. We struggled at times to develop compelling ways to show advanced financial data. According to market research, there is a broad variation in how users interpret and respond to data. Some users prefer analytical comparison charts, others prefer narrative experiences that answer actual questions, while other users gravitate to peer comparisons. To complicate matters, power users prefer different tools and graphics than novices. Because of this divergence in customer preference, I challenged our design team to develop a suite of informational displays that catered to our target customer. Ultimately, we landed on a design that met our organization’s expectations.

With the design process ongoing in the background, we conducted daily backlog refinement sessions. These sessions were comprised of myself, business analysts, developers, and stakeholders. The critical nature of these sessions cannot be overstated. Essentially, as the product manager, I offered up the features we wanted to build as a team. The miracle of business analysts is that they ask the difficult questions needed to fully articulate the vision. For example, as product manager, I was not privy to a host of information about how our back-end (many of which were build in-house) systems operated, and these limitations affected what we were able to deploy. Business analysts, in concert with SMEs, assisted us in refining and developing a vision that was realistic and also approved by the developers.

Over the course of dozens of two-week sprints, we iteratively build a series of consecutive releases: first 1.0, then 1.5, then 2.0, each with the usual UAT and stakeholder interviews needed to measure success.