An aspiring entrepreneur I’ve recently consulted told me that she’s done coding. As she’s a great programmer, I asked her what’s wrong. She was a capable technical co-founder, but, as it often turned out, she was too quick to assume that her ideas would sell.
They didn’t.
She was looking for a way to go against her instincts and validate the market without wasting time and effort on code. “I won’t code on my own again,” she exclaimed angrily. “No more rushed product ideas.”
Another entrepreneur I’ve spoken with complained that he can’t code—but he knows that he could sell. I didn’t disagree. He was an accomplished lawyer. He knew the industry inside-out. But for whatever reason, he couldn’t find a technical co-founder he would feel comfortable with.
“If only I could build an MVP on my own…” he sighed.
Seemingly, these two stories are strikingly different. But they are really the same at their core. The problem was that both entrepreneurs, as many others do, misunderstood the concept of MVPs.
MVP—a popular concept in the startup community—stands for Minimum Viable Product. It’s a product with just enough features to gather validated learning about the market and your potential customers. Clearly, the entrepreneurs from my story thought they can’t validate their ideas without investing in development. But I’m going to show you that building MVPs without coding is possible and that such MVPs can be sold in an attempt to validate almost any market need. No up-front investment required.
A common error is to think of MVP as a smaller version of the “final” product. I mean, we won’t have as many features, we’ll cut the scope, and we’ll simplify automation here and there—but more or less, it’s going to be the same thing as the fully viable product, isn’t it? After all, that’s what agile software development is really about, right? Maybe. But the beautiful thing about MVPs is that they don’t have to be software.
Instead, I’m going to teach you to think of MVPs as throw-away learning milestones. Learning is easier than development.
The first learning milestone is usually very simple: are people willing to buy the service I’m going to offer?
Many entrepreneurs think that they have to start development in order to find an answer to that question. But truth to be told, they can often do with much less. They think that agile iteration must be continuous, but in fact, it doesn’t have to; it can be fragmented, featuring steeper changes and low-fidelity products that can be thrown away.
In this article, we’re going to
Having a working order form and a functional CRM will allow us to start serving our customers manually without a software development team. We’ll be able to validate our riskiest assumptions much sooner and for a cheaper price. In the end, we’ll see what comes after our learning milestone is achieved—how to get from a throw-away prototype to a real product whenever we feel like we learned enough.
We’ll work on an example I know well personally—real estate.
Disclosure: my current startup is a real estate startup. We’re going to create a minimum viable product that finds accommodation for international students in a country with an obscure language where most landlords can’t speak English. The MVP should let students apply to a waitlist, pay for the service, and get an offer with potential listings later via email.
Our main learning milestone is finding the most optimal price to pay for our service. We want to know whether anyone will be so desperate to pay a small sum up-front in order to receive translated listings and have negotiations handled for them. Please note that we won’t be attempting to automate the apartment finding process—which means that most of the behind-the-scenes work will have to be done manually by our team members.
At its heart, a waitlist is just a lead collection mechanism. And a lead collection mechanism is, at its heart, a form. If you think about it, many products are just complex forms. For example, a Facebook profile in its update state is just a complex form. In our case, we’re going to need a form with a few important fields where tenants can write their housing criteria down and leave contact information. That’s what we’ll use Typeform for.
Typeform can build beautiful, mobile-ready forms that people love using. With its custom themes, online order forms, and conditional questions, Typeform is incredibly flexible—and you can test it for free. The real magic, though, begins with the premium tier. Firstly, it will let you use custom branding—an important feat if you care about your MVP’s design. Secondly, the premium tier comes with a Stripe integration. Thanks to Stripe, you can build a simple order form and take your first payments without even a single line of code.
Typeform should let us create a simple form that collects accommodation criteria from the students. Furthermore, if we have a Stripe account, we can connect it to our Typeform and collect payments at the end of the form. This way, we’ll be able to validate our business model by checking whether anyone wants to pay up front. So far, so good.
For the sake of simplicity, we’re going to create a simple survey with just a few questions (see figure 2.) Typeform is an extremely easy to use tool which doesn’t sacrifice flexibility:
Figure 2. A Typeform in Build mode
You can find the Typeform I built here. I didn’t add a payment field because Typeform doesn’t offer fake payments and I didn’t want to accidentally charge any of you. However, the Stripe integration is equally easy to configure, so I trust that you will be able to figure it out on your own. I also used the default theme, but you can redesign your own form as much as you want.
Now that we have a simple consumer-facing prototype, we’re going to need a way to manage the incoming data. Typeform features only basic survey management features, but we’ll need much more. For example, we’ll certainly want to assign particular surveys to our team members who will then handle the process manually. If the Typeform we created is a front-end interface, then we will have to build a back-end interface for customer management, too—something like… Trello.
Trello lets you work more collaboratively and get more done thanks to its beautifully simple Kanban lists. Monterail has been using Trello for project management for a few years now. Thanks to its intuitive interface and its integrations, which we will explore in the sections to come, Trello will do a perfect job as a simple “database” where we will be able to store important data fetched from Typeform.
We’re going to create a board called “Student Accommodation.” You can name your own board however you want, but the name is important to remember because we’ll be using it later. The board should have four columns:
Figure 3. Managing a customer in a Trello board
Whenever a new customer appears, we can add a new card to the first column on the board and then, as we make progress with that customer, we can move the card upstream.
I said “upstream” because, as Figure 3 shows, every Trello board is also a value stream map. Value stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer. Value stream mapping requires us to split any given process into discrete chunks—in our case, those are Trello columns—and observe the flow of value in the stream.
The flow will show us where the process is not optimal. If, for example, our student accommodation service is a huge success and we have too few team members to take care of the surveys, we will notice that too many cards stay in the queue for too long. We will then know that the queue is a crucial part of the process and should be automated as soon as possible in the future.
We still haven’t written a single line of code, yet we now have a consumer-facing app made in Typeform and a back-end survey management system built in Trello. Unfortunately, we still have no link between the two—our Trello board has no idea if we received a new Typeform survey or not. Right now, we would have to add cards with incoming questionnaires manually—a puny, boring task. Thankfully, I have another card up my sleeve. It’s called Zapier.
Zapier moves info between your web apps automatically. Thanks to Zapier, you can link your web apps with a few clicks, so they can share data.
Zapier flows are called “zaps.” Zaps have triggers and actions. A trigger is something like you getting a new email in Gmail—but it also may be any other event that Zapier can react to. The trigger event would then fire a corresponding action. For example, you might want to back your Gmail attachments up on Dropbox, so when the trigger detects an attachment, it would automatically upload it to Dropbox. The fun part? There’s still no coding required. Zapier seamlessly integrates with other apps so that you can go from an idea to a working workflow in minutes.
Figure 4. Another simple integration flow in Zapier
In a moment, we’re going to use Zapier to connect the Typeform we made earlier with our new Trello board.
Every time customers submit their questionnaires and pay for the service, we want Zapier to fetch the survey and create a new Trello card in the “Signed up” column.
Figure 5. Choosing a trigger app when building Zaps
You will also have to connect Zapier to your Typeform account. You’re going to need to get the Typeform API key from your account page. Zapier will guide you there. After you connect the two accounts, you can choose a form from Typeform for the zap to use. Choose whatever title you gave to your survey (see figure 6.)
Figure 6. Configuring Zapier to work with Typeform
The next step is to connect Typeform and Trello. When Zapier asks you to add an action to your zap, choose Trello as a source app. Then, from the list of available actions, select create a new card. Here’s where the configuration process gets the most tricky (see figure 7.)
Figure 7. Configuring Trello to work with Zapier
You’ll have to select a Trello board you want to post to—if you followed my instructions, it’s going to be “Student Accommodation.” Since we want the card to appear at the beginning of the board, we should choose the “Signed up” list in the second field. The third field called “Name” is where the only programmatic part of this tutorial happens. The drop-down list there will feature all available fields fetched from your Typeform—for example, you can decide to name each new card after an email fetched from an incoming survey. That’s what I chose because I wanted to email listings to my customers. You can experiment with other options, too. For example, you might want to copy the entire questionnaire and paste the answers as a description of the card so that you’ll be able to work with your customers entirely from Trello, without having to switch to Typeform.
Thanks to Zapier, we were able to connect our Typeform and its Stripe payment processing with a Trello board which is serving as a database. Now we can begin charging our first real customers—not users, but people who pay real money expecting to get real value out of their investment. Over the course of this tutorial, we tried to automate as much as we could given the scope of the article, but if you wanted, you’d probably be able to automate much more. For example, Zapier features integrations with MailChimp, which would let you send emails, or Dropbox—meaning that cloud storage with sharing options is also possible.
In 2015 alone, I coached four startup teams—who were winners of Apps4Warsaw—to challenge themselves and come up with product validation ideas that don’t require developing software. The simplest idea we came up with was merely a Twitter hashtag. The team wanted to create a social product. We reasoned that all social applications must first and foremost be trendy—and what’s a better and cheaper way to see if they would be able to bootstrap a new trend than to see if they were able to create a trending hashtag on an existing social network?
Does it mean that early-stage startups don’t have to develop real software? It doesn’t; of course, they do—at some point. My point was, you usually can start development much later than you initially think.
In 2016, I used the technique outlined in this article to create an MVP for my own startup—Ada. Ada is an AI-powered personal assistant who will help you rent your next apartment. If you say what you are looking for, Ada will text you the best listings on Facebook Messenger and schedule an apartment viewing for you. A Facebook Messenger chatbot is a very different product than a Zapier-powered Typeform, but the former couldn’t have evolved without the latter. Our crude MVP let us validate our riskiest assumptions before we spent money on development. As soon as we believed we had learned enough, we invested in a second iteration of the product based on our new-found knowledge. Whether you decide to build an in-house team or have a web development agency speed your development up—you can do the same.
