Every startup founder has the same worry: You fear your product won’t take off before you run out of money. You know exactly how long your runway will last before funding runs out. If you’re bootstrapping, you have a bit of leeway, but your time is still limited.
Your goal is to find the right product/market fit. That’s the point where you’ve identified the right market (your ideal customer) and have created a product that satisfies it. It’s also the point where a SaaS starts making real money. Iterative development is the quickest and surest way to get to product/market fit.
(Another great reason to use iteration is because it insures the success of the product. 75% to 90% of all startups fail when launched without an iterative development model.)
The most popular and most effective iterative model is called the lean methodology.
What Is the Lean Startup methodology?
Lean methodology is a scientific product development philosophy of building and managing startups. It replaces the traditional waterfall product development method. It was originally coined by Eric Ries in his book, The Lean Startup. The method was pioneered in manufacturing, but it’s largely applied to software businesses.
The Lean Startup focuses on an iterative loop of feedback and learning. It involves an initial phase of market research and customer profiling, and then the creation of an early version of the product (more on this in a moment). Over time, a powerful cache of information is gained about the customer, which is used to fuel further product development.
The goal of the Lean Startup is to create and distribute a product people want, not the product you think they want. By following this methodology, you can hedge your risk of failing by repeatedly testing your product with actual customers. This methodology is an effective way to achieve product/market fit quickly and delight your customers.
The lean methodology is especially applicable to cloud-based SaaS startups because the product developments can be distributed to current users. Whether you’re just fixing bugs or adding new features, your current user base can enjoy the newest iteration.
Your MVP and validated learning
Validated learning is the process of repeated testing of every iteration of your product. You’ll measure its success after each deployment. It all starts with a minimum viable product (MVP), a basic form of your product with only enough features to begin collecting validated information from your customers. Your MVP should use as few resources as possible.
“Once entrepreneurs embrace validated learning, the development process can shrink substantially,” says Eric Ries. “When you focus on figuring the right thing to build—the thing customers want and will pay for—you need not spend months waiting for a product beta launch to change the company’s direction.”
Let’s use an example: You’re creating a social media scheduling tool. You dream of a product with a number of features, like social post analytics, hashtag monitoring, integrations with other services, and the ability to white label the product for your customers’ clients.
Your MVP, however, wouldn’t bother with all of that. In this case, the MVP platform would likely include only the most basic features: integrations with the user’s social media accounts and the ability to post on their behalf.
You shouldn’t spend resources developing your other features until you’ve learned more from the customer so you can make sure those features are something they actually want. For instance, you might learn from your typical customers that they would never use the white labeling feature because they don’t want to deal with reselling. It’s practical to learn this before you built it.
This image depicts proper lean development. The first step would be the MVP.
Image source: deming.org
That isn’t to say that an MVP is a product with the fewest features. Your MVP should be the minimal product that provides you with the most learning. In some cases, an MVP could be as simple as a PowerPoint presentation, wireframe mockup, or sample data set – whatever it takes to get feedback from your (potential) customer.
Think of your MVP like a prototype. It’s basic, but unpolished. It’s just good enough to get your customers to use it. Depending on your typical customer, your product and your industry, you may be able to get customers to pay to use your MVP, if it provides enough value.
The build-measure-learn loop
The best products are made when its creators have a keen understanding of their customer. The Lean Startup teaches an iteration loop that helps you refine your product over time by maximizing your ability to learn.
You could learn about anything: features, your customers’ needs, the industry, pricing, distribution, etc. Your learning could even cause a fundamental shift in your product or the manner you do business. You could pivot your product to a new customer, a new industry, or transform your product into something entirely unexpected. By building your product through iteration, you maintain the freedom to create a useful product, whatever that means.
You don’t need a lean approach to achieve a product/market fit, but lean development will get you there quicker. That’s because this process is fast, agile and efficient.
The lean process is generalized as a feedback loop with three components: build, measure and learn.
Image source: steveblank.com
Essentially, the loop is the scientific method. Anything you build should be based on hard information from previous learning, not random guessing. This image adds some clarification to the three components.
Image source: steveblank.com
Naturally, this is where you build your product (or a piece of it). Use your previous learning (remember, this is a loop, so the end feeds the beginning) to create ideas, or hypotheses. In terms of SaaS businesses, “building” usually means writing code or creating system architecture.
What you decide to build should be something you can measure in some way. You should have a measurement plan in place before you deploy whatever you’ve built. You should know exactly which metrics will validate or invalidate your hypothesis.
This is where you measure and collect data on your experiment (the build). The beauty of this methodology is that you’ll be working with real information from users and customers. This is called customer-drive development. Your product shouldn’t be subject to the whims of whatever your marketing director or CEO “thinks” will sell.
In your early days, you won’t have a lot of usage data to scrutinize. You’ll probably be limited to direct customer feedback, but that’s perfectly valuable. More information equals more learning.
Once you have your data, start to glean insights. What do your customers prefer? What made the product better? What brought you closer to what the market wants? Turn your conclusions into ideas to restart the cycle and build again.
It’s quite possible that your learning will invalidate your initial idea. Going back to our example from before, let’s suppose you built a version of your social media posters’ white labeling feature – maybe something simple, like the ability for users to attach other users to their account. After six months of tepid usage (measure), you might determine (learn) that your customer doesn’t want to give other people access. In this case, you wouldn’t build out the white labeling feature because your initial hypothesis (that customers want it) would be invalidated.
The hypotheses you measure can span the entirety of the SaaS experience. You can test features, pricing, distribution channels, customer acquisition, customer segments, revenue streams, onboarding, retention, deployment, the user interface, and even the thing that makes you unique: your value proposition. Like in our example, you can even ship MVP versions of individual features or messaging.
If you continue this cycle perpetually, you’ll cause incremental changes in your product that are driven by your customers. You will arrive at a product/market fit without incurring the tremendous delays and costs (in terms of development and marketing) that products built via the waterfall methodology incur.
Does the Lean Startup loop ever end?
They say an organization is no longer a startup once it finds a product/market fit. At that point, it’s a genuine business with a repeatable and scalable model.
Nevertheless, iterative development never ends for SaaS businesses. You should always be improving your product based on your customer usage and feedback. In fact, some of the fastest growing SaaS businesses in the world spend up to 42% of their revenue on ongoing development.
So keep iterating! If you need a tool to capture better customer data (that’s actually useful), try Ask Inline for free.