Leader Spotlight: Building stickiness into mobile apps, with Joe Peterson
Joe Peterson is Product Director at Ookla, a comprehensive network intelligence and connectivity company. He began his career as an auction seller relationship manager at Overstock, where he transitioned to product management and spent eight years in various functions in the company. Joe then joined the product function at Rakuten Advertising and, later, Name.com before moving back to Overstock, where he became Senior Director of Product Management. Before his current position at Ookla, he served as Vice President of Digital Products at Wynn Las Vegas.
In our conversation, Joe talks about how mobile app conversion is about the same as that of desktop sites, and why companies need to optimize their mobile app experience to stay competitive. He shares his experience transitioning to focusing on mobile app downloads and daily active users as success metrics, as well as the importance of keeping the product’s critical path unchanged.
Shifting focus from conversion to app user retention
You’ve worked for companies like Overstock and Wynn Las Vegas, where the goal was web experience conversions. That is not the goal at Speedtest, so how has your role as PM evolved now that the focus is on building mobile app stickiness?
At Overstock and Wynn, the success of both companies depended on conversion. Thinking about hotel rates, as an example, there’s a finite number of hotel rooms you can sell in a given resort. As your conversion rate goes up, that means your prices can go up as well. If people are converting at a higher rate, there’s less inventory, which means there’s more demand and, therefore, you can increase prices.
When I joined Speedtest, it was very different. Our conversion is not placing an order or checking out — it’s taking a speed test. Pushing the “go” button is one of the easiest things you can do online. It’s really simple, and there’s not a whole lot of optimization you can do there. The challenge becomes more about the speed test app.
That was eye-opening for me, and even though people always talk about app stickiness, Speedtest really showed me why that was. The way I look at it, the Speedtest website is a movie theater, and the Speedtest app is the popcorn. We want you to come to the movie and watch it, which means taking the speed test, but we ultimately want you to download the app as well. The benefit of the app is that there’s more information available, and mobile apps convert at the same rate as a desktop site.
In general, I think this is the direction the industry is going in. Getting people to download your app is going to be your company’s North Star because everything else works out downstream. If they download your app, there’s a good chance they’ll keep it. That’s been the fun part for me — shifting focus from getting people to convert to giving them a path and reason to download the app and keep them as a customer as long as possible.
Speaking of your North Star, what is your North Star metric for mobile engagement, and how does that metric capture long-term stickiness?
I think the best North Star metric is daily active users (DAU) on our respective mobile apps. We can do a number of things to get more downloads, like optimize our app store presence, but if they’re not using it, that’s a larger issue. The DAU number is more reliable than downloads because it means people are actually using the app. Also, it’s usually a one-to-one with tests, so if a user opens the app on a given day, they’re probably going to take a speed test.
With that said, we’ve tried variations of monthly active users (MAU) and the DAU/MAU ratio, but I think daily active users is the best measure. We even looked at performance tests as a North Star, which, as a company, is a helpful metric. But for the apps and consumer team specifically, we try to focus on daily active users because even if they don’t take a speed test, we just want them to get on the app and not delete it.
Mobile apps as the future
You mentioned the industry as a whole heading toward mobile app downloads. How should PMs be thinking through that movement to mobile?
There are a lot of popular web applications that don’t have a mobile version, and that’s probably hurting them. Mobile apps are the future, and in my experience, mobile websites don’t convert well. They’re not very sticky. Any of the solutions I’ve seen out there don’t replace a real mobile app, and mobile app development is simpler than it’s ever been before.
The nice thing about an app is that the mobile website can then just be your marketing tool to get users to download the app. That’s the approach we take, and I think it’s the best one. Otherwise, if you’re constantly trying to optimize mobile web, it’s not going to give you the same return on investment that a mobile app would because the conversion rate is lower and the customer mix is totally different. Whereas, if you can get your existing users onto your mobile app, you might have a better chance of progressing in your goals.
Further, mobile phones are only going to get more powerful. People are upgrading mobile devices way more often than their laptops or desktops. It’s a no-brainer at this point — if you haven’t figured out that you need a mobile app, now’s the time to think through that.
How does great mobile UX translate into better outcomes for the enterprise business as a whole? What’s the ripple effect you see across quality of data, insights, and even partner value?
Ookla has been doing this since the beginning. We got a little bit of a head start on this because Speedtest is our speed test application, so having good brand presence definitely helps in that regard. As far as the UX goes, it’s important to have a good experience that users want to come back to. It’s the tide that lifts all ships.
Bad UX is a poor representation of the brand. It directly shows how seriously you do or don’t take the application. You can see the priority of a given product based on how much a company puts into it, and with that, we want to give our users a stellar, professional experience. We want it to look like it’s intentional.
We try to be very cautious about serious changes, and whenever we do make a change, we ensure it’s A/B tested and complementary to the existing experience. A good example is our experience ratings on the Speedtest app, which we launched a little while ago. We’re scoring people’s internet results based on the output of the test because a common piece of feedback has been, “I don’t understand my results,” or “I don’t trust my results.” Also, when users respond to a well-integrated feature that improves the UX, enterprise customers are going to notice it tenfold. Our success is their success, and every time we make a change to the Speedtest app, whether consumers notice or not, the industry notices.
Maintaining the app’s critical path
Features like Ookla’s Downdetector add value to the app but also risk cluttering the core experience. How do you balance adding engaging features with protecting the app’s critical path, i.e., the speed test itself?
It’s a good question — we think about this all the time. As far as the critical path goes, we don’t want to change that. The go button is still the go button. We added a feature called network status that tells the user that they’re connected to the internet, but it’s still the go button with a color change. It’s subtle, as we don’t want to change things too much in that critical path.
As the speed test kicks off, there’s a lot of information there, so we try not to add anything to the speed section of the test. Instead, we’ve implemented our cards framework, where users can have the speed test module at the top of the app with subsequent modules that load when they can.
Speed tests generally use a lot of data, so we also don’t want people to be running two speed tests at the same time. We don’t want people to be downloading giant files either, since that will mess with the results. With anything we do, whether it loads an ad, Downdetector content, or experience ratings, we want to make sure that there’s no impact on the test itself. We also ensure we A/B test everything so we know the results definitively.
Speedtest is used by hundreds of millions of people worldwide, each with different motivations. How do you design experiences that feel equally valuable to a casual user who’s just checking their Wi-Fi and a power user troubleshooting their network?
There’s a lot going on with the speed test, so it can often feel like a big cognitive load for casual users. It’s like when you’re looking at your cart and there are these discounts, taxes, another discount, and all these numbers on your screen.
I think it’s important to keep the important stuff clear. The number one thing people care about is their download speed, so we first show them the ping followed by their speed. Also, we’ve enabled a quick and easy test on the mobile website for people who don’t want to download the app. We try to have things like that to satisfy a more transient user who’s just there to take a speed test and move on. Again, don’t mess with the critical path — just highlight the stuff that most people care about.
With power users, however, they care more about things like loaded latency measurement. There are also expectations of power users versus expectations of the industry. When we were expected to implement loaded latency, even though most users would not know what that means, we did it because that’s the direction the industry’s going in. If we’re the killer app in the industry, we knew we needed to stay ahead of the curve. Other companies like Apple are taking this more seriously, so we’re doing the same.
Focusing on the product’s ‘so what?’
How do you balance innovation with staying reliable and core to your product’s purpose?
We have to support our users, but we also have to be on the cutting edge of new features. It’s important for us to stay ahead of the game by responding to the industry. At the same time, we also have to stay true to ourselves as a company. We have ads on the app, but people don’t like ads by nature, so we try to give people the option to go ad-free.
As far as new features go, it’s a balancing act between what we do for new tech and what we do just because it’s a good idea. One feature we just implemented was to compare their speed results to providers in their area, which was pretty brilliant. That was very important to the typical user who wants to see if they’re getting their money’s worth from their internet provider and how it compares to everybody else. And with our more advanced users, we’re doing a lot of things under the hood.
Overall, we want to ensure we’re being honest and upfront about what the data represents. When the gauge goes up and down, that’s not just magic — it’s a representation of the actual changing of the download speed based on what we’re doing in the speed test. We’ve got to have a nice-looking gauge that represents not only a good experience, but an accurate one.
By giving users context into those insights, aren’t you solving the ‘so-what?’ moment that creates reasons for them to return to the app?
The “so-what?” is key for the speed test. We try to present all the information as clearly as possible during the end-of-test experience we give to our users. On a retail website, the comparable thing would be an order confirmation page, which most people probably just throw away anyway. It’s a very different situation because the end-of-test screen, i.e., the “so-what?”, is very easy on the retail side, but in our industry, we have to both tell users the information and why we’re telling it to them.
The importance of strong mobile UX
How do you ensure that the mobile app feels like a natural extension and not a replacement of the web experience?
With Speedtest, we were faced with a question of, “Are we going to drive users to the mobile website or the mobile app?” We decided to go with the mobile app, so now, if you go to speedtest.net on your phone’s browser, there’s a banner that tells you to download the Speedtest app. That’s one thing we do very well — our mobile app gives users everything the website can and more. It has more features, it tracks more things, and it’s a more handy tool. Having a mobile app that’s not just complementary, but superior to your mobile website experience is going to be key.
If you’re the type of company that prefers a mobile web experience, then by all means, make the mobile website great, especially if you have a budget for it. But we’ve found that the mobile website is the entry point, but the mobile app is what we’re trying to actually communicate and offer to them.
What have you learned about sequencing that transition from bringing users from web to app, and how do you sustain that engagement once they get there?
You need good UX designers and strong engineers. A lot of the success in my career has been because I’ve had an amazing team who have been able to take whatever it is I’m saying to them and translate it into something even better than what I was asking for. A strong design system that makes everything look aligned is such a challenge, so that global system that makes everything match and look cohesive is so important.
That was a specific challenge we faced at Wynn — the website didn’t match the mobile app, which didn’t match the nightlife website. We added a global header that made the whole website look the same, and then we copied that color scheme to that project on the mobile app and website. Once we did that and there was harmony across all the apps, everything improved.
At Speedtest, there’s a clear consistency across all of our applications. This is something we take for granted, but when you see it from the other side, it really stands out and becomes obvious. It’s so important to have strong UX standards and harmony across all the applications.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.