Today’s post is all about providing tips for a successful Beta Launch and smooth post-launch of your digital product! At this point in the product development process, you’ve (hopefully!) conducted discovery research, you’ve designed an amazing user experience that’s not only easy-to-use, but also looks great, and you’ve worked hand-in-hand with developers to bring your app to life. If you’ve done it right, you’ve maybe even fit in some iterative prototyping and usability testing to work out the kinks. At this point, you’re ready to launch your first Minimum Viable Product in Beta –congratulations! The successful launch of a product or site, after all of this hard work, is not often talked about in UX design. Surely, the work it’s taken to get to this point is something to be very proud of, but there are a few things to keep in mind so that you and your team can thrive in this next stage (and also so that all of this hard work performs when it reaches your target audience for the first time).
This post will cover…
-
What is an MVP and Beta Launch?
-
Why is it important to ACTUALLY plan for the launch?
-
Tips for your next Beta Launch and supporting users post-launch
What is an MVP and Beta Launch?
What is an MVP?
If you’re not familiar, an MVP (Minimum Viable Product) refers to the first release of a new product or major feature update. It’s used to measure demands and confirm the need for the product with its customers. An MVP is used to, “reduce development time and effort, an MVP includes only the minimum capabilities required to be a viable customer solution.” (Gartner).
We think the MVP concept is best explained through the Cupcake model! The Cupcake model dictates that the MVP is desirable and complete on its own. It has a filling, it has icing and decorations…no one complains about a cupcake, and that’s how your MVP should be! It’s great on its own and it doesn’t feel incomplete or as though features are missing. It has all of the allure of a cake but costs much less to produce. As more features are added in through subsequent launches and releases, the product will become more complex, yet it should always maintain its completeness and desirability. To paint a complete picture, you might move from a cupcake (MVP) to a Birthday Cake (Release 1), and then to a layered Wedding Cake (Release 2, 3, 4, and so on). If you’ve ever heard of the Dry Cake model, that’s never what we’re going for when launching an MVP. Dry Cake refers to the product having a lot of features, but it’s kind of broken, doesn’t work very well, and it certainly doesn’t look great. No one wants a dry, icing-less cake that is crumbling and falling apart!
View this post on Instagram
What is a Beta Launch?
A Beta Launch puts your product (perhaps your MVP) out to a small group of people in your target user groups in a slow and controlled way before it’s fully ready for the rest of the world to consume. In addition to testing the product and checking for bugs/software issues, a Beta Launch is going to validate your product and determine if it’s something users truly want and need. This is such an important step as the Beta Launch of your product is going to provide a ton of insight into your product’s future growth and performance in the market. Rather than spending significant time and money on launching your product, putting it out there, and potentially having your product fall flat, Beta Launching allows you to safely and smartly test your product without impacting your reputation or potential future customer base.
Why is it important to ACTUALLY plan for the launch?
Simply put, because you’ve spent a lot of time, money, and resources researching, designing and developing your app or website. It would be such a shame to see all of that incredibly hard work just go to waste! Any launch inevitably comes with software bugs, things you expected to work well but don’t, and unforeseen difficulties and usability challenges–this is completely normal! However, the challenge is that you may have enough experience to expect these things, but the same can’t be said for your users, customers, and even stakeholders. An MVP is sometimes their first impression of your product, service, or brand, so you want to make a good impression. You don’t want them disappointed or frustrated about a feature that isn’t available yet or having a bug in the system preventing them from accomplishing a task. Your users could decide to boycott your product entirely if not planned carefully, chalking your app up to shoddy workmanship. As a result, this could hurt your brand and impact long-term customer loyalty. Similarly, if your stakeholders aren’t made aware of some of these issues in advance, all your hard work to convince them of the importance of doing this new design and research work could backfire and you’ll lose their trust. They could even decide not to continue with the launch or new feature releases!
Planning for the launch means you can set your Beta users (and stakeholders) up with the understanding that not everything will be perfect at the onset. You can let people know which features will or won’t work right now and what they can expect in near and distant future releases. This open communication will set you up for long-term success! When people trust you and your product and comprehend that it’s a “work in progress”, they will continue investing in future launches and releases.
Four tips for planning a successful Beta Launch
We know that a successful launch is easier said than done. We also hope that before you launch you have thoroughly tested your application or site – both from a usability standpoint with actual users, but also from a quality assurance side of things (testing the software to reduce the number of bugs and glitches). There are many moving parts and it’s easy for things to go off course, but we have a few key tips that will help you to plan for a positive result and onboard your beta users properly!
1. Launch to a small audience
Ideally, you should plan to release your beta to a subset of users. You’re probably wondering, how many users should be a part of your Beta Launch? Well, the answer isn’t straightforward and ultimately depends on the industry, your goals for the Beta Launch, and the risk involved in launching the product. If it is a high-risk launch, because you haven’t fixed a lot of the known issues or because you are in a very competitive space, then you’ll want to keep the group smaller. If it’s a low to medium risk launch because you’ve resolved all known issues, completed numerous rounds of usability testing, and are confident in not only the app’s usability but also its viability (basically knowing that it solves a need) then go ahead and launch to a bigger audience! You’ll still want to keep this audience as a subset though, and can then gather more quantitative data about how beta users are using the app or site. Another point to consider is how complicated the experience is that you are creating. Is it a B2B product or a B2C product? In the B2B space, apps can be more complicated because they often deal with very particular subject areas (for example, a legal case management system, or network management in the IT sector). If your product deals with higher levels of complex information and processes, we recommend keeping your beta group small.
2. Set expectations
This might be one of the most important tips for your Beta Launch! Setting expectations is the best practice for any new endeavour, but is especially important when it comes to launching a living breathing application. As part of your onboarding process with users, make sure you set their expectations when it comes to what features are available, when new features may be released, as well as known issues. Lean on your project management skills here for top-notch communication. Make sure users know this is a Beta Launch and while you are so excited to have them join as part of your first release, there are bound to be issues that come up. Be clear about who to contact should any challenges come up and tell them you are looking to hear their open and honest feedback about their experience.
Similarly, you’ll want to set expectations with your stakeholders. They need to understand what to expect as part of this release and be fully aware of any limitations as well as possible setbacks.
3. Create a clear user guide
As part of onboarding your users, we recommend creating an easy-to-read user guide. This guide should clearly explain how the product is to be used, the limitations of the MVP or product, missing features, warnings of any known bugs/software issues, and anything else pertinent to the experience of your beta user. Hopefully, your user guide will also include instructions on what to do if there are any gaps in the experience (think: workarounds) and how to fill these gaps. For example, let’s say you’re launching an online portal to support a user in tracking and receiving payments. But, for the MVP, users won’t see a live payment update, and instead, it will take 3 days to see their payments. Let them know they have the option to call a support number if they need to see it more urgently. You can also include pictures and step-by-step instructions for any part of the process that might still feel a little clunky, although hopefully, this is minimal! At this point, the experience should be seamless and intuitive. Share this user guide with your beta users when you give them credentials to log in to your app or site.
4. Create a roadmap (and plan for future releases)
A feature roadmap is typically a spreadsheet-like document that lists all possible features down the first column, with other columns for priority, effort (small, medium, large), status, and release number. It should ideally also include a timeline in the form of a Gantt chart that shows when each feature is being worked, and by whom. While you might not share this roadmap with your users, it’s an important tool for your team and for stakeholders to understand what features will be included and prioritized as part of the initial release or MVP and what features will be left for a later release. Your roadmap is a living document that should be kept up to date by your product manager (or you!) and it should be regularly reviewed with stakeholders to make sure everyone is aware of the project status. You can also share a bulleted list of features that will be released later on with your users during onboarding.
Four tips to support users post-launch
We believe that when planning for your Beta Launch, a successful support experience is just as important as having a great product! You don’t want to taint your hard work by having a crappy rollout. Make sure you are in contact with and supporting your beta users during and after launch. Here are some ways you can get started on this. These suggestions are especially helpful if you work for a smaller organization that may not have all the resources available to you like an entire IT or customer support department.
-
Decide on a regular contact person for the beta users. Who on your team will be their main point of contact? Share this person’s contact information with the beta user as part of the onboarding process.
-
Schedule weekly calls with beta users – Try to have at least one meeting per week with a beta user during the first few weeks after the initial launch. This doesn’t mean you need to check in with all of your beta users every week, as that would be logistically impossible and also unnecessary. What you can do is invite one beta tester each week to a 30-minute to 1-hour feedback session. These can be as casual feedback calls or as usability tests. By doing this every week versus at the end of a 4-week period, over several days, you’ll be able to catch issues more quickly, so the team can make quick changes. You’ll also be able to see how the app is solving a user’s needs over time. For example, in many applications (especially in the B2B space) a user’s tasks and actions will evolve. In the case of network management, in the first week they may be onboarding devices, and setting up wifi networks and configurations, but as the weeks go on they will be transitioning to monitoring, reporting, and then perhaps troubleshooting their customer’s issues. To see how the MVP is supporting them through all of these phases of their journey in real-time is important vs. asking them about it a few months later.
-
Set up a support email – In addition to a key contact person, it’s useful to create a generic support email which could be an inbox that is triaged by multiple people on your team. Educate your users on when and how to email support. This will streamline the support process and reduce some of the tedious back-and-forths you might have with a user trying to tease out information. As part of your onboarding process, you could suggest that users use subject lines with prefixes like “FEEDBACK” or “TECHNICAL ISSUE” to separate urgent from non-urgent emails. For example, if a beta user just wants to share some general feedback with you, that may be less important to respond to than a technical issue which could be a bug in the system that is blocking the user from completing a critical task. Your team will be able to quickly prioritize which emails to respond to first if users know to intentionally label emails. To ensure this works efficiently, you’ll also want to tell your users what the response time or window is (for example, you will receive a response from our team within 24 hours). Make sure you pick a time that is sustainable and realistic for your team!
-
Create SOPs for how your team should handle support issues: Now that you have a support email – you need to get ready to answer those emails! We recommend creating a simple set of Standard Operating Procedures (SOPs) for your team which include:
-
The team member(s) responsible for triaging the support inbox and answering support emails. Note: You may want to have your UX Researcher be responsible for answering emails labelled “feedback” while your developers are responsible for answering emails labelled “technical issues”.
-
How should the support emails be triaged? (Refer back to point 3 above.)
-
Email response scripts for responding to support emails. What will you say and what questions or information do you need from them? Think screenshots, severity, contact information, urgency, etc.
-
How fast should the team respond to certain types of issues?
-
Where will the information be logged and how will it be logged? For example, new issues should be added as bugs or user stories in Jira, prioritized and added to the backlog.
-
Trust us, taking the time to come up with a process for how you and your team will respond to support requests ahead of time will save you countless hours and headaches once you’ve launched.
Ideally, this blog post provided you with a solid understanding of what it means to plan for your Beta Launch. Your Beta Launch is a critical time for you to make a solid impression on your users, validate that your product is needed and wanted by the consumer, and gather insight into the future of your product on the market! We wish you the best of luck in your Beta Launching phase and have no doubt that you will see success (especially if you implement our post-launch support tips!).
