Minimum Viable Product development: how not to fail on the way

Every tech startup has thought of an idea that could blossom into a product loved by many. Many startups come to Moqod with a clear idea of what they want and what kind of problem they solve. Once the core is formed, one moves onto bringing the concept to the market via building an MVP around it. 

There are several ways how we may help you bring your business idea to life. In this article, I observe the optimal approach from our experience from a pragmatic perspective (most value for money). 

MVP Equals Iterative

An MVP is one of the most used words in the startup universe. According to Wiki: “It is a core artifact in an iterative process of idea generation, prototyping, presentation, data collection, analysis, and learning.” I emphasize the word “iterative” as the core value of MVP lies under this definition.

In a perfect world, you want to get an MVP the way you imagined it right away. More importantly, the way you imagined it is precisely what your starting business needs. In reality, the process is iterated until a desirable product/market fit is obtained, or until the product is deemed non-viable. Sometimes it can even end up in a place nobody could expect (remember famous Youtube pivot case?).

With an MVP, you hypothetically kill two birds with one stone. First, you can see how well your idea in practice. Second, you save quite a bit of time and money on development instead of investing into a full-fledged product.

There are a few ways on how you may proceed with an MVP. Further, let’s look closer how do they satisfy our request for iterative.

Do It Yourself 

Depending on the complexity of the idea and your level of expertise, you might consider building an MVP yourself. If you can prove market fit fast this way – go for it! We have already described this approach in detail in the article, where we recommended a certain number of tools for building your MVP without coding. 

Hire Your Own Developers

Hiring a team (no matter one developer or many) starts from the proper recruiting process. Further, it is closely connected with leveling off clear expectations, setting up business and communication processes, ensuring the same level of motivation, keeping the spirit high, retaining team members, and on and on. The process is so sophisticated that it demands to be thoroughly covered in separate articles (not mentioning the cost issues, that we described in detail here). 

After you hire people, you are stepping into the universe of employee responsibilities and no longer free in your decisions whether you want to move on with your startup or you want to get back to your previous life. Also, consider that now you are limited with the tech skills your new team has. So if market feedback tells you that you must pivot to the different sets of tools, would you also pivot to the different team? 

Let a Vendor Do It 

Alternatively, you might decide to entrust the whole MVP development project to a vendor as is. Startups often come to vendors like Moqod and want to launch an MVP right away. 

In the world of software development, we call this type of approach “project-based”, as it has start and end dates, clear scope, features, functions, and the price agreed in advance. You are supervising the project while it’s being implemented, still, you don’t have to think about development procedures, you have it all figured out right away. With this almost ideal rundown, what could go wrong? 

Why Project-based Assignments Fail for MVPs

Remember, we are keen on iteration? 

Startups come to developers with the idea based on what they already know. This is totally natural: we all always make our decisions based on the data we have at the moment, both in our work and private lives. 

However, while a business owner may be thinking that he knows what his customer needs, the truth is that very often (honestly, almost always) we are NOT our ideal customer. Then the project moves forward, more information comes in, and it drifts away from the initial idea. With a fixed amount of hours, price and deadline, this work process might spiral into a cluster headache for everybody. 

Even if you start renegotiating the hours and further refinements, you are still doing it based on what you know at a given time. While it may seem easy to ask the developer to “remove X and add Y,” the process is not as simple behind the screen. 

You can change the back wheel on your car without interfering with how the front wheel works. You can’t, however, replace one feature with another without getting in the way of the development. Almost all the tasks are interlaced with usage, technologies, frameworks, deadlines, and other nuances. A simple change might take longer than it seems. If you want to make a change on the fly, it is hard to predict what it’ll look like in terms of hours and money because the developers will have to adapt it to the existing project. 

Even if you make those changes (and pay extra billable hours), when you launch the ready MVP, you might still face a denial from the market and need to adapt to newly obtained knowledge fast. 

In our practice, it’s because this model may lack flexibility (again, iteration is a king.) New projects and starting businesses require the owner’s engagement all the time. Your MVP shouldn’t be an exception — the less you are involved, the further your MVP from the market needs. The idea itself is not the key to success, but the method of implementation is.  And you are the only one who has the vision of how to make it fly.

The truth is, no MVP is perfect from the very beginning – nothing is. Your MVP is where you could apply the law of Pareto, where 20% of work gives 80% of the results. Better ready than perfect! 

What if we suggested a more flexible approach?

Get a Skilled Team to Build It

Let us assume right away that the final product won’t be the way you saw it in your mind. You get a dedicated team with the necessary technical skills’ composition to work on your MVP under your supervision, where you are the owner and the manager (designer, marketer, business developer, tester – you name it) of the product. How is it more straightforward than the previous solutions? 

From our experience, this is often the best way to go as it is as agile as possible. It is a lower-risk way of testing your idea on the market because the work is done in two-week (sometimes even one-week) sprints. At the beginning of the sprint, the team lays out the scope of tasks and reviews the work in the end with the customer. For a new business, it is way more effective than trying to evaluate the results within 3-5 months. Shorter sprints leave room for more effective and precise adjustments. 

We would break down your MVP into smaller tasks using the MoSCoW method. We will start with the Must-tasks, and incrementally adjust the backlog to the new data together with the client. This way your scales properly, instead of scaling prematurely. You will be able to test and validate the hypothesis using product metrics. Also, when your project is launched, it is a great stepping stone in looking into funding instead of waiting for it to be perfect.

This approach allows both parties to focus on product development instead of discussing extra hours and changes. 

Conclusion

When you climb a mountain, the higher you go, the more the view changes. What you were able to see from base camp expands to broader horizons with every step. You adapt to the altitude, the temperature changes, and you can give yourself room for adjustment. 

This is how it works with shorter sprints: the more you advance, the broader your horizons become. You can pivot faster, adjust to the changes, and it could turn out better than initially imagined. At Moqod, we are in a strong position to vouch for the efficiency of remote teams, having succeeded with such projects as Bittiq, Shypple, and Learned among many others. So move forward with your project in the most efficient way, focusing on solving your business problems first and leaving technicalities to professionals.