How to build 0-1 exploratory products

A year and half ago, Alan decided to build a back pain solution. At the time, our overall objective was hazy: all we knew was that back pain came up incessantly when we spoke to customers and public health data showed the same—⅔ of the French population had back pain just last year.

12 months later, Alan now provides a back pain offer that includes 60 exercises, teleconsultation, chat with a physical therapist, and light gamification. In the past month alone:

But the road to get there wasn’t easy. We worked within Alan’s Explore/Expand framework, spending several months in the exploratory phase to find product market fit and then a big scaling phase to ship and launch to 500,000 members. 

The challenge was daunting: how to encourage members to make progress on a physical health problem over several weeks entirely inside a digital app? Below are our team’s tips for tackling an exploratory topic with verve.

MVPs can be too tame. Without an ambitious vision driving you, you lose steam fast. We asked ourselves, “What’s the coolest thing we could build—something we’d be excited to share with the world and personally love to use?” If you’re not excited about it, users won't be either.

We incessantly asked, “What’s the fastest way to get this in the app so we can learn?” For example, we wanted to test a big idea: teleconsultation. Instead of overthinking it, we shipped it in only one sprint by using shortcuts like Calendly and Google Meet.

Drastically limit:

In the past 4 months, our PM took the back pain program entry survey 96 times. Doing so helps you call problems out asap and fix them just as fast.

Despite many depressing usage graphs that initially looked like this 📉, we laughed a lot! Our mindset was to be pessimistic/realistic about individual iterations but optimistic about long-term success because we knew we had the right vision and the right team. The team must love working together; you can’t ride the rollercoaster without it!

Once we were assured we had a product worth launching widely, we completely adjusted our way of working. Whereas before speedy and creative iterations were the key to success, now we needed a longer-term plan to ship to more than half a million members. A few things we learned:

While the 0-1 phase is more of a zigzag that requires a lean team to wear many hats to make progress on a problem, the 1-10 phase is like a train moving full steam ahead that must arrive at the next station no matter what.

At the beginning of the Expand Phase, the PM created a Google Sheet defining for each topic:

We checked on this sheet every week to call out risks in our delivery. 

That said, just because we were scaling didn’t mean we could no longer test iteratively! One important thing was reflecting deeply on the question: what is the ideal journey of a user discovering our product? 

We adapted button copy, email messaging, and even broader in-app flows to ensure that members were learning about our back pain solution in a way that made them most likely to use it as intended. 

Our exploratory team loved the 0-1 phase and found ourselves a bit discouraged in the scaling tunnel. To remedy this, we allowed for mini-moments of delight where we’d take a couple of days to add a killer animation or rework a flow. 

Balancing in this way can help team members bring more energy to the scaling phase. 

Normally Alan’s framework has product initiatives moving from Explore to Expand and then to Run—aka we let the feature sit and only invest to fix bugs. 

But our ambition for back pain has grown as we’ve worked on it. To fully embody our role as a health partner for our members, we want to verticalize healthcare.

So the next big challenge is to return to Explore Mode and determine how we can build on top of our existing back pain offer to prevent visits to osteopaths and physical therapists that could be addressed with our own solutions. 

It’s another big challenge that requires changing members’ mental models and habits, but one that we’re excited to tackle!