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:

• 1800 members started the back pain program
• And have shared some outstanding feedback like, “The exercises are better than what I had at the physical therapist’s office” and “I no longer feel pain in my lower back when I lift my 18-month-old daughter from her crib.”

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.

Success on an exploratory product

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 (minimum viable product) are overrated; be bold on vision!

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.

👷 But while you’re bold on vision, be scrappy with execution

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.

👊 Focus more than you think you need to

Drastically limit:

• Your scope. Originally, the crew was also building a mental health program. We stopped to go all-in on back pain
• Your team size. 4–5 people max can go very far, very fast. It means less time finding alignment
• Your objectives. The crew had an adoption goal and a satisfaction goal. We dropped one to avoid tackling two tough goals simultaneously
• Your features. As soon as it’s clear something isn’t working, kill it and be proud of your feature graveyard. Don’t get stuck in an endless iteration loop; look for the next big thing.

🐶 Use your product constantly

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.

💀 If you’re doing it right, you should be having fun!

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!

Enter the scaling phase

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:

☘️ Define super sharp ownership

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:

• what questions needed to be answered
• the LOCI (Lead, Owner, Contributors, Informed)
• the deadline

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

☁️ Test with soft launches

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.

🍏 Come up for air with moments for member delight

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.

And now what? Do we move to Run Mode?

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!