Making Pension Investments Easier to Understand

Using customer research and live investment data to give customers greater confidence in where their money is invested

Executive Summary

Customers were being asked to make long-term decisions about their pensions without necessarily having enough context about where their money was invested or how their chosen fund was performing.

The opportunity was to make investment information more transparent and useful without overwhelming customers with financial data they might struggle to interpret.

I led the team through a structured discovery and design process to explore how up-to-date fund information could be incorporated into the product. Working across Customer, Product, Design and Engineering, we combined customer needs with the technical possibilities of a new API to identify which information would genuinely help customers understand their investments.

Rather than assuming that more information would automatically create more confidence, we tested ten potential data areas with both existing customers and people unfamiliar with PensionBee. We used the results to rank the information according to perceived usefulness and insight, then combined those findings with the technical discovery to create an iterative delivery plan.

The result was a clear evidence-based roadmap for improving investment transparency while maintaining focus on two core business measures: customer trust and the efficiency of supporting those customers.

The Problem

Pension investments are inherently difficult to understand.

Customers are investing money for the long term, but the information available to them doesn't always make it easy to understand where their money is invested, what is influencing its performance or how their chosen plan compares with the wider market.

This becomes particularly important during periods of market volatility.

A customer seeing the value of their pension fall may understand that markets move, but without sufficient context they can struggle to determine whether what they are seeing is expected, specific to their investment or something they should be concerned about.

That uncertainty has consequences.

Customers may seek reassurance from support teams or lose confidence in the product and the organisation managing their pension.

Our hypothesis was therefore:

Providing customers with more useful information about their pension and contextualising it against the wider market would help them make more informed decisions, alleviate concerns during volatile periods and increase trust in PensionBee.

The challenge was determining what information would actually achieve that.

Starting With the Customer Need

It would have been easy to treat the availability of an API as the starting point and simply expose everything it could provide.

We deliberately didn't.

The API gave us access to current fund investment details and performance data, but technical availability didn't mean customer usefulness.

My role was to coordinate the team through a structured Double Diamond process, deliberately separating the technical opportunity from the customer problem before bringing the two together.

We initially diverged in two directions.

Engineering explored what information the API could provide and the practical considerations around using and visualising it.

At the same time, Design and Research explored what customers actually needed to understand their investments and what information they would find meaningful.

The aim was to find the intersection between:

What customers need

What we can technically provide

What can genuinely improve the experience

Defining What "Useful" Means

From the available data, we identified ten areas that appeared capable of giving customers greater insight into their pension plans.

But identifying ten possibilities wasn't enough.

We needed to understand which ones customers could actually interpret and which would provide meaningful context rather than simply adding complexity.

This became a key principle throughout the project:

More information isn't necessarily more useful.

A sophisticated financial product can easily become less approachable if every available metric is exposed without considering why someone needs it.

We therefore designed research around the ten areas individually, giving participants the opportunity to assess the information and explain what they found useful, insightful or confusing.

Testing With Customers and Non-Customers

We conducted extensive moderated and unmoderated research with two groups.

Existing PensionBee customers gave us insight into the needs and concerns of people already managing their pensions through the product.

Participants unfamiliar with PensionBee provided a useful counterpoint.

They had none of the product knowledge or assumptions that an existing customer might have developed, allowing us to identify where terminology, financial concepts or visualisations relied too heavily on existing knowledge.

This combination was particularly useful because the product needed to work for customers with very different levels of financial understanding.

The research allowed us to rank all ten potential data areas according to how insightful and useful participants considered them.

That gave the team evidence for prioritisation rather than relying on internal opinion.

Bringing Customer Value and Technical Reality Together

The research didn't happen in isolation from Engineering.

As customers were assessing the potential information, Engineering was exploring the technical implications of accessing and presenting the data through the API.

This created a productive tension.

Some information could be technically straightforward but provide limited customer value.

Other information could be highly valuable but introduce significant technical or visualisation complexity.

Rather than treating either consideration as the deciding factor, we brought them together.

The final prioritisation combined:

Customer usefulness

Customer comprehension

Technical feasibility

Potential impact on our core metrics

This allowed us to make informed decisions about what should be delivered first and what could follow later.

Turning Research Into a Delivery Strategy

The research gave us a ranked set of ten opportunities.

Instead of attempting to deliver them as one large feature, we split the project into ten individual subtasks that could be tackled iteratively.

This was an important product decision.

It meant we could introduce improvements progressively, learn from customer behaviour and refine the experience rather than committing to a single large-scale implementation based on assumptions made during discovery.

The project therefore moved from:

"How do we expose this investment data?"

to:

"Which information creates the most value for customers, and in what order should we introduce it?"

That shift turned an API opportunity into a customer-led product roadmap.

Designing for Confidence, Not Complexity

The underlying goal was never to make customers financial experts.

It was to give them enough useful context to feel confident about their pension.

That meant thinking carefully about hierarchy, terminology and visualisation.

Investment information needed to answer questions customers were likely to have without requiring them to understand the mechanics of financial markets.

The experience therefore needed to balance transparency with simplicity.

The design challenge wasn't:

"How much information can we show?"

It was:

"What information helps a customer understand what is happening to their money?"

That distinction guided the research, prioritisation and eventual product direction.

Outcomes

Evidence-based prioritisation

Ten potential data areas were researched and ranked according to customer perceptions of usefulness and insight.

Iterative roadmap

The research and technical discovery were combined into ten discrete subtasks, allowing the team to approach delivery incrementally rather than committing to a single large implementation.

Stronger customer context

The project established a clearer understanding of what information customers need to understand their investments and where additional context could increase confidence.

Cross-functional alignment

Customer needs and technical constraints were considered together, creating a shared basis for decisions between Design, Product and Engineering.

Business alignment

The project remained tied to two measurable business outcomes:

• Invested customers per full-time employee

• Net Promoter Score

The intention was to improve customer understanding and confidence while reducing the need for customers to seek reassurance through support.

Reflection

The most important lesson from this project was that product leadership often means resisting the obvious solution.

We had access to a valuable source of investment data. The temptation could have been to expose as much of it as possible.

Instead, we treated the API as an opportunity rather than a solution.

The team's job was to understand what customers actually needed, test our assumptions and then find the most effective intersection between customer value and technical possibility.

My role was to create the conditions for that thinking to happen: establishing a structured discovery process, coordinating Design, Research, Product and Engineering, and turning the resulting evidence into a prioritised product strategy.

The outcome wasn't simply ten pieces of investment information.

It was a clearer understanding of what customers need to know to feel confident about their pensions—and a practical, evidence-based path for delivering it.