_edited.png){kind=small}
Putting your idea into a product is a very exciting, but work intensive phase of any new company. A digital MVP (minimal viable product) can help you test-drive ideas in a fast, safe, and effective way.
A few months after starting Supply Change we had spent a lot of time with our users and learnt a lot from interacting with them. We felt ready to put our most pressing assumptions to test with an MVP. After carefully evaluating our options, I decided to teach myself programming to build our MVP in-house. This is my journey, for you to code along.
Some social issues can be addressed through technological solutions. This means that a larger audience can be reached. Any tech for good project needs to be based on user focused design, to make sure that the solution is developed in an intentional and inclusive way.
Tech for Good is the intentional design, development and use of digital technologies to address social challenges. It is the combination of the most powerful and flexible tool we’ve ever had and good design approaches that are user-led and test-driven. Dan Sutch, Researcher and CEO at the Centre for Acceleration of Social Technologies
What is a MVP?
A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning when developing a new product. 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 amount of effort. The idea behind an MVP is that you produce an actual product that customers can interact with. Seeing what people actually do with a product is much more reliable than asking people what they would do.
A piece of internet history — The MVP described by Eric Ries
Decide what to build, and what not to build
A good place to start when deciding what to build is defining your target audience. You might have various types of users that will use your product in the future. But at the start, it’s necessary to focus on only one particular audience. The best way to go about this is to create user personas: define your audience according to their gender, age, education and hobbies. Define what their problems are and what your product will do to solve them.
The next step is to write a customer journey. You should think of the steps that your user will go through while using your product. Design the customer journey by spending time with your users and observe how they currently solve the problem you intend to solve with your improved solution. What you are looking for are the “Jobs to be done” by your customers. Focus on how your product helps your customers get their jobs done in a better, more efficient way.
Focus on the most important jobs and summarise them as user stories. User stories are short, simple descriptions of a product feature told from the perspective of the person who will be using the new product. This is a common format of a user story:
User stories can then be translated into product features. Only the most important product features should go into your MVP roadmap. Your MVP roadmap forms the commitment of features that will be contained within the MVP. Remove all the features that are not crucial for testing your main assumptions. Any features that fall under the category “nice to have” should not make it on to your road map. Review the road map with your team and make sure that everyone agrees on this. A clearly structured roadmap will help you as a reference point when communicating to your co-founders, investors or other stakeholders.
There is a great free course on Udemy about Product Design which is highly relevant to this section.
What should your product look like?
Once you have decided on the core features, it is time to build wireframes of your product in tools such as Figma or InVision. These tools also let you animate the journey between your wireframes and will quickly help you to evaluate any logical issues.
If you are in need of a little inspiration for your wireframes, check out Land Book or Dribbble where designers frequently publish their work. These are handy to get inspiration on landing pages or profile designs.
Once your wireframes are ready, this would be a good time to show them around to colleagues and trusted users for initial feedback. Observe the user on their interaction, make sure you separate useful feedback (usage, flow) from less relevant feedback (comments on the colours of your buttons). Ask questions like “Would you have expected something else?” , ask “Why” a lot. Don’t assume anything. Don’t guide the user too much or apologise for the simplicity. Incorporate the most pressing comments about your user feedback, and you are good to go.
This research is a great basis for you to write a specification brief for a web agency or freelancer that might take this project further with you. Some agencies also offer to do research with you and your users together to make sure that the MVP will meet your needs.
A MVP can help you evaluate your core assumptions
Outsourcing or building in house?
Now that you have determined what you want to build, you are ready to make this a reality. Next you will have to decide if you want to outsource product development to an agency or freelancer, or if you want to build your app in-house.
Outsourcing has become a very popular option for companies. Options range from established UK based web agencies to freelancers or social enterprises such as Gaza Sky Geeks. Our initial prototype was developed together with Gaza Sky Geeks, giving us a good understanding of this route.
However, building our MVP would require investing a significant amount of money and time, so we wanted to re-evaluate our decision. There are common things to consider around outsourcing your development process:
Time — Teaming up with an external resource allows you to know beforehand how long it will take to build a prototype (provided everything goes to plan). This can create accurate scheduling to keep your project on track and your in-house team can continue to focus on strategic topics.
Experience — Outsourcing allows you to leverage the experience and tools of outside experts. However, that also means that at the end of the project, the expertise will remain external too.
Cost — Outsourcing is likely to be the more expensive option compared to building in-house, however it lets you assess the cost of a prototype build before committing to it. This constraint also helps with project focus and deadlines. Make sure you account for initial build cost, as well as adjustment and maintenance costs.
Flexibility — Outsourcing your project means that changes to the MVP at a later stage will always cost you money and you will have to rely on the future availability of the agency or freelancer.
Quality Assurance — Assessing an agency or freelancer offer as a non-technical person is highly challenging, if not impossible. You will have to make a decision based on trust. It will also make it very difficult to foresee any problems with your choice in the future, when you might have to scale.
Knowledge — Building a technical product means thoroughly working through a problem and not leaving any scenario to chance. Having the person who has to work through these scenarios in house will spark great discussions. It will give you a deep understanding of the problem you are trying to solve.
Involvement — Building your technical product in-house will make your team highly vested and involved in its development and therefore, in its success too.
Impact — Nobody understands your social enterprise as well as you do, especially the impact element. Building in-house will allow you to focus on and not compromise your impact.
After considering these issues, having to invest the majority of our raised capital into the build of our MVP made me feel concerned. After all, an MVP is just your first shot at solving a product, most of the time you will need various iterations in order to get a market fit. I felt that the product we needed at this point was not complex enough to require cutting-edge, expertise technology.
If at this point you are leaning towards outsourcing your tech build, I recommend reading this book. It demystifies a lot of tech topics and prepares you for working with technical teams.
If you are leaning towards keeping the build in-house then continue reading this blog in Part 2.
Verena Wimmer is the Co-Founder and CTO of Supply Change Supply Change designs solutions for social enterprises to win more public sector contracts maximising social value in public sector supply chains. www.supplychange.co.uk