How Proof of Concept (PoC) can save you from product launch disaster

Launching products is a risky business, with extremely high failure rates. And it’s not something that only affects plucky startups. Remember the ill-fated Google Glass? The company lost around $400 million in development, which by all accounts is a product development disaster that would send most companies under. 

Was it bad marketing? Bad design? A concept that felt invasive? A little of all three — but ultimately, it happened because the tech giant created a product that no one wanted. If they’d invested more time and energy in Proof of Concept tests, they might have avoided the costly mistake. Luckily, you needn’t fall into the same trap. In this article, we’ll take a closer look at what Proof of Concept is and how to do it, with tips and examples to guide you. Read on!  

How do you launch a successful product? 

Product success happens when the stars align, and you do the following: 

1. You locate a legitimate problem 
2. You find an effective solution to the problem
3. You convince investors and other stakeholders that you’re onto something good
4. You produce your solution and distribute it
5. You find an audience for your solution and grow your users. 

Even if you hit points one, two, and three, there’s no guarantee you’ll make it to step five. Sometimes great products fail to hit the right note amongst real people, despite the best plans. In the worst-case scenario, you convince yourself (and your investors) that you’ve hit points one and two, jump to four, and get proven wrong. Let’s call this ‘doing a Google Glass’. 

So how do you avoid the trap? While there’s no one concrete way to guarantee success, there are some sensible things to do that raise your chances of launching a hit.  One way to lower the risk factor is to run a proof of concept, or PoC for short. 

What is a Proof of Concept? (PoC)

A Proof of Concept is an experiment to check if an idea will actually work in the real world. Think of it as a trial run.

The focus isn’t on perfecting the final product or ironing out every detail. It’s about showing the concept has potential and can solve the problem you’re addressing. This early validation (or rejection) helps you decide if it’s worth moving forward with the full project. 

Before we get into the whys and hows of PoC, let’s quickly differentiate it from some other similar approaches. 

Proof of Concept vs. prototype

A Proof of Concept is a small test focused on proving a concept works. It’s focused on the core principles of the idea, usually without any kind of build.

Creating a prototype is just as important, but it’s all about visualizing how your invention will function in the real world. Unlike a PoC, a prototype involves building a rudimentary version of the thing/service and then testing it. These tests are focused on the look, feel, functionality, and user experience. This helps product teams spot design flaws and usability issues, which they can then fix before full-scale production.

Aspect	Proof of Concept (PoC)	Prototype
Purpose	Validate the feasibility of an idea	Refine design and functionality
Focus	Core principles and functionalities	User experience and overall design
Stage in Development	Early stage	After PoC, but before Minimum Viable Product development
Detail Level	Basic, focuses on concept validation	More detailed, focuses on design and usability, and involves a build
Goal	Demonstrate potential to solve the problem	Identify design flaws and usability issues
Outcome	Decision on whether to proceed with the project	Improved, user-friendly model of the final product

Proof of Concept vs. Minimum Viable Product (MVP) 

A Minimum Viable Product (MVP) is essentially one step on from the prototype. It includes the basic features necessary to solve the problem and meet the needs of early users and give them a better feel for what your product does. This helps you continue to validate your idea before dropping more funds into the experiment. 

Aspect	Proof of Concept (PoC)	Minimum Viable Product (MVP)
Purpose	Validate the feasibility of an idea	Deliver a functional product with basic features
Focus	Core principles and functionalities	User needs and market validation
Stage in Development	Early stage	After PoC and prototyping, before initial market release
Detail Level	Basic, focuses on concept validation	Functional, includes essential features
Goal	Demonstrate potential to solve the problem	Test product with real users, gather feedback
Outcome	Decision on whether to proceed with the project	Initial market entry, basis for further development

What are the benefits of a PoC?

PoCs help you test ideas and prove they’ve got potential before investing piles of cash into production. Here’s how they prove their value: 

• Technology validation: Software teams use PoCs to test whether they can successfully implement a particular technology or approach. This helps them identify technical hurdles early on before designing or rolling out something that won’t work.

• Market feasibility: PoCs can help product teams test market assumptions and gauge potential customer interest. It’s an important thing to know, because even the best designed creations fall flat if the market isn’t in the right place. For example, designing a luxury item for a market in recession isn’t a great idea — but for when people have cash to splash? Dive right in. 

• Stakeholder support: To secure investment, you need to prove your product won’t be a financial black hole. Showing a successful PoC can help you garner the support and confidence of various stakeholders, including investors, management, and clients. It gives them tangible evidence that the concept is a goer. 

• More Innovation: Creativity flourishes in low-risk environments. PoCs encourage experimentation because they’re essentially a safe space to try out new ideas and approaches. This can help build a culture of creativity within the team, leading to more ideas.

• Clearer project direction: By validating core functionalities and principles, a PoC works like car headlights, guiding the way ahead while helping you avoid ditches along the way. This is invaluable when it comes to refining your project’s scope and objectives, leading to a more focused development effort. 

• Risk mitigation: No project is risk-free, but by identifying issues early on, you can sidestep the avoidable. This lowers your chance of encountering any major red flags during the later development stages and pressing ahead with a costly flop. 

• Cost efficiency: Running a PoC is generally less costly than full-scale development. It also helps you make smarter choices about whether to proceed or not, thus saving you money in the long run. 

• Resource optimization: A PoC helps you distribute resources in a more efficient manner. This means less wastage on ideas that won’t work and focuses your efforts towards areas with promise. 

How long should the Proof of Concept stage last?

This all depends on the project scope and team size, but generally speaking, PoC should be short and sweet, lasting anywhere from between a few days to a few weeks. The goal is to keep it concise enough to validate the idea without sinking too much time and money into the endeavor. 

For simple projects, like testing a new feature in an app, a few days should do the trick. For something bigger and more complex — like Google Glass — you should be looking at weeks rather than days. 

What is the aim of a PoC?

• Clearly define the objectives: Work out exactly what you need to validate, then set specific, measurable (aka SMART) goals for the PoC. 

• Focus on the core functionalities: Concentrate on the most critical aspects of the concept that need validation.

• Stay within scope: Avoid expanding the PoC beyond its initial purpose. Keep it concise and targeted.

• Gather feedback and data: Use the PoC to collect valuable insights and feedback that will inform the next stages of development.

How to create a PoC

To get the most out of your PoC, take a logical approach. That way, you can guarantee you’re thoroughly testing your idea and leaving no stone unturned. 

1. Define your goals and objectives 

Start by setting out the customer problem you want to solve. To really focus your thoughts here, write it out like an elevator pitch. If you can’t sum it up within three sentences, then the chances are, your goal is lacking focus. 

What are you trying to prove? Is it the feasibility of some new tech, the market demand for a product, or the effectiveness of a new process? And an often overlooked part to consider: how will you measure success (or lack of)?

SMART goals should be your go-to here. Let’s say you’re testing a new tech feature. One of your goals might be: ‘Prove that the new algorithm can return results in under 0.5 seconds with 93% accuracy within two weeks.’

2. Identify the key stakeholders

Who has a legitimate interest in your creation? Sit down and work out who your stakeholders are  — both internal (developers, project managers, designers), external (clients, potential users). You’ll also want to pull out the key decision-makers (investors, senior management), all of whom will sit in the VIP section of your stakeholder list. 

Once you’ve penned a list, you’ll want to map them in order of importance. This’ll shape your communication strategy when it comes to pitching your idea and getting to grips with their expectations. Make sure there’s a clear communication plan to keep everyone informed throughout the PoC process. Assign roles and responsibilities, making sure every stakeholder knows their role in the project.

3. Outline the scope

Equally as important as defining who will be involved: Defining what will and what won’t be included. 

List all the key features/components you’ll need to develop and test. For example, if your PoC is for a new mobile app, the scope might include basic user authentication and a core feature like the main dashboard. It won’t include secondary features like notifications or user settings. By keeping the scope laser-sharp, you can focus on the essential aspects of your concept without getting bogged down by extra details.

4. Develop a plan

Next, create a detailed project plan that sets out each phase of the PoC, including timelines, milestones, and resources. Break the project up into smaller tasks and dish these out to team members with clear deadlines. 

Include a contingency plan to address risks and issues that may arise and make sure that your plan includes regular check-ins or progress reviews to keep the project running smoothly. 

Top tip: Use project management tools like Backlog to create interactive Gantt charts. These make it super easy to visualize the timeline and all your task dependencies from a bird’ s-eye view.

5. Build the PoC

Now it’s time to kick things up a gear. Begin developing your PoC, keeping a close eye on your plan and scope. Start with a design phase where you create mockups or wireframes if applicable. Then, move to the development phase, focusing on those core functionalities. Keep the development lean and Agile, and whatever you do, resist the temptation to overbuild. 

Review progress with the team and applicable stakeholders as you go to keep everyone on track. And if you need to sidestep from the plan, document any changes and communicate them with all involved. No-one likes surprises, especially stakeholders. 

6. Test and Validate

Now it’s time to put the ‘Proof’ in Proof-of-Concept! After the building phase comes the all-important testing phase. Develop a testing plan that includes various test cases and scenarios, including functional testing, performance testing, user acceptance testing, and so on. The more thorough you are, the better your evaluation. 

While you’re doing this, gather feedback from stakeholders and potential users by conducting demos or user testing sessions. Analyze the feedback and results to work out whether the PoC meets those all-important pre-defined objectives. 

Remember: Be prepared to iterate on the PoC. There’s no such thing as a bad result. If your PoC needs changes or is proven unviable, that’s a valuable lesson learned and money saved. 

7. Document and present findings

Gather all that data, feedback, and insights gained during the PoC phase and put it into a report to present back to everyone involved. This report should clearly explain the results and their implications for the project’s future. 

In terms of what to include, you’ll want an executive summary, findings, and recommendations for next steps. Highlight the key metrics and outcomes that demonstrate whether the PoC was a hit or not. 

To make it easy for everyone to understand at a glance, use clear, colorful visuals like charts and graphs to make your findings more accessible. Remember — not everyone will be as comfortable with the technical data as you, so you’ll want to make things as clear as possible. 

To finish it off, give recommendations based on the PoC outcomes, like moving forward with full-scale development, making specific improvements, or reconsidering the project’s future.

Proof of Concept examples

Proof of Concept is a truly versatile exercise, so let’s take a look at how it might take shape across four different domains: project management, software development, marketing, and product management

Marketing

Marketing teams use PoC to test ideas for advertising campaigns before making a bigger investment on a full-scale rollout. 

An example: A company might want to run a new series of TV ads targeting a specific demographic. First, the team conducts market research. Once they’ve worked out who their customers are, they’ll run focus groups or send out surveys as part of the PoC validation phase. The results will help the team validate their assumptions and determine whether the new strategy is good to run and worth scaling up.

Software development 

PoC helps product managers validate new ideas or features before they leap into the development phase. For example, if a company is considering adding a new voice-activated assistant to its mobile app, it might develop a PoC to test its feasibility. 

First, it would do in-depth market research to validate assumptions about its core users (for example, ‘they enjoy using phones hands-free’), as well as whether the product can meet core quality, cost, and functionality requirements. Next, the team will interview potential users, run a competitive landscape analysis, then put the results in a PoC document. It’ll then share this with stakeholders, and everyone will be better positioned to decide whether the project should get the green light. 

Project management 

PoC is ideal for helping project managers work out if an idea is doable. Let’s say a manager is thinking about setting up a new workflow automation system for their team. Rather than risk wasting everyone’s time with useless tech, the project team might conduct a PoC. 

This will involve shopping around, interviewing other companies that have used similar systems, and trying out existing tools on a small scale. The aim is to verify that the tech can meet the team’s requirements and improve efficiency across the company. 

Product management tools were made for PoC

Product management tools are like Swiss army knives when it comes to PoC, offering an array of features that make the whole launch and development process that little bit easier. With Backlog, our own platform, you can share files, set up milestones, assign tasks, test code, and leave comments — all from one place. And when it’s time to present your findings? No sweat: create reports and share them with stakeholders for complete transparency every step of the way. Ready to give it a try?