top of page
HILDA MYER-POST


Reach for the Stars
Case Study:
INTRO
I started my job as a PM at Kangarootime by inheriting a mobile app with an app store rating of a whopping 1.8 stars. That's every product manager's dream, right? That might sound sarcastic but actually there are some real benefits - I had an easy, measurable, tangible way to measure my team's progress towards a goal. Was I nervous? You betcha. Did we absolutely smash our goal? You betcha again.
THE APPROACH
I started out by digging. I dug and I dug. The app was only a few months old. How the heck had we gotten slammed with bad ratings and review so quickly? I read everything (for example, one reviewer called the app "hot garbage") and talked to everyone I could find (development, design, customer success, implementation, support, and of course customers) and several patterns began to emerge.
Problems & Solutions
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.

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.

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.

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!

bottom of page