How do you define a PoC?

Sometime it can be really hard to structure a Proof of Concept. To acknowledge the time for implementation, to define the goals or the learnings we want to reach by the end of the implementation are often difficulties. So a PoC must have a clear,  small and reachable scope within the upon agreed small period of time. This post is all about the logic I follow to support my decisions to structure a PoC.

First case: Assuming that we are starting a brand new product

Everything starts by a vision, a strategy, a concept and a list of desirable features, which are the ones enabling the user for the main product features. This is what we call Minimum Viable Product.
From where should we start defining the need for a PoC?

  • In your MVP, start by writing your Epics;
  • Your EPICs will describe your features;
  • Now think about which ones are your key features. A key feature can be defined by the ones bringing more value into your product, or more value to your customer (it’s up to the project/ product nature). So now you know which ones are the most Business relevant.
  • Now you should analyze from those key features (or critical features), which type of complexity can you identify for the Implementation phase?
    • Is it a complexity in terms of Concept, User experience (conceptual or design complexity)?
    • Is it a complexity in terms of how to implement it (Technical complexity)?

Often both complexity types are present in the same feature: conceptual and technical.

Second Case: Considering a PoC for a released product. What really changes in the approach described before?

Actually, nothing very relevant, usually you will be considering the development of a PoC for a new particular feature. So you just need to evaluate which type of complexity we will be evaluating, and which results are we interested to learn, which hypothesis we will be testing.
The challenge here may be how to integrate the new feature in the present product navigation map or how to accommodate it in the solution design perspective.
Now you know which features will make part of your PoC. Time to think about how to evaluate it! For that, I recommend you to read this post: How can we evaluate results from a PoC?

One Reply to “How do you define a PoC?”

Leave a Reply

Your email address will not be published. Required fields are marked *