Startup Series Developing Your Minimum Viable Product
In our last article, we covered a number of ways that you can Design Your Minimum Viable Product (MVP) by leveraging existing products and services. This can be a simple and cost effective way of getting an early version of your product into the hands of some customers, with the ultimate goal of validate the assumptions you’ve made about your business model.
You may however find that there is no existing service out there that suits your needs, and that you will need to leverage the skills of technical experts to properly implement some aspects of your product, this is particularly the case if the functionality of your product is complex.
The process of product development (in the context of web, mobile and desktop) can be performed in many ways using many different methodologies. They will however typically involve the steps detailed in the remainder of this article.
The design of your early product version covers more than just the aesthetic appearance. By starting with wireframing, in other words, sketching out a graphical representation of the product, you can quickly identify shortfalls in your idea, and area’s that you need to address. From wireframing we can move onto both the graphical and technical design of the solution. The graphical design will cover the visual appearance of the product, whereas the technical design will cover programming language choices to the structure of your underlying database. Some solutions don’t require all the steps to be completed, while other need more work in certain areas, but for any project, I think it’s always a good idea to start by visualising the product using wireframes.
We first want a set of sketches which will allow us to visualise the product, these are also known as mock-ups. You can start off with pencil and paper or you can use software to help formalize this for you. My software of choice is Balsamiq, however this comes at a price, so if your budget is tight then you can utilize one of the many free wireframing/mock-up products out there.
For products that are purely functional, graphic design may not be necessary, you will however usually want to get a logo made up. Find a graphic designer whose portfolio you like and who communicates well, you will need to be able to connect with them in order for them to interpret your ideas correctly. The designer can take the wireframes you created earlier and base their work off these. Visual interpretation is subjective, so there will most likely be a lot of back and forth that goes on between you and the designer. They’re used to this, so they will most likely mention that you have a number of revisions available when defining the terms of the project, and if not, be sure to raise this yourself.
As with everything when it comes to the MVP, getting the graphical design optimized to best connect with your customers will take time and experimentation. Using various analytical methods which will be discussed later, you can test your customer’s response to the design, and make adjustments accordingly.
This is one area that it pays to be in contact with someone who knows what they’re doing. Technical decisions that are made at the start of a project will remain present for the duration of the project. If core changes to the technical architecture are necessary then they can be very difficult and costly to pull off, and in a lot of cases it becomes a more viable option to start the technical development from scratch. So, by making wise and future proof decisions from the start, you will be in the best position to be able to scale your solution as time passes and your customer base grows.
Lead or senior developers as well as dedicated application architects will be your best bet in ensuring the correct decisions are made. Again, you’ll want to make sure their portfolio is good and you can communicate with them easily. Consultancies will always have the more experienced programmers on board, and so are often even more reliable.
The architectural design can start when the initial wireframes are completed. By providing these to your architect, they will be able to start breaking down the individual components and piecing the solution together from a technical perspective. You will at this stage want to discuss with them any 3rd party services or platforms, such as a Content Management System (CMS), eCommerce platform or Customer Relationship Management (CRM) system, that you are wanting to incorporate into your MVP.
What you will end up with is a clear and documented plan of the platforms, frameworks, programming languages and 3rd party services that your MVP will consist of. But once that’s done, it’s time to build.
If you’re lucky, you’ll be able to get away without having to write a line of code for the initial MVP. However, you will often need to utilize the expertise of a developer to get your MVP off the ground. It’s important to note that software development is a long process, and it is imperative that adequate thought and planning be completed prior to the first line of code being written. Luckily, if you have followed the previous steps, you will have a well thought out scope of work which can be handed directly to the developer to start work.
Regardless of the platform that your application is to be released on (web, mobile or desktop), the source code of your project should live primarily in one place – and it’s definitely not your sole developer’s laptop. Source control is the modern way to store and share the source code of a project. Source control is a way of managing the source code and its associated file versioning in a secure and distributed way. It helps to make it easier to keep track of changes to files and also to resolve any change conflicts in the files (simultaneous changes to the same file). Source control is the modern way of controlling the source code associated with a piece of software and currently Git is the most widely used source control system. My suggestion is to ensure your developer is working out of a private Git code repository hosted by either the GitHub (paid) or Bitbucket (free). The great thing is also that you will be able to see details of the code changes as the come in, as a “commit message” is associated with each code “check-in”, also you will be able to provide and revoke access to other contributors as the project progresses.
If your MVP makes use of an existing platform, such as a CMS, eCommerce platform or CRM system, you may not have a need source control. You will however want to keep track of any username and passwords your developer might be using in a safe and secure place.
Deployment is the process of taking the source code of your application and packaging it up and putting it at a location where it is accessible to the public, or at least to a limited sub-set of users. Depending on the platform that you’re deploying to (web, mobile or desktop), the steps to deploy the source code will vary significantly. This will most likely be another task for your developer or the technical architect.
For web deployments, you will in most cases need at least two things; a domain name and a hosting provider account. The domain name is the web address which points to your product, such as coolclothes.com, a domain name like this must be configured to point to your hosting account. The hosting account is a where all the source files reside, this will be a folder on a special type of computer on the internet, known as a web server. The process of deploying a web application consists of uploading the source files to this hosting folder. Then, when someone opens up their browser and types in your domain name, the browser will be directed to the place on the internet where you source files, and ultimately your web application, is located.
With mobile app deployments, the typical process is that your developer will ‘compile’ the source files into a specific type of file which can be uploaded to one of the app directories, such as the App Store, Google Play or the Microsoft Store. Prior to the upload, you will need to have created an account for the app in one of the various app directories, you will then be given a location to upload the app file to through the directory interface. It’s important to note that some of the directories, particularly the App Store, have strict rules as to what kind of app features are and are not allowed, so be mindful of these restrictions as early as possible.
Desktop apps can be arguably the easiest type of application to deploy. Similar to mobile apps, the developer must ‘compile’ the application to a particular type of file, an installer. This can then be shared and anyone who obtains a copy of the installer file can most likely install that application, assuming they’re using a compatible operating system (Windows, OSX, Linux etc.).
Once the first set of development tasks are complete and a first version has been deployed, it’s time to test. Beware that there are a lot of variable factors in software development that can mean behaviour is not consistent across browsers, devices and operating systems. If an application works on one device, it may not work on another. Also, different states of data that the app is handling can produce different results, and sometimes certain use case scenarios have been missed in the development process, and errors can occur. This is why it is important to test thoroughly and using as many different test case scenarios as possible to minimise the risk of errors or inconsistencies occurring when the application is being used by a customer.
My suggestion is to write an extensive set of test cases which all relate to the core features which have been captured in this first release. For example, here is a small set of test cases:
“The user can login and be redirected to their profile page with a valid user name and password”
“The user will be shown a validation error when attempting to enter an incorrect user name”
“The user will be shown a validation error when attempting to enter an incorrect password”
By creating an extensive set of test cases, and running the tests regularly, you can be sure to release a more robust product to your customers. Not only that, if a use case does not produce the desired result, you can easily forward it to your developer. Ideally, with the broken use case you should provide the below information, as this will provide your developer with a better idea of how to first replicate and then ultimately fix the issue:
- Steps to reproduce the broken use case
- What I expect to happen
- What actually happens
With the completion of the testing phase, your product is ready to make it into the hands of some customer. Check out the next article in our Startup Series, where we cover the various ways to market your product and start attracting customers.