What Comes after Proof of Concept?

Building a successful business requires understanding your customers as early as possible.

In today’s digital economy, enterprises and startups can (and should) put their product ideas in front of users throughout the product development process to test their assumptions and make the necessary iterations that benefit customers.

This is exactly how we want to help our clients in building their digital products. Oftentimes, they come to us with a product idea, some requirements, and a proof of concept. They ask us: What’s next? What comes after a proof of concept? How do we translate this product idea or an early version of an app into something that’s market-ready?

Ideally, an early product version — even as early as a proof of concept (PoC) — can already indicate whether the product idea has the potential to work, can be realistically implemented, and is economically viable. However, validating and testing your product ideas shouldn’t be contained only during your proof of concept process. Businesses and organizations should continue to question and validate their assumptions as they progress further in the product development process.

In this guide, we look at the stages that come after proof of concept with specific regard to how you can leverage them as validation methods. These will help shape your digital product become solutions that your customers will actually use and pay for.

This guide can especially benefit founders, innovators, and product managers struggling with validating product assumptions, product-market fit, monetization, and other business challenges for product ideas they already have.

This may also benefit those with an existing web or mobile application but want to enhance their product offering or pivot into something new. If you have some semblance of a product idea or a proof of concept and are worrying about how to move them forward, then this guide is for you.

First, we look at a quick review of what an ideal proof of concept should be and how to build one in a few simple steps. Then we look at how you can evolve your PoC into a prototype, then to a minimum viable product (MVP), and then into production.

We also provide you with a cheat sheet or summary of these four validation strategies to help you in your product development journey. Ultimately, this guide intends to help your product idea become a solution that can achieve product-market-channel fit.

Proof of concept: A quick review

A proof of concept is a very early version of a digital product that serves to validate assumptions around the product idea. PoCs aren’t technically developed solutions yet. It’s critical to bear in mind that proofs of concept shouldn’t be merely seen as an output but rather as a verification method that tests your assumptions about the very idea of your product. Extensive research and testing will help you determine whether your business idea has market potential.

In effect, the primary goals of developing a proof of concept are to validate that the product will be addressing actual customer problems and that the proposed solution is technically feasible. Ultimately, the intent of this validation process is to look for Problem-Solution fit.

Proofs of concept come in a wide range of forms depending on where you are in your product development journey or the talent available within the team. The most common formats are wireframes, presentations, screenshots, sketches, or documentation. Ideally, the PoC process should generate a combination of these.

Next immediate step: Draft a proof of concept report

Again, it’s essential to consider the development of a proof of concept as a methodology or process rather than as a mere output. Upon producing an iteration of a PoC, businesses must take the effort to assess if their idea is viable or not based on sound data (whether qualitative, quantitative, or both).

It’s not enough to look at your PoC output and iterate it immediately into a prototype. You must be able to provide clear and sufficient data-informed insights why you should pursue the product idea further, how to improve it, and if warranted, entertain why and how it might not work out.

Rather than letting these insights remain as thoughts and discussions among product team members, writing a proof of concept report will help enrich the process by forcing the team to articulate insights and next steps. This report should include research, the PoC artifacts (e.g. wireframe or sketches), and any data that may have been generated from the exercise.

The PoC report should also contain:

• Assumptions
• Discoveries
• Opportunities
• Risk factors
• And other points of discussion

To demonstrate the technical feasibility of the solution, the PoC should be supported by documentation laying out key functional and technical specifications of the product.

Further, this report shouldn’t be treated as a formality or a terminal document but as an anchor to align stakeholders on the feasibility of the product idea and the market opportunities that may lie ahead. This should empower the product team, founders, decision-makers, and other stakeholders to make informed and carefully thought-out decisions whether or not to move forward with the product idea.

After the proof of concept

Only after determining that your proof of concept demonstrates a promising solution should you proceed further on building your app. At the same time, this doesn’t mean that you should already call in your engineers to code your PoC.

After a positive result from your proof of concept exercise (but before going into full production), consider developing a prototype next and a minimum viable product thereafter. Remember to adjust your approach to your situation, including limitations.

1. Prototype

A prototype is an early version of a product developed in order to assess its functionalities and design concept by showcasing its visual form, simulating the user experience (UX), and implementing select key features.

Elevating a product idea from a proof of concept into a prototype serves a number of objectives. Prototypes help product teams articulate the most critical workflows in an application and the features that enable them. It’s also intended to showcase and examine the UX and the design concept.

By the time you’re able to produce a prototype in your product development journey, you should be able to assess the desirability of the product, both as a solution and how it looks and feels.

If a proof of concept validates for product-solution fit, a prototype begins to validate for product-market fit. To do this, prototypes should primarily test for these two assumptions: usability and desirability. Will customers be able to use it? Will consumers want it?

Product teams must focus on the following areas when building their prototype:

• How representative users interact with the product and the feedback they provide.
• The needs and problems of target customers or users (building on and validating insights from the PoC process)
• Testing and validating the product workflow
• Evaluating key features and functionalities with actual target customers
• Getting user feedback on the design concept and user interface (UI)

Prototypes are often shown or demonstrated to internal colleagues as well as representative users. Prototype artifacts typically come in the form of a user interface such as a mockup or no-code prototypes, which aren’t linked yet with backend systems or mechanisms.

Product teams can put these prototypes in front of selected customers to see if, for instance, they can navigate through a workflow or accomplish a specific task.

2. Minimum Viable Product (MVP)

A minimal viable product (MVP) is an early version of the intended production-ready application with just enough features to allow a limited number of customers to use it. An MVP is meant to be a simpler version of the envisioned product.

When testing it with early users, it doesn’t need to offer the complete range of features in your product roadmap. In fact, development teams should focus on key features for their MVP.

Businesses can avoid having to make lengthy and expensive changes further down the line if they decide to produce an MVP, as may occur when releasing a full product to market without thorough testing. Sometimes, MVP is also referred to as the Minimum Viable Prototype. Personally, it’s a better way to look at it as it reminds us that we should always be in an idea-validation mode.

The primary objectives of releasing a minimum viable product are to test the app’s main features, to assess its viability and desirability, and to test channels of distribution.

While unveiling an MVP typically doesn’t involve a full-on product launch yet, you should consider it as a vital part of your go-to-market (GTM) strategy. Unlike a PoC or prototype, releasing an MVP helps you validate if you’ve chosen the right marketing and distribution channels to acquire customers or users.

If a prototype validates for product-market fit, the MVP validates for product-market-channel fit. To do this, you shouldn’t only test if consumers want to use your product (i.e. the value hypothesis). You should also test if you can create enough traction to unlock a profitable business model (i.e. the growth hypothesis).

MVPs come in the form of either a low-code product or an implemented solution limited in scope. There are a few types of MVP you could explore such as a Minimum Marketable Product (MMP), Minimum Marketable Feature (MMF), or a Minimum Loveable Product (MLP).

3. Production

Product development is an iterative and dynamic process, which makes it difficult to judge whether an app is fully ready for public consumption. There’s no hard and fast rule when to say that your app is ready to move further from an MVP to production.

However, businesses have done well when they listen to the market and deliver what customers need and want. If in your best judgment, your app is ready for public use even if it's still only built for a limited set of customers, then it’s time to ship your product into production.

In a technical sense, an application is considered to be in production when it’s deployed into operation for its intended use for target customers. However, you should only deem your app ready for production when it’s a market-validated product based on its previous iterations as a proof of concept, prototype, and MVP. This doesn’t mean that you should wait until all key features and characteristics are implemented. It means that you’re able, ready, and willing to show it to the world.

Production-ready applications should also be a working product that can solve specific and actual problems through market-validated solutions. It can be marketed or released to the broader public, a limited market, or even if only for those who signed up early. In early production stages (e.g. alpha release, beta release), you should still be continuing to validate for Product-Market-Chanel fit.

At the same time, apps in production aren’t necessarily considered fully launched products yet. This is why you should still be testing the right distribution and marketing channels and further optimizing the product in time for your formal launch. Your goals should be to test product launch readiness and early market traction.

Continue to gather user feedback to validate your product’s marketability, growth trajectory, and monetization models. While paying attention to the business side, don’t neglect the product, especially in discovering new user pain points and solving them through iterations or new product capabilities.

An iterative process of building fast, failing fast

It's essential to reiterate that the product development process is dynamic and fluid. For instance, if the proof of concept or prototyping process signals that you should pivot your product, then look at the evidence at why and how you should pivot.

Before you start significant work on product engineering, you should endeavor to obtain sufficient data and insights as early as discovery all the way to a minimum viable product. And even if the product is already in production, this discipline of market validation is a method that you ought to repeat over and over again.

At every stage of product development, no matter the framework, methods, or processes you use, it boils down to these simple steps that you and your product team can easily observe.

• Identify your assumptions (especially the riskiest ones)
• Conduct an experiment to test these assumptions (no matter how simple the experiment is)
• Apply the results of your experiments to course-correct
• Repeat

The only way to do this — the only way to test your assumptions — is to put your product in front of real users as quickly as possible. In creating innovative products, the ones who can act on mistakes the fastest wins. This philosophy of "build fast, fail fast” is at the core of the product development.

By being aware of your assumptions, testing them, and iterating your product based on new insights, you can offer a solution that:

• Is aligned with business objectives
• Can solve user problems
• Is customer-focused
• Is data-informed
• Will “kill your darlings” (abandoning ideas and projects that are “darlings” to you in favor of those that customers actually want)
• Reveals your customers’ real thoughts
• Has a viable business model
• Is ethical
• Can be sustainable

Cheat Sheet: PoC vs Prototype vs MVP vs Production

These four stages — PoC, Prototype, MVP, Production — are typically (and ideally) done in sequence not just as a matter of natural progression in product development but as validation methodologies. To help further clarify the similarities and differences among these stages, the first table below presents a quick comparison of these four.

Depending on where you are in your product development or business journey, the table below can help you identify which validation strategy you may have to conduct next.

Be open to adapt and course-correct

Building a digital product is far from being a straightforward journey. It’s not as linear as translating your idea into a proof of concept, then a prototype, then an MVP, then into production, and eventually into a fully released product.

For instance, should your proof of concept process reveal that you need to make adjustments or even rethink the product concept, then don’t jump quickly into prototyping. It’s always better to adapt or course-correct if that’s the feedback you’re getting from customers.

Also, product development isn’t a box-ticking exercise that will automatically make your product market-ready simply because you went through a PoC, a prototype, and an MVP. These aren’t mere outputs that you need to produce, rather validation tools that help you assess the readiness of your product.

If you’re working on a product idea or in the early stages of a proof of concept, we at Netguru have helped startups, scaleups, and enterprises around the world build on their early work and turn them into market-ready digital products. We’d be delighted to learn more about your project.