From the outset, some models/frameworks inform (or get embedded) in a founder’s way of seeing and approaching challenges. Some invented. Some borrowed from the industry and deftly recalibrated to fit a startup’s unique contexts. All hired for particularly perplexing situations and jobs to be done.
This Relay interview series is a vehicle to document some of those very perplexing moments, the promising models that followed and the change they brought about. A documentation that, we hope, would help fellow founders probe some of their own early-stage obstacles more methodically.
In this exchange, Lou’s co-founder and CEO, Rachel Pardue (@rachel), lucidly recounts the mechanics of building a self-serve engine, aided by continuous customer research and an evolving grasp of the freemium model.
The strikingly impactful framework:
Back in March of this year, we relaunched Lou as a freemium self-serve product. We knew for this model to be successful, we would need to be able to onboard, convert, and support thousands of users.
To make this possible with a small team, we focused on making Lou product-led:
- We redesigned the product to be fully self-serve,
- added in-app guidance to make onboarding to Lou seamless,
- built upsells into the user journey,
- and then internally we automated milestone tracking that triggers timely email follow-ups to users at each stage of their journey.
The self-serve version of Lou was a hit, and the freemium model was what we needed to bring Lou to market. We went from only a handful of companies signed up to Lou to over 1,000 about 6 months later.
The preceding (exacting) situation:
We had to overcome the pushback we received a lot in the early days, which was that many companies didn’t want to trust the most critical moments in their users’ experience to a new startup.
To gain their confidence, we wanted to give our users the chance to experience Lou’s value before having to pay. This landed us on a generous freemium tier where companies can sign up, build unlimited experiences, and then publish 1 tour & 2 announcements live.
We had first tried a more traditional sales approach to launching Lou. We were doing outbound sales, booking demos, and entering a long sales process of emails and video meetings for months.
Finally, companies would sign up for a 2-week trial, but then at the end of the trial we often heard they needed more time. And the sales cycle continued…
This model wasn’t working for our team, and it wasn’t right for our product. Much of Lou’s value comes from its groundbreaking ease of use. We decided it was time to let the product speak for itself.
We had to take the leap of faith to do everything the opposite way of how we had been before. It was a redesign that would take months to launch. However, since our business model wasn’t working, we decided we had to make a big change and fast while we still had enough runway to pull it off.
The 0-1 of adopting the framework:
First we evaluated how to rebuild our core product to make it self-serve.
Before the redesign, our product was focused entirely on allowing companies to build and deploy multi-step product tours without code. The V1 of Lou was fully configurable, but it left the process of designing the tours and coming up with the use case and content to the users. Many of our early users got stuck here with ‘analysis paralysis’.
We conducted a series of user interviews and watched users try to go through the onboarding process over video calls. We learned that there were many simpler use cases users wanted to accomplish with Lou than just product tours.
These included things like announcing a new feature, making users aware of upcoming maintenance, and more general announcements. We then expanded Lou’s feature set beyond product tours to include one-step announcements and later onboarding checklists. Now 49% of all experiences built are announcements.
To help users make decisions about what experiences to build, we launched a series of templates that users can start from. The templates are pre-built experiences for our most popular use cases, and they help users get started faster. Today, 70% of all Lou experiences that are built are started from a template.
Next, we broke the process for building Lou experiences down to 4 steps.
- Build (creating the product tour, announcement, or checklist),
- Deliver (deciding which users should see it),
- Track (tracking the success of the Lou experience),
- Publish (making the Lou experience live to your users).
This helped make Lou self-serve because our users understand that there are 4 steps to publish their experiences live, and by showing them one at a time it helps keep the process simple and not overwhelming.
After our core product, the Lou Builder (which is a chrome extension) was redesigned, next we evaluated the dashboard. The Lou dashboard is where our users first land when they create an account, and it’s the place they keep returning to to evaluate how their experiences are performing.
In the same user interviews we learned that when our users landed on the dashboard for the first time, it felt empty because they did not yet have any experiences or analytics to look at.
One of our advisors explained it like staging a home before an open house. You’re much more likely to make a sale if a buyer walks into a beautifully furnished home than an empty house. It’s the same with software.
You want to sell the vision of what it will look like once they invest the time and money to use it. We built fake experiences, charts, and graphs to show new users an example of how the dashboard will look. Once they build their own experiences the example data goes away.
Great UX was only the first part of the equation. Secondly, we evaluated how to leverage in-app guidance to make Lou truly self-serve.
When a user first signs up to Lou, they land on our dashboard. We knew it was important to have a clear path to success lined out for new users here. We decided the most effective way to do this would be through an interactive onboarding checklist. The checklist outlines the 4 steps new users need to complete to be onboarded to Lou.
The checklist has clear call to actions and can link to product tours to guide users through how to complete an item if they need additional assistance. They also automatically check off once an item has been completed which helps to keep new users motivated to get all the items done.
Additionally, whenever a user clicks to explore one of our features for the first time, like segments, they’re greeted with an announcement that explains the new feature and how to use it.
These in-app training experiences along with the changes we made to the Lou Builder and Dashboard has enabled Lou to be a completely self-serve product. All of our users onboard themselves, and Lou users who publish experiences live to their users tend to do so in about 1 hour.
Finally, we built upsells into the product.
We chose not to limit the build experience because we’ve seen that the more time and energy a company invests into building Lou experiences, the more likely they are to convert to paid in order to share those experiences with their users.
Instead, we put limits on collaboration (team seats), the amount of personalization (custom user segments), and insights (A/B testing, goal tracking, & integrations) companies can access in the free tier.
By limiting these advanced features to paid tiers, it nudges companies to upgrade when they’re ready to move past the basic implementation of an onboarding tour that goes to all new users, or new feature announcements that are seen by everyone.
For small startups, it means many of them can live happily in the free tier until they grow, but large companies tend to upgrade before publishing Lou live.
Whenever a user reaches one of our freemium limits, like if they try to build a second product tour, it triggers a message to upgrade to a paid plan.
We left the UI elements of paid features visible in the freemium plan, but then when a user clicks to access them, they get the same upsell message. This helps us to convert users to paid by nudging them to upgrade at the moment they need a paid feature.
Constraints and challenges:
With a product-led onboarding experience, our product does do most of the heavy lifting, but there are still a lot of users that stall before becoming fully onboarded.
We rely on email outreach to nudge these users along and learn why they stalled. With a small team but thousands of users, our biggest constraint was time.
We had to figure out an effective way to automate most of this outreach.
We began by breaking up Lou’s onboarding process into milestones: created account, built first experience, installed script tag, and published experience. We’re internally tracking when users reach each of these milestones, and we built an integration with our CRM so that each company will automatically move into the right stage of the pipeline.
Initially, we built a 30 day onboarding email flow that all users would get, and we were relying on our Biz Dev team to reach out manually when users reached each milestone.
We learned our onboarding process needed to be more milestone-based than time-based, and we also didn’t want team members to be spending a majority of their day writing emails. We redid our email outreach to Lou users by using Klaviyo to build various email flows that are triggered to start when a user reaches each milestone.
This allows us to send targeted emails at the moment it’s most relevant to users. Our email flow also includes surveys and requests for feedback whenever a user hasn’t moved to the next milestone in 2-3 weeks.
This helps us to learn how we can keep improving our product and onboarding experience, and the user feedback gives us further insights into what kind of companies are and aren’t a great fit for Lou.
We still have the emails set to come from our biz dev team members’ emails even though they’re automated. When a user emails back, all responses go to the designated team member’s inbox where they will manually reply.
With the exception of the first few “welcome to Lou emails”, we also opt out of using branded templates and stick to plain text emails that look like they’re coming straight from Gmail.
These methods help to give the feel that even free users have a dedicated account manager, and it allows our team to build relationships with our users. We’re lucky to have a team to help, but this could easily be replicated with a founders email for earlier startups.
Lastly another challenge that came from supporting so many free users was handling support tickets. We created a support email and signed up for Help Scout to manage support ticketing. Help Scout keeps all of our support tickets organized in one place, allows us to delegate tickets to different team members, and ensures that a ticket doesn’t go too long without receiving a response.
Luckily, because of our product-led onboarding experience we almost never get support tickets asking how to do things in Lou. They tend to be technical challenges users are running into or feature requests which are few in quantity and manageable.
Then it’s a challenge to serve a B2C business with a small team but hundreds of thousands of low paying users while also serving a B2B model with a large team but only a few hundred high paying users.
Our current pricing model is a good starting point that’s working well enough to see paid conversions into every tier and is helping us gain learnings that we can use to serve our customers even better down the road.
Signals of change:
Our biggest challenge before switching to a product-led strategy was getting companies to try Lou. Just 6 months after launching with our freemium model, over 1,000 companies have signed on to Lou.
Once we had companies signed on to Lou, the focus became how to get them to publish Lou live in a timely manner. Since the redesign, over half of companies that are live with Lou published their first experience just 1 hour after signing up.
One unexpected signal is that most of our paying customers converted to paid without ever booking a demo or sales call. They went through the conversion process in-product by themselves. This was a huge change as I used to spend 70% of my week in demo calls, and now I have about 1-2 demos a week.
Finally, the best signal that our redesign paid off is the feedback we get from users. They’ve rated Lou at 4.7/5 stars and have ranked us in the top 3 Digital Adoption Platforms based on user satisfaction in G2! It’s such an awesome feeling to hear that teams love using Lou and that it’s making a real impact by helping companies onboard, engage, and retain their users.
Concluding notes for a fellow founder:
Talk to your users.
Our users are the ones that showed us the gaps in our initial launch and taking their feedback into account enabled us to pull off a successful relaunch. I send surveys to every user and frequently get on calls with freemium and paying users to learn about their experience, but I still don’t think I talk to enough Lou users.
When it comes to user feedback there truly is always more to learn.
My biggest advice for the early days at a startup is to experiment relentlessly until you find what works. In my opinion, the biggest risk as an early stage VC backed startup is wasted time.
If I had it to do over again, I would’ve made the call to do the freemium redesign sooner. If what you’ve been doing ceases to work, don’t be afraid to make big changes.
So I think it’ll also be really useful to hear how much (if, at all) the team structure had to change to suit this transition. In what ways, different teams have had to adapt to a more product-driven approach?