Before we dive into the topic of Minimum Viable Product Development, let’s briefly discuss what an MVP is. An MVP is a minimalistic version of a business’s idea for a product, and for this article that means a software product. This initial product is usually set up with only a basic list of features which gives customers and potential users an idea of what the product will look like.
There are a number of reasons why businesses develop MVP’s. Some of which include: wanting to release their core idea into the market as soon as possible, testing the demand and usability of the product before making a full launch, developing an initial user base, reducing implementation costs, and a number of other reasons unique to the startup.
MVP development can sometimes be a challenging process, but in order to shed some light on the topic we reached out to Scott Craig from AccelOne, a Seattle-based software development company, to give us some expert advice.
We began by asking the simple question:
“What are the most important things to consider when beginning to develop your Minimum Viable Product?”
Scott: Before even thinking about how to develop an MVP, it’s important to consider whether you will outsource or develop it in-house. Whatever you decide to do, you should strongly consider thinking about the following areas as it relates to both your approach to planning and contracting/building a development team:
Get a Technical Representative as a Product Owner on Your Side
Although It’s not 100% important to have someone like this on your team, it does help both the client and vendor along the software development lifecycle. This individual will work closely with you and be able to validate software architecture, tech stack selection, management tools, authorizations and communication protocols.
Design First (UX, UI then Prototype) and Then Code and Apply Quality Assurance Testing.
Today, you can program a clickable prototype of your application so that you, your investors, your partners, managers, employees and potential users can experience it before a single line of code is written. It is relatively inexpensive to create a prototype on prototyping platforms such as Invision or Adobe XD and if you create a prototype that all of your stakeholders and potential users can click through and experience themselves, you can be more confident that what you are creating is what you and your users envisioned.
You may want to spend a good amount of money on an experienced User Experience (UX) Designer when creating your application’s User Interface (UI) Design and prototype. The reason for this is because if your user’s experience is off the mark, some of the development dollars you otherwise will spend to code the application will go to waste once the app is launched. In other words, extra time and money will be spent on having to go back and fix things that fail to meet your customer’s needs.
Do you have any tips on establishing good communication?
Scott: Make sure that you are using modern and high-quality communication and project management tools. This will increase communication velocity and responsiveness on both sides.
As far as general communication goes, we should remember that with every conversation, there are always two sides to a story. For this particular reason, make sure to document all conversations, states of production, timelines, and promises. Talking and having open communication is always important, but it’s a good idea to document what was discussed and what agreements were made in previous conversations. I would suggest sending an email right after each meeting or conversation as a way of documenting what was said. This way, both sides can confirm their understanding. This is a very helpful tip because you can always go back to a specific email thread for legal and non-legal purposes.
It’s a good idea to have your entire team understand and use this protocol as well.
What’s the number 1 thing a product owner should always remember?
Scott: This may sound obvious to some, but as a founder or product owner you should be the owner of the code repository and the only one granting permission and access to developers. If you do not take control of your code repo, your outsource provider will. And that is fine if you remain on good with your provider, but if something happens, you risk becoming hostage to the provider and they will ultimately be able to do whatever they want with your code. I have unfortunately witnessed the result of this unfortunate situation on several occasions.
For our final question, do you have any tips to share when it comes to working with investors or partners?
Scott: Yes, be positive but realistic with the story that you communicate to investors, partners or employees to get them on board of your vision and mission. Many times along your startup journey, the original story you tell tends to change along the path of evolution and understanding and that change can result in people losing trust in you if they heard a sensational story the first time which is followed by yet another one.
Wrapping Up
Developing an MVP may be a challenge, and is often something different than a client or development agency is accustomed to. But MVP development can bring with it a number of benefits that other approaches may not.
