4 things you can do to minimise the cost of building your onboarding experience
So what’s important for a product’s onboarding to keep expenditure to the minimum? Here’s what we think is absolutely necessary:
- Prioritize flows and features for highest ROI
- Reduce the number of assumptions down to the lowest possible
- Build as little as possible and design for evolution
- Bring the whole team together earlier in the process
What do we mean by all of this, you ask? Hang on, we’re just getting started! Let’s dig a little deeper:
Prioritise flows and features to generate the highest ROI
Reminder alert! Customers are like you and us: human. Too much information too soon can be overwhelming. It’s in everyone’s interest to keep onboarding crisp and to the point. This invariably keeps the flow condensed, and your costs low.
But how might we do this for a product that requires a whole lot of data to work effectively from an ambiguous customer profile? We ride on this: The Pareto Principle. Designing a flexible onboarding that might work for different kinds of users is not going to work for anyone.
At Pause, we designed for the most important users — the 20% most likely to contribute to 80% of our revenue. We trimmed our flow down to optimise for the most lucrative path.
Hot tip: Don’t make the mistake of giving users multiple paths; you’ll only end up confusing them. As you grow, you’ll discover customer bases you’re not even aware of, and the other paths would ultimately become less relevant.
Reduce the number of assumptions down to the lowest possible
“It’s a commonly held view that tailoring the product too narrowly to a smaller target market means that growth will hit a ceiling — but I don’t think that’s the case.”, says Rahul Vohra, founder of Superhuman in his insightful post on PMF. Focusing an MVP on customers who need your product as opposed to those who might want it someday is a wiser investment, says Vohra.
For Pause, we used Occam’s razor to trim our core target customers to agencies and early-stage startups with small teams (10-75 people). Narrowing our target group meant that we could prioritize features that were directly relevant to them, saving us both time and money.
As counterintuitive as it might sound, this approach lends itself to laser-sharp focus and decisive decision-making. Growing across target segments or lateral feature sets can always happen in the growth stage of the product life cycle, once PMF has been achieved.
Build as little as possible, and design for evolution
It’s tempting to design entirely new flows and components for different parts of your product. In fact, it almost feels like a requirement.
However, the load it creates and the inefficiency it breeds for all stakeholders is high and much better avoided. Prevention is better than cure, right? Where this applies to most of product building for early-stage products, it applies 10x more to onboarding. Why?
Onboarding is where you’re getting your customer familiarized with your features. It shouldn’t require a different flow for the same set of features. Where certain tech constraints might demand alterations in this approach, finding a way to maintain your regular features within onboarding is a cost-effective and user-first choice to make.
This is also the most scalable way to keep your onboarding up-to-date. As your features evolve, onboarding will evolve as well.
Trust us, your features will evolve, especially if you’re factoring user feedback back into your product.
Bring the whole team together early into the process
Product building may appear linear, but it sure as heck isn’t. Design-thinking is a good starting point, but it’s more a mindset than a rigid framework. Isolating different stages of the building process from stakeholders who are seemingly irrelevant to the step is a mistake in the least, especially for high stake features like onboarding. But, how does this impact costs? Let us explain.
For Pause, involving and prototyping with engineering helped us ship our onboarding experience quicker and made it crisper. Early collaboration meant we could combine the niceness of design thinking with the constraints of coding earlier in the process. That led to a shorter turnaround time on feature deployment.
Might we add a collateral benefit to the mix? Designers learn to think systemically like engineers and engineers write code with a greater empathy towards the user. The result is a truly user-focused product that is built upon a scalable and clean system. Now that’s the dream, isn’t it?
We hope this guide brought value to you. If you have any ideas, questions or follow-ups, use the chat icon to write to us.