Thirty-one percent. That's how many users were actually logging in. The $1.5M client portfolio was about to walk, and everyone thought we needed more features. They were wrong.
- Rescued at-risk client portfolio worth $1.5M ARR
- Drove adoption from 31% to 90% across 32 clients
- A/B tested onboarding: proactive live sessions converted at 76% vs. 31% for self-serve
- Rebuilt trust through bi-weekly client demos
The Backstory
SwapViewer was a legacy financial planning platform for municipal and nonprofit clients - built years earlier and in maintenance mode with no dedicated PM. The director of the group wore the product hat on top of everything else. It worked fine for the existing user base, so it wasn't a priority.
Then a new wave of clients came onto the platform. And the numbers were brutal.
Adoption was stuck at 31%. Across 32 clients, most users had tried it once and gone back to their old workflows. Contract renewals were coming up. Account managers were getting uncomfortable questions. $1.5M in ARR was at risk.
The assumption internally was that we'd fallen behind on features. Competitors had more capabilities. If we just built more, clients would come back.
I stepped in to lead the turnaround. I had 90 days to figure out what was wrong and fix it.
What Everyone Assumed
The feature gap theory made sense on paper. Product teams always want to build more. Sales teams always want more things to sell. When a product is struggling, "we need more features" is the easy diagnosis.
But something didn't add up. SwapViewer wasn't light on features. If anything, the platform was dense. Lots of screens, lots of options, lots of functionality. The engineering team had been busy.
So why weren't people using it?
I decided to stop theorizing and start listening.
What I Actually Found
I spent the first two weeks talking to users. Not account managers, not executives. The actual people who were supposed to log into SwapViewer every day and do their jobs.
The conversations were revealing.
"I tried it once and couldn't figure out what I was supposed to do."
A financial analyst at a municipal client had logged in on day one, clicked around for ten minutes, and never came back. The platform didn't match her workflow. She couldn't find the reports she needed. It felt like software built for someone else.
"There's too much stuff. I don't know where to start."
A treasury manager at a nonprofit described feeling overwhelmed. Every screen had options he didn't understand. He was afraid of clicking the wrong thing and breaking something. So he just didn't click anything.
"Nobody ever showed us how to use it."
This one came up over and over. The launch had been a technical success. Emails went out, logins were provisioned, documentation was uploaded to a portal somewhere. But nobody sat down with users and actually taught them how to do their jobs in the new system.
"I just went back to my old process. It's slower but at least I know how it works."
The killer. Users had a choice between a confusing new platform and their familiar old workflow. The old workflow won.
The Real Problem
We didn't have a feature problem. We had an adoption problem.
The platform had been built based on assumptions about what users needed, not research into how they actually worked. Features were added because they seemed like good ideas, not because users asked for them. The result was a product that could theoretically do a lot but practically helped no one.
And onboarding was basically nonexistent. Launch day was "here's your login, here's a PDF, good luck." For busy professionals who didn't have time to figure out new software, that was a death sentence.
The clients weren't unhappy because SwapViewer couldn't do what they needed. They were unhappy because they couldn't figure out how to make it do anything at all.
The Turnaround
I had 90 days to turn 31% adoption into something that would save the contracts.
Weeks 1-2: Listen and Diagnose
More user interviews. I wanted to understand every workflow that mattered. What were people actually trying to accomplish? What did their day look like? Where did SwapViewer fit, or fail to fit?
I mapped the core user journeys and compared them to what the product supported. The gaps were painful. We'd built features nobody asked for while ignoring workflows people used every day.
Weeks 3-4: Reorganizing Around the Core Job
I ran MoSCoW workshops with the team. The conversation was uncomfortable. We had to admit that months of work had missed the mark. Features people had sweated over weren't being used.
But the problem wasn't the features themselves. It was that everything was treated equally. Power tools and basic tools were mixed together in the same interface. New users couldn't find what they needed because they were drowning in options meant for power users.
The insight: we didn't need to kill features. We needed to reorganize around the core job-to-be-done and move advanced capabilities out of the default view.
We identified five feature areas that were overwhelming new users:
For each of these, we made the same call: move it to an Advanced section. Power users could still find everything they needed. New users wouldn't be overwhelmed.
Weeks 5-10: Building the Opinionated Default
Two-week sprints focused on the default experience. Not new features - a better starting point.
The new default dashboard was opinionated. Instead of a blank canvas with endless options, users got a single view designed around their actual workflow: current valuations, counterparty exposure, upcoming actions, reports. No configuration required. It just worked.
Every two weeks, I demoed progress to clients. Not polished presentations - just honest updates. "Here's what we heard, here's what we changed, here's what's next." The transparency rebuilt trust.
And crucially, we weren't taking anything away. Power users who needed scenario modeling or custom dashboards could still access everything. They just had to click into Advanced.
The key insight: great products are opinionated about defaults while preserving depth for those who need it. We stopped trying to serve everyone equally and started serving different users appropriately.
Testing, Not Guessing
The original launch had used self-serve onboarding. Welcome email, links to docs and video tutorials, a check-in email a week later. It wasn't working. Activation was stuck at 31%.
I hypothesized the problem was passivity. Users weren't lazy. They were overwhelmed and needed a human to guide them through the first session.
So I designed a different approach and piloted it with a small subset of clients.
The Variants
Variant A (Original)
Variant B (Pilot)
The Metric
- Primary: "Active user" = logged in and completed at least one core workflow within 14 days
- Secondary: Support ticket volume, time to first action
The Tooling
- Amplitude for login and workflow completion tracking
- Spreadsheet to track which clients got which approach
- Bi-weekly reviews of the numbers
The Results
It wasn't close. Live onboarding converted at more than twice the rate of self-serve.
The Rollout
I scaled Variant B across all 32 clients, re-engaging users who had bounced with the new live onboarding approach. Within 90 days, adoption hit 90%.
The Learning
Users weren't lazy or uninterested. They were overwhelmed and needed a human to guide them through the first session. Self-serve docs work for power users. They don't work for busy professionals encountering new software on top of their existing job.
What Changed
Adoption went from 31% to 90% across 32 clients in three months. The contracts renewed. Clients who had been ready to leave became advocates.
But the numbers don't capture the real shift. At the beginning, client calls were tense. Account managers dreaded them. By the end, clients were giving us feature requests because they actually cared about the product getting better. They'd gone from checked out to invested.
What I Took Away
Two lessons from this one.
First: the instinct when a product struggles is to build more. Add capabilities. Close the feature gap. It's a comfortable answer because it means the problem is external. Competitors have more, so we need more too. But sometimes the problem is internal. You built the wrong things. Or you built the right things and forgot to help people use them. More features won't fix that. They'll make it worse.
Second: don't guess when you can test. I could have picked an onboarding approach based on instinct and rolled it out to everyone. Instead, I piloted a new approach with a small subset, measured the difference, and let the data tell me what worked. The pilot took a few extra weeks to set up. It saved months of iterating in the dark.
My Role
- Led 90-day turnaround as Senior Product Manager
- Conducted user research across 32 clients to diagnose root causes
- Ran MoSCoW prioritization to re-scope around actual user needs
- Designed and executed A/B test on onboarding approaches (31% → 76% activation in pilot)
- Rebuilt trust through bi-weekly client demos
- Drove adoption from 31% to 90% by scaling the highest-converting onboarding approach across the portfolio