Design before Development
Whenever a designer and developers start their work at the same time, this may lead to a bottleneck situation. It’s not like the developers need the whole design on day one, on the contrary, it’s great when they can participate in the designing phase. A lot of them have good ideas, they are looking at different things, but they can also quickly validate designer ideas. If you want to release the application as soon as possible, spending an extra day or weeks on some custom UI may not be the best approach. Of course, this doesn’t mean you have to get rid of all the fireworks, but more like the balance between UI/UX and time. If the development doesn’t end after releasing version 1.0.0, you can add improvements after that and you know what - users love updates to see that someone is working on improvements. On the other hand, the situation might be totally different and UI or flow might need full rework and then again, you saved some time by not implementing time-consuming custom UI.
Do not get me wrong here - I’m not saying that all of the designs must be done before developers even start to work, it’s not like that. What I’m trying to say is to let designers start a bit sooner i.e. 2 weeks, so that they can prepare white frames, the initial concept, some screens, and so on, because then, before developers set up their environment, it gives more time to the designer and developers to work closer.
Another benefit of having designs sooner than later is that the estimates can be more accurate. With such constraints as a lack of designs, estimates are mostly based on experience, but with designs, developers can plan their work on a specific situation.
Is this feature really a “must-have”?
Ask yourself a question if a feature is really a “must-have” and should be an easy one while you are building an MVP. If a user can live without something, the answer should be “no”... but it’s never that easy and some features might seem to be necessary. In the beginning, let’s clarify why we even have to think about it. The reason is simple: we are building a minimum viable product. For example, you are building a new e-commerce platform to exchange some goods or services. And you want to buy a printer, so you get 1234 results, but you want a pink printer so what do you do? You go to filters and select only pink color, that’s obvious. Or you want to hire a plumber, and you get 1234 available plumbers in your area, but who wants to hire a plumber rated 2.3 stars? So you go to filters and select 4.0+ stars, that’s obvious. Now, return to your product, are there going to be 1234 printers or plumbers available on the launch day? Probably not, most likely you’d be delighted if there was 10 of them.
So are Filters a “must-have” when users will get just a few results? I would say “no”, that’s not the problem of day one of a product life and that’s why MVP shouldn’t solve user problems that can appear a month or months after launch, because there will be a month or months to face those problems.
MVP should solve the primary problem, not the secondary ones.
In the example, the primary problem is that a user wants to buy a printer or hire a plumber while having too many results is the secondary problem. That’s why you should build your startup MVP as simple as possible and not include features that will delay the launch and can easily be added later. You can use the RAT (Riskiest Assumption Test) approach to test ideas and validate your assumptions without implementing them.
Marketing, marketing, and one more time marketing
There are three kinds of marketing: no marketing, some marketing, and marketing. “No marketing” is when you do nothing, literally nothing. That can only lead to a situation when your product will die a natural death because no one will ever hear of it. So, unless you just want to waste your money, or waste the time of people who will build the product, don’t go for it. “Some marketing” is when you spend on marketing as little as possible, maybe because someone told you that you need “marketing” and the conversion rate tends to zero and it’s not zero only because you click on it. Even if you get a few users, most likely they won’t even pay off the infrastructure cost. So close to “No marketing”.
Did you name your startup after you? Or maybe you came up with the original name? Unless your last name is “Wonka” or “Musk” or the name is “Big Kahuna Burger”, you need marketing. Actually, you need “the marketing”, that’s the way people begin to know your product exists or is being created. It doesn’t matter how great, innovative, and helpful your business idea is, how much work and money you put into it, how cool your designs are, or how many features you have. If there are NO users, no one will have a chance to realize that your product is something they needed their whole life, no one will admire designs, no one will use all the “must-have” features you just decided you must have. People must hear of the product and if you don’t tell them about it, there is no magic spell that will just make them know about it. The other thing is, if they will remember it, that’s why the product must be remarkable.
Choose the suitable tools
When it comes to building startup MVP, time is what costs you the most, because, before launch, you’re not guaranteed your product will be successful and every month before launch is you being in the red. What can help to release sooner rather than later is choosing the most efficient tools that will do their job. As a mobile developer, I’m going to refer to mobile development, but it’s applicable to every kind of development where you have a choice. In mobile development, basically, you have to choose between building native or cross-platform applications. As I have years of experience with Android native and Flutter development, I’m going to take these two as an example.
If you want to build exactly the same-looking apps, with some fancy custom UI for both Android and iOS, I would say go Flutter, building UI in Flutter is much easier and quicker. If you want to build high-performance with complicated calculations or lightweight applications, I would say go native, when something is universal, it has to weigh more and be less efficient. If you want to build a hardware-based application i.e. a camera app, where you want to allow users to draw, put stickers, or apply filters on the photo or video, I would say go native. In Flutter, you can merge a cross-platform and native, so maybe a particular feature can be native and the rest of the app be Flutter.
Every product is somehow different and each needs an individual approach, like with cars: Ferrari is great and on track but good luck with moving. The same is with development. There is no golden rule for which one is better because it depends on the product, its needs, and who will build it. The key here is to choose a framework/toolset which will better suit the requirements and features because that will speed up the work.
Manage your budget
Do you have unlimited money to invest? I doubt if at least one person answered “yes”. So if there is some line, you have to manage your budget. Maybe you have the potential for new investors or maybe your investors will invest more when they see progress, but still, you will need more money at some point.
To all who answer “no”, there is a golden rule, something that can make your budget theoretically “unlimited”:
Your product has to start validating as soon as possible.
Okay, but what does it mean? It means that it has to start making a profit, that’s why there is a concept of MVP, a product with the minimum viable features, something that will allow you to make any income or growth user base. That’s the reason why we were thinking if all those features your product will have are necessary or not.
In my opinion, while considering the budget, the most important decision to make is if we are going to stop development or not, once MVP is released. Both approaches have negative consequences such as: cost and product is not yet profitable, lack of work - no users, no feedback, and if everything from the scope is done. If development stopped, there might not be anyone to fix potential bugs, even when maintenance reaction will be slower. If there are a few months’ breaks and the team falls apart, rebuilding the same squad after a few months might be impossible, so there are new people onboard, people without domain knowledge. So maybe the approach should be different? Let’s assume you have a budget for 5 months of work and the estimate says 5 months. This doesn’t look promising, the estimate is just an estimate, it can take less time, but it can also take more. What if the scope for MVP was smaller? For example, 3 months, would it mean there would be a budget for extra 2 months of work post-launch? There would be a team with project insight, they wouldn’t be bored because of lack of work, and they would be able to address feedback or fix bugs quickly. There would be time to validate a product. This situation can be compared to buying a car, you need a car and you have 100K in your bank account, what are you doing? Are you buying a car for 100K? Most likely not, that’s irresponsible. The approach to MVP shouldn’t be different from buying a car.
While building MVP you will face a lot of challenges, but by avoiding these 5 mistakes you’ll increase the chances of success. Second part of this article is already available here.
Maybe you are just facing challenges after an MVP phase? Check out this article about scaling a startup.
Maybe you’re seeking a partner in designing and building MVP or other products? Let us know!
