If you reached this section then you certainly deserve a round of applause. This means that you have already completed the most complex part of product development. If not, then go back and read the previous parts:

Part 1
Part 2
Part 3

The rest is quite straightforward. Inexperienced product teams often mistakenly believe that software development is the most complex aspect of any product launch. However, if you have closely followed the previous steps, you have already completed 90% of the work. By now, you have resolved all the unknowns. You know precisely what you want to do, who your customers are, the problems they face, the solutions you can offer them, and exactly what to do to succeed.

You also have a very limited MVP scope that does not require years to launch. And you are ready to make your last sacrifice - MONEY. Your hard earned money, the most scarce resource that young teams usually possess. And there are many things that you can distribute it across, for example:

• A cloud server
• A good designer (because you don't want your final product to look like shit right?)
• A dev team (oh boy usually this is the most expensive one so I highly recommend to either learn coding yourself or invite someone in your team who will do the job for a stake in the future company)
• Security auditor (yeah dude, yeah, someone has to check if you really keep passwords in your DB encrypted)
• Fonts, icons, frameworks, API licenses and other resources that become an inherent part of the product that you are trying to build
• ...

In most cases, at least one of these elements is missing. If you weren't able to obtain all of them for free, be prepared to pay. Human labor is costly, so it's best to have the right people on your team from the beginning. However, if you don't, hopefully you haven't exhausted all your funds by now, as this is the ideal time to invest.

The only remaining question is how to effectively develop your product and determine the right technique. Below is an overview of the methods I recommend for early-stage product development.

The waterfall model is the most simple and straightforward way to develop your product. Every project has to go through the same sequence of events that includes gathering requirements and documentation, system design, implementation, testing, delivery, and maintenance. Unlike other methodologies it doesn't require any specific training or certifications for employees or project managers. You can jump right into it without battling a steep learning curve. It is a super easy start.

One of the main advantages of using the Waterfall model to build your MVP is that it commits to the end goal from the very beginning. Which makes it perfect for delivering products with a clear-set scope and a minimal set of features. Even though Waterfall is considered to be a bad choice for ongoing development and the maintenance of large and complex software products, it is an excellent choice when working on a proof of concept.

Agile has gained a lot of popularity in recent years and has beome the de-facto gold standard in software development. It is important to understand that Agile is an umbrella term rather than a particular technique and encompasses a variety of approaches to development such as scrum, crystal, extreme programming (XP), and feature-driven development (FDD). The most important thing to understand about Agile is its mindset. Unlike in Waterfall, teams working in Agile develop software in iterations, each of which includes a little part of the initial scope. This way they can minimise risks (such as bugs, cost overruns and ever-changing requirements) that usually occur when working on complex wide-scope projects.

Despite the obvious advantages of Agile when it comes to handling complex projects, I deter teams working on MVPs from using it for to the following reason: Agile setup is too complex. You need to remember that your primary goal is to deliver a proof of concept as quickly as possible to verify your initial assumptions, fail fast and iterate again. Instead, you will be spending too much time in daily planning and meetings. In addition to that, Agile requires some expertise and a specific skillset from team members which many early stage startups lack.

RAD is a form of agile software development methodology that prioritises rapid prototype releases and iterations. Unlike the Waterfall method, RAD emphasises the use of software and user feedback over strict planning and requirements recording.

It is most effective for projects with a well-defined business objective and a clearly defined user group, but which are not computationally complex. In my opinion, this makes RAD a perfect mix of Agile and Waterfall to deliver limited-scope MVPs under time-sensitive conditions. I highly recommend it to those who are aiming to deliver a proof of concept.

The answer is dead simple: iterate fast. Choose the methodology that allows you to build MVP, test it and fail as cheaply as possible because each additional loop will cost you more money. If you are new to software development and your project's scope is very small, go for Waterfall. If you have experienced team members on board who have spent years in Agile - then go for it. But never forget your main objective - move as quickly as possible.

Do not overcomplicate the process. Do not waste your time on choosing the right product/project/requirements management system. I have seen very successful projects started in Notepad and managed in a simple Excel spreadsheet. And that was not reason enough to fail. What would make you fail, however, is if you start wasting your time trying to find your ideal task management system, which will devour your team's precious time. Life will eventually get complex so do not be the one to introduce even more chaos. By the way this is the first sign of procrastination: spending most of your time setting up instead of doing the actual work.

So use your scarce resources wisely and you will have much higher chances of success.