top of page
test5.png

All Onboard

Case Study:
INTRO
You know how, at a startup, every day is the same and nothing ever changes? I kid, obviously. Life is chaotic and the highs are high and the lows are somewhere in the Mariana's Trench. And sometimes you have to step in at a moment's notice to put together something to address a hole that yesterday was a pinprick and today is the gaping mouth of a blue whale. But I digress.

We signed a huge client, which is of course good news. They were the biggest one we've ever had. They had 300+ different franchise locations that all needed to learn our software, and we had a team of four in the onboarding department that traditionally delivered live, individual trainings. Not the best situation.
THE APPROACH
I was called in to craft a self-service onboarding experience, essentially on my own. I was uniquely qualified in that a) I used to work as an onboarding consultant, b) I used to work as a product designer, and c) I was already familiar with Pendo, a low-to-no-code solution for in-app guidance that we already contracted with. I acted as PM, designer, and developer to research, design, develop, release, and maintain our self-service onboarding system.

Planning

FIRST PROBLEM:
BUGS GALORE
Hoo boy. When I say bugs galore, I mean we had so many ants at the picnic it wasn't even funny. But here's the thing - none of them were critical per se. So they had been allowed to sit, and pile up. But you know how it is - when you're trying to accomplish a quick task and you hit three small obstacles, you stop trying because that is annoying as all heck.
SOLUTION:
EXTERMINATE, EXTERMINATE
Spoiler alert: we fixed the bugs. In setting our OKRs for the quarter, our primary focus was to get our bug count down. Luckily, many of the bugs were very quick fixes (again, nothing critical). Over the span of our first quarter working on this app, our bug count jumped down from a whopping 46 to 8. Since that quarter, we got our bug count down under 5 and have kept it there.
BIGGEST PROBLEM:
LACK OF CHANGE MANAGEMENT
I'm sure you know this, but people really, really hate change. The users of our app were no exception. The folks at Kangarootime had done a really great job managing change for our customers prior to my start. But this app was unique - it was for our customers' customers. Kangarootime is used by childcare centers to manage their operations, and this app was for parents to see what their child was up to all day and to pay their bills. And unfortunately it was the parents who were on the app store calling our app a "dumpster fire" (yes, that's another direct quote).
SOLUTION:
SOMEHOW WE MANAGE
We needed to make sure that our user base wasn't feeling left out to dry when they were essentially forced to use a new app without any say in the process. Lucky for me, change management is my bread and buttah. I was able to formulate and introduce a simple release marketing planning process. With every release (and we released a lot) we selected a strategy to help smooth the transition. We used two scales - a) how disruptive the release would be to existing flows, and b) how excited folks would be about it. Sometimes, the right thing to do was nothing at all (low disruption, low excitement). But, for when it wasn't, I came up with three options that we could mix and match.
list-two.png
Release Notes
LOW/MID DISRUPTION, MID EXCITEMENT
I created a process for all nine of our cross functional dev teams to report items for release notes. I collected them, unified the written voice (adding a few jokes here and there) and distributed them to the relevant users. This process helped not only our app users, but all the rest of our users as well.
video-two.png
Marketing Videos
LOW/MID DISRUPTION, HIGH EXCITEMENT
Our marketing department when I joined Kangarootime was  only one person, and so unable to spend much time making useful artifacts for dev teams to pass along to users. So I made my own. I wrote and recorded scripts, captured screens and created graphic visuals, and edited them together in Camtasia. I saved these for the most exciting features, as you might expect.
browser.png
In-app Guidance
MID/HIGH DISRUPTION, ANY EXCITEMENT
With a "dumpster fire," a little bit of disruption was necessary to create a good experience, and disruption often warranted in-app guides. Depending on the story, we might just add some context, or provide an entire click-through of the feature. We used this sparingly to avoid what I lovingly call "modal fatigue."
FINAL PROBLEM:
TOO FEW RATINGS
Like I mentioned, the app was new. We had less than 50 ratings at the time. I had designed one of our key results to be focused on increasing our app store rating, and so we took on the simplest experiment to possibly achieve that. We pushed a prompt to users asking them to rate the app. It's important to note here that measuring satisfaction with app store ratings is inherently risky due to the public nature of them. Make a push at the wrong time and you may get valuable data but sacrifice the perception of your product.
SOLUTION:
PUSH IT REAL GOOD
We were patient. We started implementing our change management strategies. We fixed the bugs. We ground our teeth and bit our nails. And then we sent out a push. It was biased for sure - we asked them "Are you enjoying our app?" and if they said yes, we prompted them to rate it. If they said no, we asked for feedback. We received tons of helpful feedback this way - it played a major role in crafting our opportunity solution tree for the following quarter.

Results & Reflection

We started at 1.8 stars. The key result I'd set for us was a roof shot for sure, which was to get to a 4.0. By the end of the quarter, we had moved from 50 ratings to over 300 with an average of 3.9 stars. By the end of the next quarter, it was a 4.3. To say that I am proud of the work we did is an understatement.

Our whole team worked their butts off to make this happen. It took lots of patience, tons of collaboration, a cheeky little homepage aesthetics update (one of the reviews said the app "looked like it had been built by high school students"), a bunch of mistakes, and a lot of trust building between all of us as we were an entirely new team. We came out of that first quarter together as a strong unit - unafraid to challenge each other and with some well-earned pride and perhaps a small dose of hubris. Don't worry though - we were almost immediately slapped with a huge list of commitments for a potential big client and that knocked us down a few pegs. But that's a story for another day!
Asset 1_edited.png
bottom of page