It’s no secret that nine out of ten startups fail, mostly because of the lack of interest and problems with the product-market fit. But validating your hypothesis from the beginning can dramatically improve your odds for success. How? With the Lean startup approach.
Lean startups are not a novelty. They’re often the reason why small businesses take the lead over bureaucratic and not that open-minded corporations. The flexibility of Lean allows companies to quickly develop an MVP and focus on post-release adjustments based on customer feedback.
Being experts in Lean, we’d like to tell you all about this approach in product development. Since the topic is quite broad, we’ll cover it in two articles.
In this article, we’ll talk about the Lean approach and the minimum viable product (MVP) — one of the key principles of the Lean method. You’ll learn how to develop an effective MVP that meets your customers’ needs and has no redundant functionality. We’ll show you the main tips on effective MVP development through the lens of a project we did for an American startup SmartLane. In the next article, we’ll discuss the post-MVP phase and the common mistakes businesses make.
So let’s get down to it!
Lean startups: getting to the market faster
Dropbox, Slack, or General Electric's project FastWorks are just some successful startups that used the Lean approach. And for a good reason. The method is based on three main principles:
- Summarizing ideas by creating a business model canvas
- Testing ideas by using the “get out the building” approach (aka, customer development)
- Creating MVP to collect customer feedback (Agile development)
The Lean approach emphasizes experimentation, agility, and speed: it embraces the MVP creation instead of yearlong development. Startups can analyze the user experience and improve the product based on the real market needs instead of guessing the customer's expectations.
Simply put, a Minimal Viable Product is the first working version of a product with just enough features to be released and ensure customer feedback. For businesses, building an MVP is beneficial since it:
- Accelerates time to market
- Allows companies to test product ideas and avoid bigger failures
- Requires minimum effort and resources for development
- Reveals real-life market needs and tendencies
- Prevents from wasting fund expenses and engineers' hours
- Attracts early investors or helps with crowdfunding
Many big companies have become successful by starting their journey with an MVP release. For instance, Virgin Airlines began with just one plane flying between Gatwick and Newark, while Yahoo’s first website had one page with a list of links to other sites.
To show you how MVP development works, let’s take a look at a real-life case of Providence Health & Services described by Adrian Slywotzky in his recent book. Providence Health & Services is a health care network operating hospitals across eight U.S. states. They built and released software in 45 days instead of nine months as had been expected.
At first, a team of developers created a prototype and released it in just two weeks. Naturally, they received negative feedback, to say the least.
However, customers’ comments allowed developers to create an improved version of the product, which took them two more weeks. This time the feedback was better: instead of fierce criticism, customers advised on what functions the product still lacked. When the third, final, iteration was completed, the product worked like a charm, and customers loved it.
This example shows how Providence Health & Services managed not only to develop a full-fledged product at breakneck speed (1.5 months!), but also tailored it to the specific customers’ needs.
For our client, building an in-house competence center for MVP development wasn’t a financially justified option. So they decided to outsource MVP development. Knowing about the quality of offshore outsourcing in Ukraine, they came to us with high expectations and ambitious demands. The main challenge was that SmartLane had only four months to launch their MVP — an online mobile app and an engine for the car auction software. So we discussed their idea and immediately set to work.
Before building an MVP: preparation steps
Before jumping aboard the MVP train, make sure you have a clear vision of your future viable product, its goals and functionality. Let’s talk about this in more detail.
Understanding the concept
We’ve seen many companies that don’t understand the concept of an MVP right. Here are four principles to bear in mind before you start the development process:
- An MVP makes sense when a company has hypotheses that need to be tested.
- An MVP should carry enough value to attract first users.
- An MVP is not a set of some random basic features. It should have the functionality that would allow a company to verify its hypothesis.
- An MVP is less about the product and more about the process of developing the product that will fully meet market needs.
MVPs start with a business idea addressing the existing market needs and the pain points of potential users. Without an idea at its core, your MVP will flop.
Setting business goals and hypothesis
The first thing to do is to set and analyze the hypothesis of the market's need. The hypothesis statement often consists of four main components:
- Customer segmentation: understanding your customers, their activities and pain points; defining personas
- Problem: prioritizing pain points, focusing on the specific problem the product will address
- Solution: deciding on a list of potential solutions and, as a result, choosing a set of features for the future product
- Success metrics: mapping out the user engagement funnel and picking the right metric for evaluating customer satisfaction
At Implex, we partner with a research agency to ensure an appropriate level of hypothesis analysis and help our clients with their business decisions. But since SmartLane is an expert on car auctions, they came to us with a ready hypothesis and a list of functions the future product should have.
Creating project documentation
Regardless of how genius your developers are, they don’t know the project as perfectly as you do. Effective communication can bridge this gap. But without a rock-solid foundation, many details are often lost on the way. So writing project documentation is the next thing to focus on. You can start preparing it in advance or while building the team. Here’s what you’ll need:
- A high-level product specification with epics and user stories
- A detailed description of the first one or two sprints with a complete sprint design
At Implex, we prefer the story mapping technique for describing the future product and its requirements. When making the map, we arrange user activities along the horizontal axis according to their priority or system requirements. Down the vertical axis, we place product features in the order of descending priority.
Story mapping is equally effective and insightful for both: software development teams and product owners. On a single sheet of paper or a board, developers can see product goals and features arranged in a strict order. Product owners, on the other hand, can see the efforts and costs necessary for every additional feature. They can also change priorities or discard non-important features from the MVP.
In one of our projects, using the story mapping technique allowed us to cut an MVP scope three times, compared to the initial plan. At Implex, we love using Miro for story mapping, but you can choose what works best for you. If you’d like to get more detailed instructions on this technique, check out this post.
Choosing the right tech stack
You should also select your tech stack and define architecture beforehand. To do this right, we recommend inviting specialists experienced in different industries and well-versed in many technologies. In the SmartLane case, we set everything down one month before the development stage.
The tech stack for SmartLane comprised:
- .NET Core due to high requirements for the system's performance and complex logic model of the auction
- MongoDB due to the new Mongo.Watch() method for quick bid synchronization across multiple servers
- Swift for flawless performance and simultaneous status change across hundreds of UI components displayed on the screen at once
When developing an MVP, working fast to collect the first feedback makes a lot of sense: it saves you from budget loss and failures in case your product doesn’t fit the market. To arrange the process quickly, you need to start building a team of developers long before the development starts.
In the second part of this article, we’ll share with you our top tips for building a software development team and arranging the working process, including information exchange, sprints and requirements planning. And if by the time we finish you’ll feel lost in the nitty-gritty of the MVP development, don’t fret, we’ll give you key principles to follow so that your MVP can succeed.
Meanwhile, if you need advice or help with MVP planning, write to us! You can also contact us on LinkedIn or by email at email@example.com.