PromisePay for utilities:

Launching a new product in times of great uncertainty

🚧 I promise this looks better on desktop. However, since you are on mobile, can you share why are you reviewing portfolios on mobile? I'd appreciate a quick email — elemarus@gmail.com

In a nutshell

This is a story about how we pivoted and launched a new product in the middle of the pandemic. It shows how you can break almost every rule, turn a traditional design process inside out, and end up with a successful product.

Role: Design Lead
Timeline: 8 weeks
Teams & parties involved: Sales, Engineering, Operations & Support, Design
Context & Goals
Process
Discovery
Step back
Trade-offs
Outcomes

Context

In 2020, at the start of the pandemic and full-blown lock-downs, our company had to sunset its core project. We had a great team but limited time to find a new application for existing technology (payment plans) that would allow the company to survive and potentially thrive on the COVID-affected market.

At some point, we got in touch with a water company from Kentucky and realized that we could use our technology to help people with utility debts that had sky-rocketed during the pandemic.

Goals

Create, launch, and validate a new product helping people and utility providers to manage their debts and keep water services on during the pandemic (while still making a profit for Promise in a non-exploitative way).

1
Create and launch a new product in 2 months
2
Help people in debt keep their water on
3
Deliver over 20%* repayment rate

* benchmark set by previous vendor

Process

Real-life vs. theory.
Or why it can be a good idea to begin from the end.

Starting with hi-def mocks. Wait, O_0 what?

As a company, we had no previous experience with utilities, and our proposal needed to be very persuasive for this partnership to happen. Our sales team was convinced that visuals could make the difference here.

Long story short, I had 3 days to come up with a demoable hi-def prototype that would show a full customer experience: from initial outreach to account management flows. The goal was to make it look as real as possible.

Image by brilliant Pablo Stanley

Quick note: instead of copying existing solutions from other utility companies we decided to lean on our previous experience with payment plans, as well as previous insights and data from our product experiments.

Below is the prototype our sales team presented to the customer.

We added reactions that don't exist on mobile to make our presentation more interactive

The presentation turned out to be a huge success. The client loved the visuals (they pointed this out in their feedback) and overall ease and simplicity, and we proceeded to implementation.

More mess coming. Planning, building and implementing — all at the same time. Wait, O_0 why?

Not only did we want to offer our payment plans as soon as possible to people who struggle, we also had an important external factor that forced us to rush — the government moratorium on water shut-offs was about to end. Everyone who would sign up for a payment plan would be protected.

Understanding this context, our Eng team started building the key features and integrations even before we had defined the full scope of work, agreed on the initial design, or were able to do adequate user research.

Under normal circumstances this would be a clear path to failure, in our case, it was the most logical way to proceed and shorten our go-to-market time.

Finding time for research. Wait, O_0 when?

It took some effort for me to squeeze user research into our timeline. The timing (halfway through the implementation cycle) was not perfect, but, you know, better late than sorry.

Usually, I would team up with a researcher. In this case, I owned the project from start to finish.

One more issue

Being in debt is stressful by itself, discussing it with a stranger can be even more uncomfortable.

Solution

I did a language deep-dive with our support team and prepared a list of potentially triggering words to avoid.

E.g.: even the most innocent words like 'help' or 'assistance' can make people feel uncomfortable. Even under pressure, people still have their pride, and often they don't want any 'help' or 'charity.'

Being a recent immigrant and non-native speaker, I had to be extra careful with wording and aware of possible cultural differences.

Respondents

Zoom interviews were scheduled with 5 people.

1
A person only a few days past due on their bills
2
A person past due from time to time, lives in the area but their neighbourhood is serviced by another water company
3
A person past due from time to time, up to date with their payments
4
A person past due over 30 days
5
A person past due over 30 days with a failed payment plan for their water bills

Five is just a handful, but it was enough to verify our initial ideas, pre-validate our product offering, and to come up with product insights, additional hypotheses, and a list of possible features.

Snapshot of the interview prep doc, click to zoom in

Insights & Discovery

1
Utility bills are payments of the highest priority among people who struggle financially. Usually household expenses are prioritized as follows: food, rent, utilities, other expenses.
2
People with higher income unpredictability don't use auto payments because they need to have more control over their budget.
3
When in financial hardship, it takes more effort to track all payments and due dates. People mentioned having multiple ways of tracking bills, including having bills on the fridge door, setting up google calendar, managing several paper notebooks, or having hand-written notes on every mirror in the house.
4
Timing is crucial for successful payments. People tend to plan their payments around their pay days. Some get paid on specific dates (e.g.: the 5th of every month), and some are paid on a specific day of the week (e.g.: every 2nd Wednesday of the month, or every other Friday, etc.).
5
People tend to contact their utility provider directly if they need help, or search for affordability programs on utility provider websites.
6
People are familiar with the payment plan concept, and would like to use this option if the terms seem fair and if the plan offers some amount of flexibility.
7
People prefer self-service for payment adjustments (e.g.: request more time to pay in some automatic way instead of calling and talking to a rep).
Following ‘The Mom Test’ interview approach, at the end of each interview, I briefly introduced our product, and asked my respondents if they were interested in signing up. We subscribed 2/5 respondents for early enrolment (2 were not eligible, 1 was not ready to make a commitment).

Normalizing the process

Taking a step back

Starting from a high-fidelity design is considered to be bad practice for a reason. Being locked on solutions early on can backfire in many ways: you can spend your time solving the wrong problem, or stick to the wrong way of solving the right problem.

To avoid these pitfalls, I decided to take a step back, ditch high-def mocks and the prototype for a while and focus only on high-level flows and user goals at each step.

I used sticky notes to list the goals for each screen, available actions, potential issues, and questions for the team to answer.

This seemingly unnecessary step helped the team to align and agree on the goal for each page and allowed us to move more quickly as a group. It also led us to our first big product decision and trade-off.

Trade-offs

1
Choosing between simplicity & flexibility for enrollment

Accessibility and flexibility are two core features of our payment plans. And finding the balance between showing off all our 'plan tailoring' capabilities and reducing the cognitive load on our stressed-out clients is always a challenge.

In this case, we had the following choices for payment options:

2
Choosing between faster onboarding & long-term success

User interviews and our previous experience with payments showed us that flexibility around payment dates was crucial for long-term success. Our goal was to align all future payments with the client's income schedule.

The central question was when to surface our payment schedule flexibility:

Testing different approaches (not really)

Yeah, normally, it would be a good time to run usability tests or even better — A/B tests to figure out what solutions performed better. But we didn’t have the time or resources, so we had to make judgment calls.

After careful consideration, we decided to optimize for quicker enrollment so that we could establish a relationship with a client ASAP and communicate our product flexibility later (if needed).

Cutting features for an MVP

As the great philosopher once said (and yes, I am quoting Mick Jagger here)

—You can’t always get what you want

And neither did we. As much as we'd have liked to have built all the flexibility features we wanted, we had to respect existing limitations (Eng team capacity, harsh timing) and higher priorities (launching the service before the shut-offs came back).

We decided to launch with only one feature from the 'plan flexibility' list — payment extension request. We designed it in a very forgiving way, so that we could do two things — give our clients instant relief and learn the reasons behind those requests.

Flexibility features we wanted to include

Flexibility features shipped before launch

Design changes

Payment extension flow — the only payment flexibility option implemented for launch

Outcomes

We were able to launch a month before water shut-offs were back on. And what can I say, we have some pretty good numbers:

  • 93% repayment rate (comparing to 20% with previous vendor)
  • 30% conversion rate
  • 2 months from concept to launch

And a couple of strategic outcomes:

  • Our first utility customer became our champion and is actively promoting us across the industry
  • We validated our new product vertical and are expanding it rapidly, partnering with more utilities across the country as I write this
  • This project helped Promise to regroup and find a new path during the Pandemic, resulting in a series A raise of 30M

Lessons learned

*E.g.: At some point, our UI and visuals on prod were way below my personal standard, but it really didn't matter for the success of the product and for us being able to help people. However, I'm glad that we revamped our UI before the next implementations.

P.S.
There are 3 more things I'd like to share

1
A Case Study made by the US Water Alliance
This analysis from the US Water Alliance for Louisville Water aid and payment plans program (designed and implemented by PromisePay) is an unbiased confirmation of product value and real-life impact.
Screenshot from US Water Alliance case study, Page 3
2
B2B dashboards that we share with our utility customers
Initially, we launched with a B2C flow only. All of our communications with our B2B clients were heavily manual. As a quick follow-up, we came up with a set of B2B dashboards allowing our clients to track financial metrics and plans performance and simplify day-to-day work for their CS teams.
3
The second iteration of product UI (up and running now)
We switched to a customized Material UI and tightened our flow a bit.