Startups rarely die due to technical risk. Most startups build the software or product they set out to build but die because either their product or messaging doesn’t connect with their customers.
The greatest risk lies in finding product-market fit and message-market fit.
Finding success in a startup is a function of finding the overlap between demand, competition (aka differentiation) and product.
You can be directionally right about the demand for your solution and fail because you are not differentiated enough.
You can also be right about demand and choose the right differentiation and fail to implement it in a way that makes sense to your customers.
It’s really, really important to test your assumptions as you go and not be overly confident in positive signals.
For example, you might validate that there is demand for your product by speaking with potential customers and verifying that the TAM (total addressable market) is large but build the wrong solution.
You might validate the value proposition by showing off a slide deck of the product you are planning to build, collect prepayment, and build it in a way that doesn’t make sense to the end-user, retain them, or provide enough value.
And then you can nail your product and fail to find message-market fit in a channel that scales.
The diagram below is how I think about this. The orange bands represent choices that will resonate with customers and the white bands are choices that will fail.
The problem is that being right about one or more previous steps is no guarantee that you’ll be right about the next one.
Building a product is expensive, time-consuming, difficult to change, and you have an almost certain chance of getting something wrong.
This is why you should hack together a minimum viable product using existing tools.
Hack Together Your Own MVP (Minimum Viable Product)
I’ve hacked together many solutions using off-the-shelf tools like Spreadsheets, Zapier, Sendgrid, form or survey software, and very little if any code.
Hacked together products can be:
- Fairly robust
- Easy to make (compared to coding it from scratch)
- Flexible and easy to adjust as needed
Frequently these hacked together solutions end up being more robust and feature-rich than anything our developers could make in less than 6-months to a year.
And you can build them in days or weeks rather than months.
But the best thing about these MVPs is you can quickly adjust them when one of your assumptions about how to implement a solution inevitably needs to be adjusted.
No matter what you do you will get things wrong so you need to iterate quickly.
Once you’ve validated your MVP and are ready to code it up you’ll know exactly what to build the first time. This dramatically de-risks building new products or features.
A Case Study
At Localfluence we have a platform that helps local businesses generate word-of-mouth marketing on social media.
Restaurants and other local businesses can create exclusive offers (like a buy-one-get-one-free or a free entrée) which locals can redeem in exchange for posting about their experience on social media or an online review.
The problem is our platform only works well for businesses that have products or services with very wide appeal… Like restaurants for example.
To get around this limitation I want to help businesses turn their existing customers into advocates. Existing customers are, after all, the people who are most qualified to post about their purchases and share positive experiences on social media.
This would require reversing our existing flow. Our existing flow works as follows:
- Bring a new customer to businesses
- The new customer receives a free or discounted item
- The new customer posts about their experience on social media or online review
With my new way we would:
- Target a businesses’ existing customer after a purchase
- The customer would post about the item they already purchased on social media
- The customer would be rewarded with a free or discounted item as a reward
This completely flips the funnel on its head and would allow us to help almost any business with existing customers.
The problem with making big changes like this is you have to make A LOT of assumptions. You can be right about 90% of your assumptions and still fail due to the other 10%.
So the most important thing is to test and iterate quickly.
Unless you have a very large dev team, coding up an app or a new set of features from scratch is the opposite of fast and does not iterate well.
So let me break down how I created an MVP by gluing spreadsheets, Zapier, and other off-the-shelf platforms together into a working product.
Validate Demand and the Value Prop
This all started as an idea in my head. But before I did anything else I had to find out if there were customers out there that want what I’m thinking of building.
So we did 3 things.
First, we decided on our target customer. We picked e-commerce stores.
Second, we validated that there is a significant total addressable market size and that we could charge enough for something like this.
We did this by looking at the pricing for other marketing platforms targeted at ecom businesses and examined the market cap and funding activity of those platforms.
Third, we actually talked to a few e-commerce stores to gauge their interest with a verbal explanation of the idea and got some financial commitments.
Map Out the Flow
Once you’ve validated demand and your value prop, you need to think of a few different ways your solution could work.
I made various mockups of how we could target an e-com store’s existing customers in XD. Some of these mockups included:
- Before purchasing with a checkbox
- After purchasing on the confirmation page
- After purchasing in an email
- After purchasing in a text message
- When their order arrives in the mail via an email
- When their order arrives in the mail via a text message
Ultimately, I chose to send an email when their order arrives because I feel it is the easiest method from a UX and development standpoint.
If I can’t get enough engagement by email I might try SMS next but I’m happy to avoid the cumbersome FCC laws around SMS marketing for now.
This is the flow I decided on:
- The customer places an order on a Shopify e-com store
- The order arrives in the mail
- They get an email inviting them to receive a free gift in exchange for posting about their new product
- The customer posts a photo of themself with their product on social media
- The customer takes a screenshot of their post and uploads it to us
- We send an email to the customer with a unique promo code that can be redeemed to get their gift
Now I’m going to show you how I hacked together a completely viable and testable product using simple tools in just a few days.
Below is the Zapier workflow that starts when a Shopify order is shipped and ends with sending an email to the customer.
1 Shopify Trigger
We’re going to start with Shopify customers. I am still investigating to see if I can figure out a way to trigger when an order is actually delivered to the customer.
If not the trigger will be when the order is shipped and I will add a delay equal to the average shipping time.
If I do the shipped trigger, I’ll figure out the average time it takes for an order to arrive and use Zapier’s Delay action. This will depend on the store but for this example I’m using 3 days.
3 Send Email
Next, I send an email through Sendgrid that is aimed to land in the customer’s inbox at the time they receive their order in the mail.
The email contains a link that takes the user to a landing page to explain the offer further.
The most important thing to take note of is how I’m sending the customer’s email as a parameter in the link. Parameters are just ways to tack on information onto the end of a URL. In this case, our parameter is
firstname.lastname@example.org is replaced with the actual customer email from the Shopify order.
Social Post Workflow
If a customer is interested in the offer within the email they will click the link which takes them to a landing page I built in WordPress.
1 Landing Page
As I mentioned earlier, the link leading to the landing page includes the customer’s email address as a parameter. The landing page explains what is expected from the customer and includes a call to action which takes the customer to a form made with Typeform.
In order to know who fills out the form, we need to make sure the link to the form also contains the customer’s email as a parameter.
I wasn’t happy with the flexibility I had in Typeform and decided to go this route to have more control over the design. This is a crucial step from a conversion standpoint and I’m a bit of a design and conversion snob.
After clicking the call to action on the landing page, you end up on a form I built with Typeform. This form walks the customer through how to create their social media post.
The last step on the form is to upload a screenshot of their post.
Once the form is submitted it launches a Zapier workflow with Typeform as the trigger.
3 Trello Card
Finally, a Trello card is created that includes the customer email and the image of their social post.
Since this is a proof of concept, I need to make sure there are manual touchpoints to see if things are working as they should.
If customers are uploading bogus photos or are confused and uploading the wrong thing I can choose to not approve the post and address the issue in the next iteration of the workflow.
Promo Code Workflow
The last workflow kicks off when the Trello card that represents the customer submission is moved to the “Approved Posts” list.
1 Trello Card
Below is the Zapier trigger I used:
2 Google Sheets
E-commerce stores don’t want to give promo codes for big discounts or free items that can be shared. So I had to build a 1-time-use code management system.
To do this I created a Google spreadsheet with 2 workbooks. The first contains a thousand unique 1-time codes. The second workbook is where codes go after they are sent to the customer so they don’t get used again.
This step actually required 3 separate Google sheets actions in Zapier.
- One to grab a row from the bottom of the “New Codes” workbook.
- Another to delete that bottom row.
- Another to append the unique code to the “Used Codes” workbook as a new row.
3 Sendgrid Email
Finally, we send the promo code in an email to the customer.
And that’s it! We now have everything we need to be able to test this proof of concept out with real customers.
You can build some amazing MVP products in just days or weeks. Products that would take a whole team of developers months to build.
Now, what I built isn’t going to scale very well. But it’s incredibly fast to build, test, and change. And there will be changes.
I expect something to go wrong. Maybe emails won’t work. Maybe we’ll need to do texts. Whatever it is, I will be able to make those changes very quickly.
Now it’s your turn! I’d love to know what you are thinking about building. Hit me up on Twitter @mikewille_ and I’d love to hear about it.