P.O.C is the new M.V.P

Spoiler alert: The blockchain tech is moving fast. Run P.O.C. Don't bother much about MVPs before you prove it works.

Blockchain networks, or 'the crypto ecosystem', is a market tremendously stimulating, both in terms of products offering and technological proposal. Should you aim for a market entry with an abundance of investment opportunities coupled to the promise of a privacy-focused yet transparent future social landscape, you may want to plug yourself into the blockchain innovation sector.

Let's propose that all public and systematised matters in human affairs shall eventually be traceable, transparent, and non-alterable. Some might call this an uber-efficient, decentralised "Bureaucracy 2.0" powered by technology. It could potentially be applied for everything from running elections and proving ownership of creative works, to monitoring stock market trades. To that end, 21st-century technocrats are bullying forward to harness and combine cutting-edge tech with innovative social processes to solve the biggest problems of our time. How cool would it be to be part of or even become founder of some of the largest ecosystems and tools that will run society, the economy, or the financial system?

On the other hand, in the business sector and for whatever entrepreneurs do, there are some general and historically-proven common denominators. One of them has always stuck around: 'who reaches the market first with an innovative idea usually creates, or predominantly owns that market. At least for a while'.

In the blockchain market, speed of execution, uncertainty of technological implementation, and proposal relevance in the wave of disruptive evolution creates the need to adapt quickly and constantly change in order to find the right product-market fit real fast for any potential project.

Let's take a step back. For an innovation team/individual, a conventional 0-to-million endeavour pipeline will process ideation like the following:

proof of concept (can this work?) → prototype (you like it and want to invest?) → minimal viable product (let’s launch, its customer ready) → consolidate, scale, iterate (growth phases).

That seems to work just fine in a conventional, stable business environment. But in the crypto space, the slow nature of the procedure may be inappropriate. For any project new-to, synching with, or exploring Web3, you probably want to course correct the application life cycle initiation process.

The question then becomes: what truly defines a POC?

Essentially, it’s the initial product development validation step. It then acts as an exercise to produce concrete evidence (code) to verify a design concept, product, or methodology (can be turned into an /is feasible/ practicality). Is the proposal applicable in a real situation? The outcome is naturally experimental, usually lacking scaffolding, but if the idea is unique, it stands tall. In a fast-evolving technological environment, we dare say it can act as a business or product proposal (we have written code for automation after all, right?!).

To clarify the intent, we’re not looking for market confirmation here, or how to choose the best production path. In a disruptive landscape, you want to crystallise ideas fast, assess proof of worth, identify potential risks, and get data before allocating more resources behind an untested hypothesis. Eventually, a successful POC output is code. It works, and blends in with the all-new-tech out there (needless to say with yet little auditing, best practices, or state of the art - cutting edge, investment strong tech ecosystems are generally less than 3 years old).

As a potentially helpful and simplistic analogy: you want to think of it as the first or second wave of gold miners arriving on the east coast of the US, which promised the much-demanded gold, with tremendous social impact, where colonial Europeans went for the land grab to build mining operations and the prospect of better lives.

The question for a project manager or investor becomes: how much operation is enough in the innovation race to secure a marketplace? With a thoughtful proposal, market insiders, seasoned engineers, and designers, the POC stands as a draft or even an early version of the final product. Why not make it act as a prototype and MVP altogether? That written piece of automation is valuable as long as no one else has reached the market with a similar proposal, while it’s still fresh and core structures it relies on are in place. In effect, bathing in an ecosystem that develops rapidly but is also risky (zero to something ratio is usually transcendental and mind-blowing), you have to pace yourself and consider the cost/opportunity ratio.

The main advantages the process seeks to offer are identifying implementation issues early on (practical discovery phase ++), and being able to weigh the cost of solutions. This offers one the superpower to make critical decisions right at the start, reducing any financial risks to end-nowhere-near-a-viable-market-proposal.

Note that the major drawback of this approach is twofold:

• the risk to give up on a project due to biased initial criteria, which may have been viable over the long term for a little more effort invested
• scalability issues → where you try to make things stand together fast, but lack the pipeline setup/culture to follow through to production or industrialization scales.

To break the latter down to a minimum of impact, should you successfully profile your audience, determine performance expectations and list all business needs, you may just have a winning idea. And repeat. Practice makes perfect.

What are the core criteria for a POC?

• takes up to, MAXIMUM OF, 1 week (and that’s for POC beginners!)
• clearly defined and outline criterias for success
• an evaluation piece of work (process feedback is of utmost importance)
• a proposal for how to move forward, should the POC prove successful.

Let’s outlay some general methodology to a POC procedure - the course:

• Initiate : Sit down with the team, analyse POC objectives, and draw a thin-air version of a business proposal from templated canvas - output document should contain some of the following headings:

  • POC Objectives
  • POC Expected results
  • POC Stakeholders and reviewers
  • POC Perimeters (target, tools, scope, research data necessary, time to process).
    

• Research: Search the market for, and gather all, material necessary for raw implementation. Note:

  1. It doesn’t have to be final, just good enough tooling
  2. Ideally with repetitions, a lot of the dev/prod tooling and pipeline will become familial, and plug-and-play, where you can solely focus on the core proposition.
     

• Race: Time to make it happen - this is where you run with the core dev/market team.

• Analysis: Breathe, evaluate the process journey, analyse process output vs early naive expectations.

• Conclusion: This is were you take a decision (eg. is it feasible, do time and effort justify the potential revenue streams?) etc.
  ** If ** (concretion | adoption): then iterate.
  ** Else ** (negation): move on to the next idea.

How about a simple practical case?

Near the end of 2021, we partnered with an entrepreneur to build an apparel-NFT-print company that seeks to allow any crypto-lover to display their ownership of unique artwork in social settings. FYI our sister company Whitesmith runs the Web2.0 customer facing application development, while we at Blocksmith enable the Web3.0 production capabilities.

The main idea was to connect customers' wallets, retrieve all current/owned NFTs, and ship to partner industries. Mind you, at the time, the NFT market was booming, but little to no NFT-processing APIs were yet available. The POC we had set to produce: the gathering of user owned NFT(s). The only way to do so: using standard web3 libraries.

We created scripts to gather user past/present NFT belongings, ie. effectively a full blockchain explorer for a target address, printed its NFT list, downloaded full res, worked out resolutions (NOT SIMPLE in early markets with no standard), process payment, and ship to the manufacturer. The initial explorer POC was executed in a few days, and it worked brilliantly. From there, we were able to help our partners secure core funding and see product launch. Now, the entrepreneur's original idea is a thriving business.

Note that just a few months later, the Alchemy team was to launch its NFT API toolkit in beta version. Then OpenSea ran the API race too shortly after, which allowed developers to simply provide an address and receive all its owned NFTs. And more of this kind of toolkit became available to the public. Hopefully this showcases what we mean by “race in the crypto-space”, “first-to-market”, or “build and publish it before it’s too late”?

What about the results for this early-day raw blockchain explorer? Well, we put a flag on the moon for the business. Several months later, the Alchemy NFT API is still one of the most widely used solutions for development teams to interact with the NFT market, and NFTees is THE platform where to print your crypto wearables. We mentioned earlier that PoC is all about understanding, measuring, mitigating, and ideally eliminating risk factors. In an ideal world, the PoC will prove that the technological risks or the viability risks are not really a risk at all. In that case, you can continue to the next steps in the product development cycle, stabilise project procedures, run and/or reinforce industrialisation, and secure market ownership.

Keep in mind – when working with disruptive innovations, we will always be at the leading edge of technology. Sometimes (dare to say often) the ideas are a step ahead of what is called “project-scoped viable achievables”. Your goal, as a project lead, is to find the equilibrium between market-production and research in the space.