So, an idea for a project is there. But, where should you start and how should you think in order to implement it successfully? The set of guidelines provided below might come in handy as they are the steps that we take from the point that a client comes with an idea until we have completed the product. See them as a guideline on your journey.

Our Function Factory is a few years old and we have implemented more than 14 MVP projects so far. Along the way, we have learnt to recognize things that should be done, the things that should be avoided and the general path in project development that has taken many of our projects to success. Based on the aforementioned, I have created a set of guidelines hoping it would help you in a project.

Step 1: Define the scope 

The first thing that should be done is defining the scope of the product which can be, for example, a web or a mobile application. Prior to starting to define the scope, let’s define an MVP which according to the Agile Alliance is: 

“Eric Ries, defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. This validated learning comes in the form of whether your customers will actually purchase your product.”

So in short, we need to define the minimum amount of features needed to create a functional and testable product (MVP). Our suggestion is to have a workshop with the client where the client explains the main purpose of the product. From there, you create epics and roughly define user stories  without going too much into detail. To visualise it, we usually use Trello. The most important thing to keep in mind during the scope definition session is to find solutions that give the most value in the shortest amount of time. 

 Tips on how to make the scope smaller:

• Focus on “must have” vs. “nice to have” features
• Don’t worry about making everything fully automated, maybe some things can be done manually through the database or similarly

Step 2: Prototype + Test

After you have compiled a list of features, you know what you need to create. A great way to start is by prototyping. We suggest doing low fidelity prototypes (a low fidelity prototype is a very simplified version of the design without too much detail). It can be black and white and only the key elements are included, meaning no detailed text, no images, no styling. You can use tools like Balsamiq or simply do sketches on paper. A great advantage of doing a low-fidelity prototype first is that it can be completed and changed very quickly.  

After the first version of MVP is done, it might be necessary to iterate it with the client multiple times. Don’t be afraid to spend time on this, it will lay the groundwork for the implementation and straighten out any question marks regarding the features. It is also a good idea to do some testing with potential users.

When you have a version that is good enough, you can proceed to creating high fidelity sketches. They need to be created and modified based on the needs of the project. In some cases, it is enough to create a graphical profile which defines the colors, fonts and elements which are later just applied to the low fidelity prototype. However, in some cases, the client might want to do extensive testing which requires clickable versions of the prototype. So, in this step it is important to do what is right for the project (having the overall time and budget in mind).

Step 3: Implement

Regarding the way of working, it is important to choose something that makes sense for the particular client. Usually we follow Kanban since the scope is fixed and we track the progress through Trello. Demos are organized either ad hoc or bi-weekly.

Due to the budget limitations MVP projects often have, it is important to make sure that you stay inside the defined scope. 

A tip: make sure that new requirements don’t appear and that focus is on keeping everything as simple as possible. 

When starting with the implementation c a stack that makes sense for the project and for your team. Our team mostly works with the MERN stack, if it suits the project. When developing mobile applications, we usually do it using React Native (if possible) because you get two applications, but develop only one which is very cost-efficient for the client. It goes without saying that the security and pricing of the deployment and hosting are important. A tip:  do it “good enough”. 

Since the development can go quite fast,  we recommend to start with the deployment questions early. If the client needs to buy a domain they should do it as fast as possible. If you are going to deploy a mobile application on the App Store and/or Google Play, they should set up the accounts and applications at the start of the project.. If you solve deployment issues early, you can make the product testable by the client quickly. This can help with having the client involved and getting feedback fast. 

Step 4: Handover the MVP

After the development is completed, the project usually goes into a testing phase to see if the product has a value on the market. It can be useful to help the client with this by guiding them through user testing sessions. Knowing what questions to ask and how to set it up can be crucial to get the information needed .

It might also be a good idea to add tools like Hotjar or Google Analytics in order to track the usage of the application.

So, to summarize…

•  Define what the “must have” features for the application will be.
•  Create a simple prototype and test it. 
• Stick to the design during the development to make sure you stay within the scope. 
• Keep the client in the loop to assure that you get feedback in time. 
• Be there for the client during the testing phase. 

And, don’t forget to have fun in the process! It is a privilege to work on innovative and creative projects. 

Before you go, a few words about me.

My name is Neira Causevic. I was born in Stockholm, Sweden, and I have lived there all my life. About three years ago, I moved to Sarajevo to start working at Softhouse. Many people ask me why I moved, and the short and simple answer is that I really love being in Sarajevo and combining that with a Swedish work environment is a perfect merge for me.