Before launching on a full-scale development process, it is usually necessary to validate your product concept. After all, you want to make sure that you solve the right problem. Or, if not, find it out as soon as possible, preventing you from spending a lot of time and money on executing an idea that will not deliver the expected results.
At Helmes, we use agile development practices, including validating a project idea with a proof-of-concept, a prototype, or perhaps a minimum viable product. These three methods help keep the project scope as small as possible and provide helpful feedback before the full implementation of the project. However, they come with their own caveats.
In this blog post, we’ll outline some of the most common real-life situations you might encounter when building a proof-of-concept, prototype, or minimum viable product. But first, let’s get straight what we mean by each of these concepts.
Proof-of-Concept (POC) proves if the idea or concept is technically possible.
- The primary purpose of a POC is to test out functionality while usability and user experience are not considered.
- You use it when you need an easy reality check on the business side about whether your idea is technically possible to implement (and how much effort it requires).
A prototype is an example of a solution to test a concept or a process.
- A prototype is a visual representation of a product or process, where the underlying technology is not considered, only the UI or UX. Prototypes vary in their level of detail depending on their purpose – they can take the form of a simple image, be interactive or even mock the real solution.
- You use it to test if a concept or process is understandable with minimal resources before developing the real solution. For example, you could check whether the workflow is comprehensible or the layout appealing to the customer, which is always easier to convey through visualization rather than mere explanation.
A Minimum Viable Product (MVP) is a minimal solution that can be validated in the market.
- An MVP means building the bare minimum to solve the problem that the product is meant to fix. After the MVP is validated, you can add additional options and features.
- You use it as the most straightforward and fastest solution to a problem that you can test out in the real world before moving on to full implementation.
Even though it sounds straightforward, validating your product ideas requires practice.
Let’s get to work
If you have a business idea and are thinking of validating it with a proof-of-concept, prototype, or an MVP, we’d love to hear about it. Contact any of our people or drop us a line at info@helmes.com.
So here are nine pieces of advice for efficiently building a proof-of-concept, prototype, and MVP based on our experience with working with dozens of companies in diverse sectors.
No. 1: Don’t expect the prototype to look pretty
Don’t expect the prototype to look exactly like the end product. The colors may not be correct, the copy might read wrong, and the design might not look pretty – that’s okay. There is no point in making the prototype look perfect, as the goal is only to validate if the UI/UX is logical and demonstrate how some functionality should work or some page look.
You also must keep in mind the users who will be testing the prototype; if they need the design to look like the final product to improve their understanding of the flow, you need to put some effort into the appearance as well. Aim for the optimal balance that allows verifying if the developer is on the right track or any changes are needed before continuing with the implementation of the project.
No. 2: The MVP does not equal the final solution
When jotting down the requirements for your MVP, it’s essential to separate the critical functionalities from features that can be added later. If you cannot strip down the solution to a bare minimum, you’re not aiming for an MVP but a complete product.
Defining the essential features may seem a challenging task, but a development partner who is experienced in building MVPs can provide invaluable help in the process.
No. 3: Get to know your users
While this may seem an obvious point, it’s one worth repeating. We should never assume everybody thinks exactly like we do but verify our assumptions with actual end-users. Otherwise, it will be tough to build a product that solves a problem for them, resulting in spending time and money on something that will not gather traction in real life.
Developing and using personas designed to mimic the different user types that might use your product can be helpful in case there are no customers yet. The next step should be testing the prototype with a few potential customers before developing the complete solution.
At Helmes, it’s always interesting for us to team up with our clients to assist them in customer and problem discovery. For example, we have used personas for defining the requirements for a product and have even held full-day testing events where we collect feedback on a prototype from end-users.
No. 4: Focus on the real world, not an ideal one
When establishing requirements for a project, it’s important to stay rooted in the real world. Sometimes you may have an ideal solution in mind, while in real life, your employees or customers might be doing things differently and using different processes. Always take the latter as the starting point to ensure that the product will deliver value for the end-users and not miss any crucial elements.
Try to find actual users as early in the development process as possible and let your development partner talk to them or observe them ‒ it will make a massive difference in the result.
No. 5: Sometimes, simple things can be complex
It’s always worth being aware of hidden challenges and complexity in the background, making ideas more time-consuming than expected.
For example, adding a credit card payment or a social sign-in option to an application might seem like a straightforward task. In reality, it’s a technically complex process because of privacy and security issues involved and the integration with external systems.
Considering the required testing and configurations, this may mean some seemingly simple tasks could take considerable time to accomplish.
No. 6: Define things you will not do from the start
It may happen that your developer partner has almost finished their work on the project when you recall a new functionality that absolutely must be implemented. However, with the remaining time reserved for testing and bug fixes, adding new requirements would mean the project is not delivered on schedule.
It’s easiest to avoid such a situation by carefully planning the project scope at the start. Besides writing down the critical features that need to be completed, it’s wise to write down items out of the project’s scope. You can split those tasks into nice-to-have features (which might still be implemented within the project’s timeframe if there are free hours to spend) and features to be added in the future (if it’s a long-term project).
No. 7: Set aside time for communication
When developing a prototype or MVP, your developer partner may need some input and feedback from you at various stages of the project. If handling the project is an extra task for the product owner in your company, make sure that they have enough time for communicating with your development partner throughout the project on top of other tasks.
Setting aside (extra) time for communication will ensure the project will run smoothly, and the developer won’t miss out on important input and feedback from your side.
No. 8: Hold regular meetings with the developer
What is the most effective way of keeping track of everyday progress during the development process?
At Helmes, we have found that weekly status meetings with all the responsible people from the client-side with an analyst and a team lead from our side work extremely well towards that end.
During the meeting, we go over the to-do list and update the status of the items in the list. It might also be a good idea to share a status update already before the meeting so that you can spend valuable meeting time discussing issues and next steps rather than describing what has been done so far.
No. 9: Prepare for questions, lots of questions
Successful delivery often depends on pinpointing all the relevant details involved in the project. Therefore, be prepared that your development partner will be asking a lot of questions from you throughout its development.
Don’t flinch if some questions may seem unrelated to the project (for example, concern over the product launch or marketing strategy) or if the analyst asks the same question more than once. Asking many questions is simply one of the most effective methods for avoiding blind spots and ensuring that your prototype or MVP solves the RIGHT problem, provides real value, and is delivered on time.
Have an idea? We’ll make it happen!
Hopefully, these nine tips based on our experience provide you with some valuable insights for validating your product idea and planning the development process.
Helmes has been developing custom software for clients in more than 20 counties for three decades and counting. Our clients include fast-growing startups, and multinational companies in the telecom, fintech, logistics, healthcare, and other sectors and public institutions.
The article is written by our business analysts Krislin Viira, Kertrud Järg, and Elo Pelovas.
Let’s get to work
If you have a business idea and are thinking of validating it with a proof-of-concept, prototype, or an MVP, we’d love to hear about it. Contact any of our people or drop us a line at info@helmes.com.
