A Proof of Concept (POC) focuses on the technical aspects of a proposed product and tests the idea to ensure that it’s feasible. At Stoplight, we use POCs frequently, both to validate proposed product ideas, but also to show customers how Stoplight could work for their business needs.
They can be useful tools to improve your entire development cycle. So here’s some advice on how to determine when you need a Proof of Concept, what to look for, and how to be successful.
When should you consider a proof of concept?
There are a few reasons why you might consider standing up a POC. One reason is to help show that a big, new idea is actually feasible for your business before you spend time and energy developing it. In that way, a POC is a crucial part of the design process.
Another reason might be if your project comes with a lot of uncertainty and unanswered questions about the technical implementation. There’s always something that you don’t think of until you’re actually a little farther along.
So as much as you can try and plan out your project on paper, it’s nice to be able to validate that certain capabilities exist before heading down the road of official development.
Establish goals for your POC.
The most important thing about a POC is deciding what the takeaway needs to be before you start. What are you trying to prove? And once you’ve proved that specific outcome, then you need to stop working on the POC because otherwise you’ll just develop and develop and add more and more.
Always ask someone else if the goal and the scope could be simpler. Very often, you already have some implementation ideas or feature designs in your head, and it’s almost always more complex than the minimum viable proof of concept. Communicate and trust your teammates to give you that honest feedback.
So it’s important to have a clear, attainable goal at the end of the POC to prevent code creep; don’t worry about trying to make it nicer. That’s what the development process is for.
Using a proof of concept for Style Guide Projects.
A recent example of a POC at Stoplight was for Style Guides projects. This feature relied heavily on Spectral, our open-source linting tool, in order to create and share custom rulesets across projects in the Stoplight Platform. In this case, our team needed to be able to bundle custom functions into a JavaScript style guide and then be able to extend that from another style guide.
Because we’d never tried this functionality with Spectral before, a POC allowed us to see what was possible. And once we were able to see it in action, we were able to provide a better estimate of how long it would take to develop; if you haven’t done something similar before, a delivery estimate without a POC can really be a shot in the dark.
Of course, the POC will be rough around the edges and it will not be usable by users or perhaps even anybody except the person who wrote the code. However, it’s a fast, inexpensive, and low-risk way to anticipate future problems.
What are the benefits of a proof of concept?
A POC serves as risk mitigation to prevent neverending implementation or neverending engineering that happens far too often because you didn’t really know what to expect.
It can help with estimating the end date for the project with a higher degree of confidence because the POC helps point out any stickiness or problems beforehand.
Another benefit is that a POC results in better code. When you analyze the problems and write up issues from your POC in order to fix them, it can help cut down on documentation and peer review during the actual development process.
Gain a better understanding of what can be done.
Whenever you do something you haven’t done before, you can end up with lots of unexpected learnings that can influence other aspects of the team and project management, and technology stack. You just need to keep your eyes open for ways to apply or teach your learnings across the organization.
Curious to learn more about Style Guides? Check out what makes this new feature great.
