My Life in Practice

TLDR

How do you manage a multitude of competing user personas that need the same information in different ways? Exploring how I solved the problem in the past and how I might solve it differently today. While the final solution was adequate, I would not say it truly addressed the true jobs to be done (JTBD). More time could have been spent up front on Persona Hypothesis and JTBD Hypothesis testing to ensure the project was on track. I feel that would have prevented delays and frustrations over the end-product. Hindsight is always 20-20 and I am very proud of the product solution that was delivered.

Project Background

Transitioning a complex manual process to a Single Source of Truth model. The prior current state process of capturing retirement plan configurations involved multiple groups interacting with the same information across multiple documents with similar but not identical wording. There was no single source of truth that everyone could reference. The process was rife with pain points, leading to confusion with internal teams, and frustrating for the external client. Failures in the process could result in significant penalties: incurring penalties, having to fund corrective contributions, or being disqualified as a retirement plan.

User Personas and Goals

Retirement Plan Sponsor

• Discuss the current plan document and any changes that should occur in the new plan.

Project Manager

• Lead point of contact for the Retirement Plan Sponsor.
• Gather plan configurations and gain agreement from the Retirement Plan Sponsor.
• Communicate confirmed plan configuration with multiple teams.

Plan Document Associate

• Translate the current plan document, likely from a different vendor, into the new template.
• Create the plan document once the plan configurations are confirmed.

Plan Setup Associate

• Utilize confirmed plan configuration to setup front-end (e.g., website, call center) and back-end (e.g., recordkeeping system, inbound/outbound file transfers) setup.

Problem to be solved

While there were multiple problems the project attempted to solve, I will focus on the persona problem. It is helpful to think in terms of languages. Each persona above speak a different language and manual translation led to regular confusion and frustration.

The Retirement Plan Sponsor speaks the language of their business. They are not a technical expert but will be the ultimate decision maker.

The Plan Document Associate speaks the language of compliance. They translate business specifications into a plan document that will legally represent how the plan will operate.

The Plan Setup Associate speaks the language of the recordkeeping system. They translate business specifications into different systems that all track how the products and services will operate.

Lastly, the Project Manager needs to speak all the languages. While they may not need to be fluent, they must be able to understand how a business requirement might translate to the plan document or the recordkeeping systems.

Solution

Create a Single Source of Truth. Focusing on the persona issue, the solution must:

• Be finite enough to accurately communicate the options available to the Retirement Plan Sponsor for each product and service.
• Be flexible enough to capture incoming configurations that do not match up to the new options.
• Accurate communicate the confirmation status to all teams.

The new solution would be presented to the Retirement Plan Sponsor, and as the ultimate client in the process, their needs were of primary concern. I focused the language on the language of business, no jargon, clear selections, and understandable questions.

This meant that the language considerations for the other personas needed to be handled either on the back-end or via supplemental inputs. For the plan document, a reference ID was added to ensure clarity on exactly which provision was being references. For the recordkeeping systems, system integration was the primary solution and where that was not yet available, policies and procedures were needed.

What would I do today

As a Product Manager, I would spend more time with persona ideation and identifying each personas JTBD. Many of these were discovered during the build rather than being known up front. I would leverage my support more, acknowledging that while I am informed on many of the topics, that does not mean that my understanding of the actual problems we need to solve are correct. Last, I would work on getting Retirement Plan Sponsor input. Creating some prototypes to get their feedback, instead of delivering the finished product and then getting feedback.