Hi, it’s Eugene. I’m a system analyst at Purrweb, which is a studio that designs and develops MVPs for startups. In this article, we’ll discuss the mistakes that prevent a startup from winning users’ hearts and continue to grow after the release.
Mistake 1. Ignoring the needs of the target audience before launching the project
Sometimes, clients come to Purrweb with product ideas we call “put it all on black”. The startup owner is so confident in their hypothesis that they don’t even want to check the needs and pains of the target audience. Such a project may take off, but in most cases, it’s harder to evolve and make it profitable. Users just don’t need it or find it inconvenient.
To avoid this, I recommend you study your audience before launching the project. This research will give you a clear idea about the needs of future users and, maybe, some surprising insights. Agencies analyze startup business ideas and the target audience for about $3,000. On average, custom development costs $70,000, and it’s easy to calculate the loss a startup may face if their product doesn’t meet the audience’s needs.
A product that tries to please all the audiences at once is like a one-man band playing: it’s hard to enjoy the sound of a single instrument. At the same time, a product for a certain target audience is like a professional conductor, creating a perfectly harmonious sound
Here are the research types that any startup will benefit from:
1. Quantitative research: a survey. At this stage, the task is to get statistical data. For example, we need to make a housing rent service. With the survey, we will find out how long it usually takes for an owner to rent out their place or for a tenant to find one. You should leave fields for answering open-ended questions. Here, a respondent will be able to write what they think, and you will get valuable insights.
I advise you to use an online calculator to determine the number of respondents for your research. It takes into consideration several indicators that matter for calculating the final sample group:
-
- Consumer confidence index represents how confident you will be in the research results. I recommend you choose the standard 95% confidence index to reduce the probability of failure to 5%. This makes an optimal ratio when you need a balance between the budget, the research due dates, and result precision.
With a lower confidence level, like 90% — the results become less reliable, but we can question fewer people. This option is suitable for products in a fast-evolving market or for the B2B segment, as it’s hard to find many respondents there.
-
- Margin of error shows how far the results you get are from the truth. For example, we have questioned 100 tenants, and 20% of them have been looking for an apartment for over half a year. With the +/- 10% margin of error, it’s possible that the actual number of such tenants can range between 10% and 30% of the population. When we lower the margin of error, the interval becomes narrower and the result — more precise.
-
- Population size represents the number of the target audience representatives in a country. You don’t have to specify the exact number here. For example, we, again, question tenants. It’s clear that our target audience is not limited to dozens or hundreds of people — we’re talking millions here. In this case, 10 million people may be enough to calculate the sample group. If you are making a product for a smaller audience, use the available Wordstat or Google Trends statistics as a reference.
2. Qualitative research: customer development. It is a series of meetings with potential users. In the case of the housing rental service, it helps determine the problems of the owners and tenants, what the schedule of meetings with candidates looks like, what the most irritating thing is, and if it is convenient to use the products that are already on the market.
We questioned about 20 people if the product niche was clear and well-studied. If a client’s idea is less obvious — for example, they want to make an app for agricultural supplies, it’s better to increase the sample group to 40 respondents.
In this article, we explained how to conduct customer development interviews.
We select research methods based on the product complexity and market volumes
The research results will let you determine the target audience more precisely and make the product that matches their needs. If you neglect this part, it will be very hard to develop the product, as it will be a service for everybody, but not aimed at anyone specifically.
A case from our practice. Recently, we were contacted by a client who wanted to make a social network for those wishing to lose weight. We conducted research and found out that the target audience wasn’t interested in posting their gym photos and communicating with fellow weight-loss enthusiasts. However, many respondents tried many ways to lose weight and didn’t achieve their goal.
We suggested the startupper should replace their social media idea with an app where users could get professional help: find a coach or a nutrition expert who would create an individual weight loss program. As a result, a person would be able to achieve their goal without severe restrictions and stress. It will be an actual useful product — not an app in a vacuum.
Mistake 2. Overwhelming an MVP with too many features
Imagine that a startupper decided to create a marketplace of goods for photographers. The mechanics of this app are complicated: a few stores, recommendations, reviews, a payment module, delivery statuses, and even neural networks. The startupper decides to implement all the features right away, although it is expensive and takes a lot of time.
Two years and $100,000 later, the startupper releases it to the market at last. And suddenly, it turns out that users don’t need half of the features, and the UI is outdated and needs changes. Instead of developing the product, they have to waste time remaking what they have.
The core idea: it’s better to restrict the amount of features for an MVP. For example, if you are making a marketplace, start with a catalog, payment features, and delivery. Leave the smart recommendation system for later.
Think of how Telegram emerged. It was just a basic messenger at the start. Now, it’s a complex platform with chatbots, stories, video calls, and an advertising platform. First, Pavel validated his concept and then added features as he developed the platform. It is a perfect example of proper development.
I advise you to use the thumb rule to determine the key features of the app. At the CustDev stage, look for the main pain points of the audience and ask how much this or that situation bothers the person. Use the 10-point scale for that. If over half of respondents give it a solid 10, the problem really exists. Then, give priority to the feature that will solve it.
Case from our practice
We at Purrweb developed a service for remote renovations of apartments in Dubai. The client wanted to make an app for users, an app for designers, a web-based admin panel, and a landing page for collecting applications — all in three months. It was not possible to fulfill all the listed tasks over this period. That’s why we suggested using the versioned approach: to start with the MVP app version, select the top priority features, and then add other features gradually. Altogether, we planned 5 app versions so that after each stage, we could update the service in the stores. This way, it would be possible to gradually add features, and the client could influence the product growth by choosing the features with higher priority.
We prioritized all the features of the future app and distributed them between versions: we left only the key features for an MVP.
We decided not to overload the design and make a minimalistic UI to help users focus on the renovation process.
We designed new features for future iterations. We divided the renovation process into clear stages: completed, being renovated, and to-do. Also, we added designers’ portfolios, chats, and payment methods.
We suggested adding a feature for tracking renovation expenses: a user can select a budget, view spending, and save all the checks & bills in one place.
To make it easier for a user to specify their wishes, we decided to integrate design briefs with text references.
Mistake 3. No taking into account product development in the architecture
If we leave just a square meter for farmland, it’s technically impossible to grow an orchard there. An IT product has the same logic. At the start, you should make provisions for its growth. Leave a metaphoric 5-10 meters on the left and right sides of this square meter patch. If you don’t do this, your product won’t be able to grow, and very soon, it will lag behind its users’ needs.
For example, a startupper plans to make a social network for music fans. The concept consists of a music service and chat for communication. After the release, users ask to add a recommendation system and feed. But the product is made on a no-code platform, so it’s hard to add new features. The startupper will have to stick to the chat with the player or invent some workaround.
In this example, the startupper should follow the first rule of scaling: plan the product growth strategy beforehand, prioritize features, and discuss all of this with the contractor at the start. In this case, it’s possible to make provisions for everything in advance. And they won’t have to remake all of the app’s features to add a new one.
We at Purrweb use a comprehensive approach to architecture. This helps to make provisions for the future growth of the product 👇🏻
1. Select a way of building the architecture: a monolith or microservices. If your client doesn’t have much time for development, but scaling is important, we recommend you make a monolith with a module system. In the future, it’s possible to split it into microservices or add new modules. At the start, a developer won’t have to invent a complex architecture for every microservice or an interaction network between them.
2. Use the Domain-Driven-Design approach by Eric Evans. We use DDD in the monolith architecture because this approach makes it easier to add new features and, if necessary, to split the product into microservices.
Let me explain how it works. In DDD, there is such a concept as a bounded context. Inside one context of this kind, we develop the solution of tasks for a single business goal. Suppose a service already has two contexts: the production planning context and the context of implementing the plan in this production. If we want to add the product shipping status to the service, we will add this change to the existing implementation context. If the users will need a feature outside the existing contexts, for example, a feature for managing the production branch offices, it’s better to add a new context to the service.
When we want to add new features to the product, we ask ourselves if they relate to the existing business goal or to the new one. If the goal is new, we make a new context. If the system already has it, we add the feature to the existing context. It’s easy to split this system into microservices because all the entities are already distributed among contexts, and their communication is clear.
We place solutions for every business goal on the map of organic contexts, and then we build connections between the entities that emerge here
3. Select an approach to development: no-code or custom. The first option immediately restricts growth: here, they use the standard software for an app. The service’s time to market will be much shorter, but later scaling is impossible. The custom development allows you to make an app of any complexity and add new features endlessly.
Custom development always implies an individual approach to a client’s idea. That’s why custom apps always cost more than no-code services
Mistake 4. Not knowing if the contractor maintains the documentation
Sometimes, it happens that a startupper orders an MVP from a contractor but entrusts the further product development to their in-house team. Suddenly, they find out that the contractor neglected the document maintenance. This means that the in-house team will spend months puzzling out the contractor’s code and understanding the business logic. During this time, the startup is just stalling, and its owner spends money on the wages of the team that doesn’t add anything new to the service.
I don’t think that at the MVP stage, you should go crazy about the documents and record every step, but there are a few simple rules that will make your life easier in the future. I recommend you check if the development team does this.
Keep a record of the business logic. We at Purrweb use the system of BPMN diagrams that illustrate all the service work stages. For example, a customer ordered five cheesecake snacks from a grocery delivery service. The BPMN records show exactly how these snacks will get to the customer’s house and what will happen if there are fewer snacks in stock or if the store has run out of them.
This is what a part of a BPMN diagram can look like for a marketplace or an online store
Apart from the BPMN diagrams, we at Purrweb keep other records as well. For example, we use the UML diagrams and product acceptance criteria. But a client doesn’t have to go through all the documents. The main thing that must be clear from the records is that the app totally meets the needs of the target audience. If it is not clear from the documents, the client should synchronize with their contractor again.
Conclusion
Well, to avoid a startupper’s nightmare, you need to:
- Select a specific target audience and find out its needs and pain points.
- Avoid turning an MVP into a complex product with multiple features.
- Make sure the development team takes the product growth into account.
- Monitor the documents: at least a bare minimum should be available, and it must include a description of the business logic and product acceptance criteria.
All done! You’re amazing! Now, the chances of a successful release and further scaling are higher.
