Almost all SaaS businesses start life as a *great idea*: a kick-ass concept destined to revolutionise the way the world functions.
Trouble is, I've seen a ton of passionate founders invest their time and energy into realising their vision, building and refining a polished, perfect product; only to find out that it solves a problem nobody cares about.
So, what went wrong?
What is a Minimum Viable SaaS Product?
Simple. Almost all of those great ideas are built on a ton of pretty fundamental assumptions:
- You assume your SaaS product solves a problem, and solves it in an effective way.
- You assume the problem is important enough for people to pay for a solution.
- You assume you solve that problem more effectively than your competitors.
...and actually, as a startup founder, you first job isn't to build the world's greatest product, or scale your business as fast as possible.
Your job is to prove/disprove your fundamental assumptions in the least expensive way possible.
That's where the Minimum Viable Product comes in.
The Minimum Viable Product (MVP)
A Minimum Viable Product is [a] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Eric Ries
Imagine trying to hit a bullseye in a pitch black room. For starters, you don't know where the target is. Hell, there might not be a target.
So, before we can hit that bullseye, we'd need to conduct a few tests.
We'd need to:
- Turn the lights on, and check that the target exists.
- Try out a few different tools, and determine which was most accurate: a bow and arrow, a shotgun, or a sniper rifle.
- Practice hitting the target, as chances are, our first few shots are going to miss.
Building, launching and scaling a new product is like trying to hit that bullseye: you can either build a finished product, straight from Day One, and hope that it hits the mark; or you can build your product in small, incremental steps, and test your assumptions at each stage.
That process is called validated learning. Instead of building a product to secure customers and generate revenue, you're building a product designed to maximise learning.
Instead of building a ton of features and functionality, and hoping they align with customer needs, you're building a single feature, testing it, and using that feedback to determine your next steps.
Examples of Minimum Viable Products
1) DROPBOX
Sometimes, you can test fundamental assumptions without even building a product. Before DropBox became a $10 billion global behemoth, it existed as a 3-minute video stuffed with geeky in-jokes and amateur narration.
Founder Drew Houston realised that the level of time and energy required to create a functioning DropBox prototype was incredibly high: necessitating all-manner of complex integrations with existing tools.
So, instead of investing a ton of resources into creating a functional version of the software for users to try, Drew created a simple video, explaining how the software was intended to work.
Despite the simplicity of the video, it caused an explosion of interest: proving that the DropBox concept, once properly implemented, would solve a hugely painful problem.
[The video] drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away.
Drew Houston
2) ZAPPOS
Back in the days before eCommerce was an established concept, Nick Swinmurn had a radical idea: that people would be happy to buy shoes online, without ever trying them on.
To test that idea, Nick went to local shoe stores, photographed their stock and advertised them online. If the shoe sold, he'd return to the store, buy the shoes and ship them on. Fast forward a few years and eCommerce is a multi-billion dollar industry; and Nick's business, Zappos, was bought by Amazon for $1.2 billion.
This approach is sometimes known as 'Flintstoning': although it looks like your product and service is polished and fully-functional, you're actually pedaling like hell beneath the surface.
3) ANGELLIST
Instead of building out a complex website, and spending a fortune to market themselves to both investors and founders, AngelList kept it simple: relying on their existing network of contacts, and plain old email, to arrange their first few investment opportunities.
Once they achieved success at this small scale, it became much easier to justify the time and resources required to scale-up the service - safe in the knowledge that their fundamental assumption had been proved right.
The 4 Types of Minimum Viable SaaS Products
Building a SaaS solution is risky. Creating a perfect, polished product can take hundreds (sometimes thousands) of hours of development time - and there's no guarantee that people will even use it, let alone pay for it.
So today, I'm looking at 4 ways you can build a Minimum Viable Product (MVP), to minimise development time and maximise your chances of building something people actually need.
...the riskiest aspect of new products is not technology (whether it can be built) but market (will people use it and pay for it).
Ramli John
1) Landing Page MVP
When you're gearing up to sell your finished product, you'll need to create a landing page or two - so why not build that landing page before you have a finished product?
- Develop your landing page, and wax lyrical about the benefits of your soon-to-be product.
- Set up an AdWords campaign to drive traffic to it. This is something author Tim Ferris does to test potential new book topics: creating ads for each topic and monitoring audience responses.
- Measure conversion rates. Ask people to sign-up for more information, or even let them 'buy' your product - only to be greeted by an out-of-stock or 'available soon' message. Morally questionable, perhaps, but an effective way to gauge the desirability of your product.
Crucially, a simple email sign-up form isn't a Minimum Viable Product: capturing email addresses isn't a form of validated learning.
As Buffer's Joel Gascoigne explains, to make your landing page a true MVP, you need to use it to capture as much product feedback as possible:
Ask them to click a sign up button at least before giving you their email.... Ask them to click a “pricing plans” button, choose a plan and then give their email and you’re actually getting some validated learning.
Follow it up with a conversation and you might learn why they gave you their email and whether they truly have the problem you’re solving for.
Joel Gascoigne, Buffer
2) Explainer Video MVP
Once upon a time, cloud storage giant Dropbox was little more than a glorified YouTube video:
Over the course of the 3-minute explainer video, founder Drew Houston talks through the basic principles of the Dropbox solution - complete with geeky in-jokes designed to appeal to his target audience of early adopters. This alone was enough to generate a huge surge in interest, and validate the Dropbox concept.
In the Dropbox example, Drew had coded up a basic prototype, but there's no reason you'd even have to go that far. As long as your explainer video accurately demonstrates what you intend your product to do, you can still learn a ton about the perceived value of your idea.
3) Flintstone MVP
If you saw the Flintstone family drive past in their 'car', you might assume it was powered by an engine. But beneath the surface, they're actually using old fashioned manpower.
That's the basic principle behind the Flintstone MVP (also known as the Wizard of Oz MVP): creating the illusion of a fully functional product, but behind the scenes, relying on manpower alone (and services like Amazon's Mechanical Turk) to deliver the finished solution.
This low-cost approach means you can test the market response to your product without having to actually build it. Only once you've seen a positive response do you invest development time into actually creating it - an approach leveraged to great effect by ecommerce giants Zappos.
4) Concierge MVP
The Concierge MVP represents the ultimate in inefficient, non-scalable development: instead of building a product, you emulate a product by delivering a completely manual, hands-on service.
Meal planning service Food on the Table (acquired in 2014) started out as a concierge MVP, with the company's founders offering a VIP service to a single customer: hand-picking recipes to suit her needs, identifying the ingredients required, and sourcing the best in-store promotions for her to use.
At the end of the week, they'd receive a cheque for $10: but more importantly, they'd learn a huge amount about the parts of their service people loved, and the parts they didn't. That insight allowed them to start developing a product they knew people would actually use.
How to Build a Minimum Viable SaaS Product
Discover the six stages of building a Minimum Viable Product, and ensure that every hour of development time, and every dollar of your budget, goes into building a product people actually need.
1) Define the Problem You're Trying to Solve
It's easy to get caught-up in ideas of a particular product, and forget about the problem it's intended to solve.
But if you want to build a successful SaaS business, you can't build the product you want to build: you have to build the product people need.
Get attached to the problem, and not a particular solution: because chances are, the product you'd originally envisaged isn't actually the best way to solve that problem.
2) Find the Simplest Way to Solve the Problem
With 'the problem' front of mind, it's time to start planning the solution. As a developer, you might find yourself mapping out elaborate functionality and cool new features, because it's what you're good at, and what you enjoy.
Trouble is, it takes time and money to build-out all of that functionality. Even if you could muster the resources to develop your perfect product, there's still the huge risk that nobody would use it: it might solve a problem that no-one cares about.
So instead of committing a ton of resources to product development, we're going to cut our features list back to the bare bones. We're going to launch the smallest, simplest version of the product we can: containing just enough functionality to test our 3 fundamental assumptions:
-
Does the problem exist?
-
Is the problem important enough?
-
Can we solve the problem?
3) Prioritise Your Features
In order to build the smallest functioning version of our product, we need to identify the core features that we can't do without, and the 'nice to have' features we need to save for later iterations.
Thankfully, there are dozens of different frameworks for prioritising your feature list, including the MoSCoW method: a way of splitting your features list into Must Haves, Should Haves, Could Haves and Won't Haves:
Must Have
These are the bare bones features that are inextricably linked to the functionality of your product. The features that end up here constitute the backbone of your Minimum Viable Product.
Should Have
These are features that a finished product needs to have, but aren't essential for this early-stage iteration. For example, you know your product will eventually need an automated password recovery system, but for your MVP, you can use a manual email support system instead.
Could Have
This is where all of your desirable, added-extra functionality goes: ready to be built-out only once you've tested the core functionality of your product.
Won't Have
Sometimes, it can be valuable to define the high resource, low reward features your product shouldn't have.
4) Forget About Efficiency
In order to grow, your finished SaaS product needs to be efficient and scalable.
But this isn't your finished product, and at this stage, you can afford to develop your MVP in an inefficient and un-scalable way. Efficient processes can be developed later. For now, you're just testing your fundamental assumptions.
Returning to our earlier examples, AngelList and Zappos are two great case studies in inefficient MVPs developing into scalable, profitable businesses:
ANGELLIST
For AngelList's MVP, they needed to find a way to connect angel investors with startup founders.
Traditional product development would necessitate a website, a sign-up system, some kind of in-built messaging functionality - but AngelList's MVP achieved the same end goal using plain old email exchanges. Though this approach couldn't scale, it was enough to prove out the demand for their solution.
ZAPPOS
Instead of buying a warehouse's worth of stock, Zappos went the ultimate low-tech route: advertising products they didn't own, and purchasing stock only when they'd already managed to sell it.
5) Build, Measure, Learn
An MVP isn't an end-goal: it's a stepping stone. You aren't trying to generate a fortune in revenue (yet), and you aren't trying to scale your business as quickly as possible. Instead, you're trying to maximise learning.
With your MVP's features mapped out, you can start developing. But crucially, this development isn't the end of the road. It's the start of a feedback loop, designed to help you to continually improve your product in 3 stages:
Build, Measure and Learn.
STEP 1) DEVELOP A USER BASE
The more users you can sign-up to your MVP, the more data you'll have to analyse. Running an open beta, and using services like BetaList, will allow you to attract the right types of users to your fledgling product: the early adopters and technology enthusiasts that enjoy using prototype products and providing feedback.
STEP 2) COLLECT USAGE DATA
The V in MVP stands for Viable: that is, people need to be willing and able to actually use your SaaS product. Services like Mixpanel and Intercom offer a cost-effective way to collect usage data, and start tracking all-important metrics like customer churn.
If you're developing a B2B SaaS application, 'viability' extends beyond a single user experience. During the 'measurement' phase, it's important to see how your MVP is being used in the context of a wider organisation, and whether it provides value (for example time saved, profits increased, better communication, etc.) to the potential buyers of your product - as well as the individual users.
STEP 3) ASK FOR USER FEEDBACK
Make it easy for users to contact you, and you're likely to get a ton of insights into missing functionality, bugs and unneeded features.
With that said, users are always more likely to contact you when they're having a problem with your product - so to work out what's working well, it's important to be proactive, and reach out to your users using services like Qualaroo and SurveyMonkey.
STEP 4) UPDATE YOUR SaaS PRODUCT
Armed with usage information and customer insights, you'll be able to work out which aspects of your MVP are a resounding success, and which need some further improvement.
These changes can be built into the next version of your product, and once your product is updated, you can measure, learn and build, all over again. With each iteration, you'll draw closer to a full finished product - and crucially, a fully-finished product that people actually need.
6) Pivot or Persevere
Sometimes, user feedback will reaffirm your beliefs, and indicate that you're heading down the right path. Sometimes, it'll tell you you've misfired, and you're heading in the wrong direction.
These insights are painful, but they're crucial to building a product that people need. After all, we aren't building software for the sake of software: we want to create a product that people will fall over themselves to use. Without testing, we don't know what that product looks like.
So, if you launch a Minimum Viable Product and realise you've taken a wrong turn, don't worry. You've just failed yourself a little bit closer to success.
10 Strategies for Pivoting Your Failing SaaS Product
We're all going to experience failure at some point. All that matters is how we choose to respond to it.
Today, we're taking the advice of The Lean Startup, and looking at 10 ways to turn a growth dead-end into a successful SaaS pivot.
Pivot or Persevere Decisions
All SaaS businesses start with a *great idea* - but even the best ideas rely on unproven assumptions.
As product development progresses, and we start to earn feedback from real users, we begin to realise that some of those assumptions are wrong.
All of a sudden, we begin to see the first warning signs of 'failure':
- Growth begins to slow, and churn begins to climb.
- Features we expected to excel die a slow death, and others surprise us with their popularity.
- We market ourselves to one customer segment, only to find growing interest in another.
- The business we set out to create evolves into something else altogether.
At this pivotal juncture, we have two choices:
- We can stick to our guns, remain resolute in the face of adversity, and hope that the dip in performance isn't symptomatic of a downward trend.
- We can assume that one of our fundamental assumptions is wrong, and use it as an opportunity to learn about, change and improve our business.
In other words, we can pivot or persevere.
A pivot is a special type of change designed to test a new fundamental hypothesis about the product, business model, and engine of growth.
Eric Ries
The Road to Hell is Paved with Perseverance
Perseverance plays a crucial role in success. After all, we'd never achieve anything if we balked at the first tentative signs of struggle.
But there's a difference between riding out a rough patch and blindly ignoring evidence.
Most of the SaaS sector's fairytale success stories are characterised not by stubborn perseverance, but by smart, responsive pivoting.
Instead of blindly carrying on with something that didn't fit the real world, companies like Slack, Eloqua and PayPal took a chance to test new ideas, and ultimately, reshape their businesses into something more desirable, and more profitable.
With that in mind, we're looking at the 10 types of SaaS pivots - each representing a different way for you to take stock of your current growth strategy; doubling down on the parts that are working, and scrapping the parts that aren't.
1) Zoom-In Pivot
If your SaaS product offers a ton of functionality, there's a chance that a single feature will have a particular resonance with your target audience - even if it isn't the one you expected.
In these cases, it's possible to ditch the extraneous functionality, and turn the popular feature into a stand-alone product.
Both Slack and Flickr have unlikely origins, starting life as wildly unsuccessful online games.
When the games' internal photo-sharing and chatting features proved to be popular, founder Stewart Butterfield ditched the extra features and turned them into standalone products.
2) Zoom-Out Pivot
In other cases, the opposite needs to happen. Customers cry out for extra functionality, and a range of complementary features are developed to support the original feature.
3) Customer Segment Pivot
Sometimes, you'll succeed in solving the problem you set out to solve, but you'll do so for an unexpected group of customers.
In this situation, you need to be able to switch gears, and start focusing on the people that want your product - not the people you want to want your product.
Groupon's 'tipping point' system (where projects only activate when a minimum level of support is reached) was originally deployed in a fundraising capacity, as The Point.
Groupon was rolled-out as a side project, and targeted at a completely different customer segment - quickly eclipsing its parent venture in the process.
4) Customer Need Pivot
Conversely, sometimes you'll be hit by the realisation that the problem you're trying to solve simply isn't a problem.
However, armed with the insight you've gained from targeting a specific segment, you may be able to pivot to solve a more urgent and pressing problem.
Marketing automation giants Eloqua started life as a business-focused messaging app.
Realising that chatting wasn't a major priority for their target audience, they shifted their focus towards lead generation - reinventing the product as a tool for following-up with leads.
5) Platform Pivot
Sometimes SaaS businesses will develop their own platform to sell or support a product.
In some cases, it's the platform itself that proves interesting to their customers, and the decision has to be made to focus on the platform, and not the app - making the pivot from SaaS to PaaS in the process.
6) Business Architecture Pivot
Occasionally, a SaaS business may need to completely change the architecture of their business.
As the true nature of their customers' sales process begins to emerge, it becomes necessary to switch from a low margin, high volume model (typically B2C), to a high margin, low volume model (more commonly found in B2B), or vice versa.
7) Value Capture Pivot
'Value capture' refers to your strategy for generating revenue from your product.
As your SaaS product develops, and your growth goals change, different methods of value capture may become more beneficial than others - necessitating a shift to either a free (read: ad-supported), freemium or premium model.
Video marketing company Wistia made the pivot from premium to freemium, adding in a free tier package to encourage greater adoption of their services.
8) Engine of Growth Pivot
There are three main engines of growth: viral, sticky and paid.
Though it's important to determine a single engine of growth for your SaaS product, the most relevant engine may change as your business evolves.
- Viral refers to growth achieved through user referrals (something measured by a viral coefficient).
- Sticky refers to growth achieved through customer retention (with very low churn rates amplifying customer growth - if nobody leaves, every additional customer has a compounding impact).
- Paid refers to the growth achieved through the combination high customer lifetime values (LTV) and low customer acquisition costs (CAC) - making it possible to profitably generate growth through paid channels.
9) Channel Pivot
The 'channel' here refers to the method you take to deliver your SaaS product to your customers.
If you decide to take a different route to market, abandoning a complex sales process in favour of selling 'direct', you're undergoing a channel pivot. The same principle applies if you decide to sell via a third party, or a particular marketplace.
10) Technology Pivot
Sometimes it becomes possible to deliver the same solution with a different technology.
This type of pivot is typically a sustaining innovation - with established businesses finding new ways to solve the same fundamental problem.
In its original incarnation, PayPal was designed to facilitate payments through Personal Digital Assistants (or PDAs), like the Palm Pilot.
A few years on, with growing adoption of the web, PayPal pivoted to offer the same safe and secure payments through the internet.