SANDBOX: PART 3. Building Successful POCs in Metron Sandbox


One of the main challenges in building a POC of an entire product concept is forming a crystal clear idea of what represents the core value proposition, and, more importantly, what does not. A common problem that many innovators and entrepreneurs have is that they find it agonizing to leave out even the tiniest part in a POC that is intended to highlight the key Minimum Value Proposition of the product.

Often, they want to cram the entire product development into just a few weeks. This especially becomes a challenge when they see a working POC materializing before their eyes. (We usually put up a reference instance on a server so they can have get visibility into the progress on a day to day basis) it is inevitable that you are tempted to start developing new wish lists based on something you saw on the net yesterday).

But avoid that at all costs! Have a very clear idea of what is the core value proposition you want to highlight to investors/decision makers and stick to it. These people are typically extremely savvy (or you shouldn’t be approaching them at all). You don’t need to pretty up the demo – they are looking through it. You don’t need to build stuff which is clearly commodity routine components. If there is any spare time in the precious few weeks of POC development, invest it in further improving the core value.

All this doesn’t mean that you have to just create an insipid, tired context-less wireframe as a POC. It does need all the various knick knacks which illustrate the flow, the usability that surrounds the core value proposition in a way that it fires the imagination. And there are ways to materialize all of this in just a few weeks with some judicious decisions and some creative technical ideas.

The process of this judicious scope planning is a very collaborative process between Metron and the client. In the initial planning phase we (our top technical management guys with potentially 50 years of combined technical product and startup experience) sit intensively with you in a role virtually like a co-founder and help sketch out how to make the POC give the maximum bang for the buck.

The same senior architects who worked intimately with you on features, scoping, and planning oversee the architecture of the POC (a POC needs an architecture?! Read Why). We design POCs in a slightly different approach that can cut down the effort of your subsequent product development effort tremendously, depending on the decisions you make.


In summary, the most important factors for success are:

  1. Having a clear idea of the MVP objectives of the POC
  2. Judicious decisions of what need to be fully fleshed and what doesn’t – we’ll give you lot of creative solutions on how mostly everything you want in the POC can be included
  3. Don’t waver, avoid changing scope or don’t suddenly decide you want an entire 6 month effort product build in a few weeks.

Be clear whether you are sandboxing a quick POC, or you are interested in launching development of the product itself. Calling a product development initiative as a POC does not mean it can be magically done in a few weeks. If it is an actual product development effort, we can do that for you too – but separately: not the promised POC in 6 weeks.

Leave a Reply

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