Back to List

Proof-Of-Concept: Experiments with Short Feedback Cycles

Joe Vetta Joe Vetta  |  
Mar 03, 2017

Value and Risk

Technology is pervasive in life these days, and has been a critical part of business success since the industrial revolution. Not every project, however, is a guaranteed success story. You have to take on risk in the hope of achieving returns. But risk, as they say, is risky. 1 Such scenarios are the perfect chance for a proof-of-concept project.

It's crucial when experimenting to create value as quickly as possible to test the market. A market study or panel might tell you they love an idea, in concept, but consumers can't touch your idea. There must be something concrete, even if imperfect, with which the customer can interact.

A lack of perfect information is a human problem. It affects everyone without mercy. In fact, the hardest part of problem solving is understanding the problem well enough to be sure you're solving the correct problem. Your client and your software are all trying to solve a consumer's problem, but until a version of the solution is in the consumer's hands, there's always a risk that you've solved a non-existent problem, or at the very least a slightly different problem. Let's take a look at a few ways to reduce the risk associated with such experiments by getting to potential value as soon as possible.

None of the ideas below are wholly original, and some of them might be familiar to you already. These are simply ideas I have found valuable while experimenting on various projects.

Make It Work

Perhaps the most famous expression of this idea is Kent Beck, who is often attributed with the saying, "Make it work, make it right, make it fast.". [Cunningham 2014] His Mastering Programming post is full of gems, and I share it with every new developer I meet. However, the most memorable discussion of this concept that I have come across is Casey Muratori's post on Compression-oriented programming. [Muratori 2014] Casey's idea goes well beyond the simpler idea of making things work first, and I encourage folks to take a look at it. Even if you disagree, exposing yourself to different or conflicting ideas is another great tool to help when doing more creative and experimental projects.2

Use the above concepts to experiment and get a rough idea working as quickly as possible. However, do not expect someone to pay you to experiment for a week.

Seek Feedback

The goal is to turn an experiment into value as quickly as possible in order to mitigate the risk associated with a proof-of-concept project. I recommend trying to get something done and in front of the client in one day.

It's almost impossible to get an answer if you ask someone what they want, but if you show them something, it ignites their creativity. It's either way off base, or they start to see what's possible.

If the feedback requires more work than can be done in one day, that's fine. The important thing is to get something working and get it in front of the client so you can adjust course or confirm that you're on the right path.

Overcoming Analysis Paralysis

I first came across these ideas of compression-oriented programming and the "make it work" approach when at a point in my life where analysis paralysis had begun to ensnare me. No projects benefit from that, but a proof-of-concept project would be dead in the water with a design-up-front approach.

Being paralyzed at the beginning of a project comes from too much focus on trying to make it right, and a fear of it ever being "wrong." I'd argue that it's not even possible to make it right up front, especially on an experimental project. What does it even mean to be right? How can you start to make it work, if you don't know what "right" is? The client doesn't even know what "right" is yet, so you can't possibly know. Take a deep breath. Don't let the unknown create stress. Instead, let it free you.

I was recently watching "Abstract: The Art of Design" on Netflix. [Neville 2017] In the first episode, Christoph Neimann is covering his approach to illustration and mentions the Chuck Close quote, "Amateurs look for inspiration; the rest of us just get up and go to work." Christoph says about that:

The one thing I really love about that quote is it relieves you of a lot of pressure. It's not about waiting for hours for a moment when inspiration strikes. It's about showing up and getting started, and then something amazing happens, or it doesn't happen. All that matters is you enable the chance for something to happen.

This approach encourages failures and missteps instead of dwelling on them, and is the only way I know to move beyond a paralyzing fear of your project being just right.

Software Craftsmanship This Ain't

Proof-of-concepts are about producing value as quickly as possible and shortening the feedback loop. They are not about refining your TDD practice or tinkering with the latest framework or pattern. However, they do often involve working with some new, never-before-used technology. The key is focused learning. Figure out just enough to make something work and get it in front of the customer. Do not refine (make it right) or optimize (make it fast) until you have client feedback assuring you that you're on the right path.

Share your progress

Get feedback from everyone who will listen. It's not just about client feedback on the results, but colleague feedback the implementation as well. Put your efforts in front of your coworkers. In my experience, they're always happy to tell you they think you're wrong. But, be careful of the ones trying to derail you with the latest bells and whistle tech they saw on a blog once. You don't need it yet, and might not ever need it.

The project that inspired this post was launched to experiment with Azure Cognitive Services Bing Speech API, so there was no reconnaissance done with regard to other options. Sharing with a colleague pointed me in the direction of webkitSpeechRecognition, an up and coming specification that's actually crucial to the functioning of the project at this point. That's the kind of new technology worth exploring. Once it started working well, Azure's speech to text results went downhill, and Chrome's implementation of webkitSpeechRecognition saved the day.

Think Critically

It's as dangerous to focus too intently on the process surrounding the creation of something new as it is to take these tips as gospel. I encourage you to experiment with some of the ideas presented here on your next project. Seek feedback from client and colleagues alike. But, as with any piece of advice, think about it critically. Look at how these tips might help your project, and fit them in where they do. Take this advice like you would any individual piece of feedback from a friend or co-worker. Most importantly, do not let fear of the imperfect solution imprison you. Enable the chance for something incredible to happen.


1: I just made this up. No one says this, but you get the idea.
2: I am careful to say experimental when discussing this approach to software development, because some projects definitely require more rigor, but be sure that I am conflicted about it. There is definitely a relationship between these ideas and agile development processes, especially with regard to the lack of perfect information. As with any tips or advice, do not be afraid to use these tips, but always be mindful of their success or failure in your particular environment.


Cunningham, Ward. (November 27, 2014). Make It Work Make It Right Make It Fast. Retrieved from
Beck, Kent. (June 7, 2016). Mastering Programming. Retrieved from
Muratori, Casey. (May 28, 2014). Working on The Witness, Part 11. Retrieved from
Neville, Morgan (Director). (2017). [Christoph Neimann: Illustratrion] Abstract: The Art of Design New York, NY: Radical Media Retreived from


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
WinForms Fluid Design - A Cautionary Tale
Jeff LucasJeff Lucas  |  
May 01, 2018
As a developer, you can find yourself digging into all sorts of code, even the occasional WinForms application.  WinForms come with a lot of handy features that can make fluid design quite simple, allowing your forms to be resized by the user but still hold the basic shape you desire without...
Blog Article
Using SignalR Base Classes in Angular
Eric DitterEric Ditter  |  
Mar 06, 2018
On one of my previous projects I used SignalR extensively in an Angular 1.6 application, and I was using the angular-signalr-hub library to integrate it into the application. It worked very well, but I am moving to the next version of Angular so I wanted to find a way to do it without having to...
Blog Article
How to Use .NET Core CLI to Create a Multi-Project Solution
Ben BuhrBen Buhr  |  
Feb 20, 2018
.NET Core has been around for a while (over three years if you count the release candidates). Over that time, the framework and tooling around it has evolved rapidly. I remember starting work on a new ASP.NET Core website back when the framework was in its first release candidate. At that time...
Blog Article
The Many Powers of Redux Dev Tools
Jeremiah BillmannJeremiah Billmann  |  
Oct 12, 2017
This blog post is loosely based on a talk, “A Time Traveling Tale of Immutability and the Many Powers of Redux”, that I gave at That Conference this year.Redux is a predictable state container for JavaScript applications. “Predictable” being the key word here as Redux also...
Blog Article
How to Build Mobile Navigation for Desktop with only HTML and CSS
Melanie LenaghanMelanie Lenaghan  |  
Oct 10, 2017
Desktop website navigation comes in a variety of flavors, but you typically see it as a list of labels positioned horizontally across the top of the screen with sub labels that drop down on hover or click.    This type of navigation is what people are familiar and comfortable with...