How to prove a proof of concept

Congratulations! You’re on the “FitShoes™” project. FitShoes™ will be like Fitbits^®, only because the chip is built into the shoe, they won’t interpret gesticulation as jogging a few miles. Even better, they’ll include GPS. They’ll keep track of the route … and therefore will know when the wearer is walking uphill and downhill so they can calculate exertion more accurately.

The theory is that while your company will make some money on the shoes themselves, it will make much more on the intelligence to be gained by knowing customer exercise patterns, both for direct marketing and from strategic intelligence gained from analytics performed on the pooled data.

How to proceed? The first step (NPI) is, of course, a proof of concept. There’s no point pouring R&D dollars into a product like this if the concept doesn’t hold up to the sturm und drang of life here on earth.

So the company forms a cross-functional team, and, recognizing that throwing money at a problem rarely solves anything, keeps its budget lean, letting everyone know that if the initial proof of concept yields promising results, additional funds will be forthcoming.

Armed with a deep understanding of the vision plus a modest budget to play with, the team designs the pilot. They agree that this early in the game, with detailed requirements still to be learned, they’ll use Excel for the database and processing.

The other key agreement: Creating a chip/circuit board to power a prototype FitShoe™ would be far too expensive and time-consuming. Instead, volunteers will keep track of their movements using a smartphone-based spreadsheet template they email to the project team every day for a month.

And …

This “proof” of concept will prove nothing at all. But it resembles many of the so-called proofs of concept I’ve seen over the years. It tests the least-challenging dimensions of an idea, leaving the hard stuff for the actual implementation when there’s enough time and budget.

Also when it’s too late to change direction.

To avoid this trap:

• Be clear about what concept you’re proving. Or concepts. In our FitShoe™ example, the only concept being proved is that data sent from elsewhere can be used to update a database.

• Know when more than one concept must be proved. The FitShoe™ depends on several of them: (1) It’s possible to put that much functionality on a chip or small circuit board; (2) that when you do it will be durable enough to withstand the pounding when someone exercises in the shoes; (3) people who wear gesticulation-foolable exercise monitors want more accurate exertion data; and (4) there’s enough to be learned from those who do to warrant the investment.

• Test concepts independently. If you try to build a scale model that incorporates every key aspect of whatever it is you’re developing, you’ll save a lot of time.

If, that is, everything works according to the initial vision. If it doesn’t, figuring out which concepts are sound and which ones aren’t is a lot harder when they’re all jumbled together.

Prove each concept separately first. Then assemble a working prototype.

• Test the complexity. In IT, unlike product development, proofs of concept usually revolve around the applicability of some already-proven technology or other to one or more business processes or business process cases. The temptation, parallel to the FitShoe™ parable, is to start with the simplest case on the grounds that this will be the least expensive pilot project, and the one most likely to be successful.

Except that with proofs of concept, “success” means learning something important about what actual use will be like. Just building something that works by avoiding all the nastiness the final product will have to deal with means that when you’ve finished you won’t have learned anything at all.

• Don’t create an incentive for success. The FitShoe™ project team’s incentive was a more generous budget for the next phase. Bad idea: It’s another version of defining success as building something that works rather than learning something important about what building the final product will take.

In any proof of concept there’s already too much of an incentive, in the form of political pressure. Someone’s name is on this; in too many companies that means if it doesn’t work their name will be on something that’s considered a failure.

Which means that as is the case throughout the world of business leadership, incentives and “holding people accountable,” are just about the worst choices you can make. True success requires, not these, but a culture of honest inquiry instead.

Without this, proof and “proof” will have nothing at all in common.