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.
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.
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).
* benchmark set by previous vendor
Real-life vs. theory.
Or why it can be a good idea to begin from the end.
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.
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.
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.
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.
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.
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.
Zoom interviews were scheduled with 5 people.
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.
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.
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:
Show all available plan options → maximize flexibility, learn clients preferences
Only show one or two plan options and deemphasize or hide the rest → decrease cognitive load, simplify enrollment, easy to build
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:
When a client selects a payment plan, before the first payment → risk of potential drop-off due to additional (and optional) steps
Sometime after enrollment, as part of the plan management page → potential discoverability issues
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).
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.
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:
And a couple of strategic outcomes:
*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.
