Since working with Bixly, the BeGreat app has pivoted to a new concept, however version one of the app is still a wonderful example of how a simple...
Your Proof of Concept
A proof of concept is an experiment, test, or early version that validates assumptions. It should contain research to identify the viability of an idea.
Once you've thought of the idea you want to build into a new app, it's easy to get so excited about your vision, that you don't consider what customers actually want. Proof of concept is a quick way to pump the breaks, get customer feedback, and refine your business model.
However, testing your idea and getting feedback shouldn't be exclusive to your proof of concept. It should be central to each stage of your product development. That's what an MVP is all about. That's what agile is all about.
What is a Proof of Concept?
A proof of concept is an experiment, test, or early version that validates assumptions. It should contain research to identify the viability of an idea. A proof of concept can have wireframes, screenshots, early designs, and documentation. There are two main questions you should focus on answering when developing your proof of concept. One, what is the main problem this software will uniquely solve? Two, what are the specific pain points potential customers are currently experiencing? The proof of concept should include evidence and documentation proving the viability of the technology and the business strategy. It is not a developed piece of software. This step should occur well before you start writing code. The proof of concept should help you identify exactly what code you should write.
Why is it important?
Identify What People Want
With a proof of concept, and I would suggest additional and continuing market research, you can identify what people want. Identifying user needs and user pain points is your golden ticket! In addition, your proof of concept research can help you understand who your people are. What is your target market? Who is your ideal customer? This can be done with market research, surveys, interviews, or focus groups.
Outline feasibility and limitations
Once you have digested the needs and desires of your market, it's time to tackle the question of how to bring a solution to them. This is where feasibility comes in. How likely is your project to succeed? What technology will it rely on? What are some of the potential risks? What features or aspects contain unknowns? Are there limitations to what you will be able to do, either at all or due to budget constraints, or simply due to technological constraints?
If you are not a technologist yourself, connecting with a company like Bixly for Project Roadmapping can be extremely helpful. It may not be immediately clear which features are easy and which take more work. Technology experts can sift out those features for you. We recommend a paradigm that identifies which solutions are high or low effort, while you identify which ones make a high or low impact for your users. This allows you to avoid that which takes a lot of time and money, while not making much of an impact for your users.
A proof of concept can be the first foray in beginning to estimate the cost of building your solution. Now that doesn't mean it will match up with business-provided budgets. In the case that the technology costs more than approved funds, there are a few ways to proceed: one, developing a very lean MVP or prototype only; or, two, securing funding from investors.
A Compelling Investor Proposition
Since you have at this point completed significant market research, identified pain points for users, understood the feasibility and limitations of your product, and identified your market, you are ready to make a compelling presentation for funding. You should already know the viability, profitability, and market share for your product. The last piece is answering the question: is it a good investment?
A proof of concept generally takes the form of a written report containing some of the following: product goals, feasibility, limitations, technology recommendations, market research, and target market. A prototype takes all the research done in the proof of concept and brings it to life in a visual and interactive form. It is an early version of a product that attempts to simulate the user experience. It is generally not coded but represented through wireframes, user flows, and high-fidelity designs. Designs can often be made clickable to showcase the essential components of the final product.
A prototype can do more for you than help people understand the goals and visualize the final product. Observing users interacting with your prototype can give you key UX feedback. Do they find certain components frustrating or nonintuitive? Do they ignore whole functions of the software? It helps you further validate the product workflow and key features.
There is a ton of content all about minimum viable products, including some of our own content here. In summary, an MVP is an app that is a complete whole. It is viable. It is production ready. However, it has only the essential functionality built. It is a simpler vision of the full envisioned product. This is key to the agile workflow, since changing massive software projects is often expensive and time-consuming. Getting feedback early and often from your target market helps businesses avoid costly investments in features that don't matter to users or overlooking simple fixes that do. It is a key piece of the journey as you continue to validate your product and business.
As you iterate on your MVP, taking into account user feedback, you will approach your full-featured software. Due to the agile approach, it may differ greatly from your original product roadmap. However, the idea of incorporating this essential feedback is that you will end up with a vastly superior product than what you may have originally conceived. Even as we call this a "full-featured" web or mobile app, you may choose to continue adding and modifying features. In fact, most users expect updates and improvements over time. However, this version is achieved when you have a working product that solves specific and actual problems, preferably the very one you identified in your proof of concept.
As you can see the Proof of Concept is the first step in your development lifecycle to owning and deploying a custom software solution. It sets the tone for the iterative process to come. One that relies on research, testing your assumptions, and prioritizing customer feedback. For Bixly, a Proof of Concept is equally successful if it eliminates an idea as if it affirms it. In fact, the earlier you can identify a bad business move or investment, the better. Because a Proof of Concept requires no development time, it is a cost-effective strategy as well.