4 Tips for a Successful POC

Creating and implementing proof of concepts (POCs) are a common way to do just that… prove out a concept. Many large companies innovate this way - dedicating a small number of (protected) resources to prove if an innovative idea is likely to be successful.

As a product manager, you may be tasked with a POC at some point in your career. Managing a POC is a little different than building out a full-fledge product, and is also very different than enhancing an existing product that’s already in production.

While every POC is different, here are 4 tips for making your POC a success as a product manager.


1 - Get very specific goals from your stakeholders

The goal of the POC may or may not originate in solving a specific customer problem. The POC might be driven by other business goals, a potential partnership, or proving an idea wrong. What does ‘success’ look like? Is it to rule out a potential partner, is it to assess if a technology is right for the use case at hand?

It may sound obvious, but make sure you understand leadership’s desired outcome of the POC, document it, and get written agreement.

2 - Keep the guest list limited

POCs often generate a lot of interest from people wanting to get involved. While intentions are usually good, you may want to limit the guest list - the more people involved, the longer meetings drag on, and the more opinions are involved. Communication can become unruly, which can impede the speed at which you need to move.

Make sure you have a core list of invitees and that each have a very specific role and ownership. Otherwise, you could end up with too many people at an unruly party.

3 - Keep process to a minimum

The hardest part about a POC if that you have a definite end-goal, but many risks and unknowns. (That’s the whole point of a POC in the first place!)

Set milestones and checkpoints as you can, but when running a POC you may need to get comfortable with semi-organized chaos. While your end-goal is documented, you’re figuring out how to get there as you go. Attempting to document a fully fleshed-out PRD and epics and user stories could distract you from the ultimate goal of producing a functioning piece of software.

4 - Evangelize the end goal

Every POC has a very different end-goal, so you’ve got to evangelize what the goal actually is, when it will happen, and contain scope-creep as much as you can. Everyone will want to add their goals to the mix, so make sure to set a story, evangelize the story, and stick to the story.

  • “We plan to have a functioning app at the end of October that will prove x.”

  • “In collaboration with Partner X, we will build out x functionality by November so that we can present at X Conference.”

  • “We will integrate this POC with X platform by December.”