Building a Referral Feature — MVP Style
“Does your business need a referral program?” is almost a rhetorical question for growth managers nowadays. Referral programs have been proven to be the most powerful marketing channels in many different ways. The Nielsen Study of 2016 proofs this in a data-driven way. The case study about Dropbox or the inspiring tech talk of Jimmy Tang and Gustaf Alströmer at Airbnb proof this on a practical level.
The question is then: When you know that a feature or rather a marketing channel is considered the most powerful, why would you even need to build an MVP version of it and cannot just start building it natively? The answer lies in the challenge of every young company. There are millions of great ideas but not enough people or rather developers to execute all the ideas. Luckily, however, there is something in between building a feature and not building a feature. You can build a small version of this feature and test to what extent it would help you and how to actually embed this feature in the customer journey.
For this challenging task, it is not even necessary to have a fully functional referral feature available. With your work, you are rather collecting reasons why the referral feature should be built natively as soon as possible. This is why I want to provide a framework and a methodology that can be used by even the smallest one-man growth department to show what referral programs can do for your business.
Want to read this story later? Save it in Journal.
Intro
We are assuming that the company in which a growth manager works has either a website or a mobile app or even both.
When I am talking about referral programs, I mean the feature that rewards a current customer for promoting and spreading the word about your product or service to potential new customers. In the following, I will call the customer promoting the product an advocate and the potential customer being invited to the product a friend.
Smoke Test MVP
The easiest step is to display a referral feature only via the Smoke Test MVP. This is a common concept in lean startup terminology. It is used to test or validate if there is any kind of demand for a feature at all. It literally means that you tease or show a feature at a certain location in the customer journey but do not really implement any functionality.
In the case of referral this could mean that in your app, you can show the referral button (click here to invite your friends) after the customer performed a certain action. This would show you if the customer would at all consider clicking on a button that conveys the idea of a referral program. When customers click on this button you could either simply show them a “coming soon” screen or ideally ask them something relevant for your referral program.
The same goes for your website. Here, even less effort would be required. You could simply use a Hello Bar that pops up any time the customer visits your main page and then show a branded landing page to collect some special information about the customer. You could even use this setup to ask the customer about his idea of an ideal referral program.
The benefit of using the smoke test is that the first conversion from advocate impression to advocate click can already be tested and worked on without any functionality being available. This basic setup can show you a benchmark on how many people would click on the referral program if you advertise it on one, two, or multiple steps in the user journey.
Concierge MVP
The Concierge MVP can be considered a bit more sophisticated than the smoke test since there is at least some functionality involved. The idea behind the Concierge MVP is that all the functionality is actually performed manually by a human. Generally, this way of testing a feature is performed in a rather early stage, since it clearly requires a lot of time and effort to perform all the tasks by a human. Consequently, this is also not the most scalable solution. However, it helps you to understand how the customers want to perform a feature or how they want to use the product.
In the case of referral, this could mean that after the customer entered the referral experience in your app, he gets taken to a screen that will lead him to a live chat window. The concierge will interact with the customer in real-time and ask him how he would like to perform the referral and to whom. Alternatively, it is possible to really do this via phone by presenting the customer with a callback button through which he will be called back as soon as possible. Or the customer can specify an exact time and date when he wants to be called by the concierge. The concierge then gets in touch with the customer and collects information about his referral and manually executes the referral by getting in touch with the friend of the current customer.
While this sounds like a lot of effort for a more or less standard feature, it helps your business to better understand what the customer wants. Therefore, it is important to have concrete questions about the implementation of this feature. For example: Which platform would the customer use for the referral? How would the customer ideally confront his friend with the referral? How many friends would he like to refer ideally? What incentive will make sure that the customer will use the referral feature? All these questions can be easily answered in a Concierge MVP.
Wizard of Oz MVP
The main difference between the Wizard of Oz MVP and the Concierge MVP is that in the case of the Wizard of Oz MVP, the customers do not know that there is human action involved in the process of using the feature or product. You are rather creating the illusion of a feature or product that is fully functional, however, only the front end of the product is. The back end functionality, which would certainly be necessary for most of the features is not yet created. The Wizard of Oz MVP could be seen as the next step after you understood what the feature or product is about in a Concierge MVP and now want to further work on it in different iterations.
In the case of referral, this could mean that after the customer entered the referral experience in your app, he gets taken to a screen that will ask him for the email or another contact information of his friend. After he submits the contact information the app will show the customer a success screen and indicate that everything was taken care of, while in fact only an event was sent to an employee, who will know contact the customer by creating and sending an email to him. Both advocates and friends will assume that all of this was done automatically.
While this way of testing does not sound much more sophisticated than the Concierge MVP, it can be used for many different product features. It would be easy to play around with the incentive for the referral and let the customer choose which incentive he wants to get for the referral. Also, additional features like a referral progress bar that shows if the friend already clicked on the referral link or even signed up to the product could be interesting and can also be maintained manually by the workforce. For at least some scalability, it is possible to use the Amazon Mechanical Turk Worker to perform these kinds of tasks manually.
Piecemeal MVP
The Piecemeal MVP is my favorite way of testing things out. Instead of using the human workforce like in the two other MVP versions, the Piecemeal MVP tries to reduce the amount of workforce needed to zero. This means third-party tools are used and integrated to perform the feature (in combination). The nice way about testing this feature is that most tools offer many branding possibilities and are easy to integrate. Thus, the Piecemeal MVP way of testing features can be more scalable and does not have to be replaced immediately through native applications.
In the case of referral, this could mean that after the customer entered the referral experience in your app, he gets taken to a Typeform that will ask him for the email of the friend that he wants to refer to your product. We then use Zapier to send this value over to customer.io along with a specific campaign code and from there a trigger automatically sends an email to the referred friend. Additionally, when the friend with this email registers he could get a special referral onboarding email through customer.io that is explaining to him that he has some extra perks since he came in through a referral. Also for giving the incentive automatically, there is certainly a solution to do this via automation depending on the tech stack and setup of the business.
This way of testing or rather enabling features is an important discipline for growth managers. Being able to onboard a new feature in a short amount of time using different automation and making it look acceptable requires a solid technical infrastructure built for experimentation, the knowledge of tool stacks that can mimic the features required and the skill to integrate these tools with automation tools like Zapier.
Especially in the early stage of a company, it is extremely important to have profiles with these kinds of skillsets. A single growth manager can onboard entire features like referral programs within a single day while this would take engineers weeks to integrate natively.
But also in the later stage where the growth manager is managing an entire team of engineers, designers, and analysts, it is crucial to keep working on features in this kind of setup. However, the experimentations become more granular and are assessed with way more data-support.
Outro
I already mentioned the Airbnb Tech Talk of Gustaf and Jimmy on how they worked on a referral program step by step. In this Tech Talk, they mention that it is not only difficult to work on the referral itself but also it requires a lot of work to convince all stakeholders to invest more in working on the referral program. It is not easy to make referrals really fly and ultimately a company can also think about creating an entire team around this feature alone.
The advantages of having a referral feature that really works are numerous. Especially for investors, KPIs like CAC and CLV are very important. And the (discounted) CLV should ideally always be bigger than the CAC. Now, referral programs can help on both sides of this equation. They reduce the CAC because you do not have to use classical (saturated) acquisition channels and they increase the CLV because suddenly a customer can even become an ambassador who can win you hundreds of customers. These KPIs can also serve as high-level reasoning for implementing the referral feature.
The referral is one of the last steps in the Pirate Funnel but that does not mean that it has to be late in the customer journey. In fact, I made some good examples of placing it right in or after the acquisition step of the journey. There are tons of things to work on when implementing a referral feature. With the methods described above, I wanted to illustrate that basically all of the hypotheses around referral can be tested and worked on without having a large interdisciplinary team right from the start. However, what you always need to consider is to very closely look at data every time you tested something.
📝 Save this story in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
