Is it possible? Can it be done?
These are the questions we find ourselves asking every day. With each new advancement in technology, the possibilities are growing. Each iteration sparks a new idea, and new business or technical challenge. Oftentimes, if these ideas can be implemented, they are game-changing, industry-shaking. But how do you know if something is possible? How do you start to answer your questions? How do you prove to your company that there is value in investing? To solve this we will show you how to build a proof of technology.
How to build a proof of technology
Providing proof of technology or proof of concept is a compelling way to make an argument for change — something tangible that not only proves if it is or is not possible but, when applied, has business value. Our Proof of Technology Engagements take your wild idea and match it with today’s technology to explore and create the beginnings of something great. Using a tried-and-true eight-week exploratory and iterative process, we’ll work together to find out if your idea is possible.
In this guide, we will show you how to build a proof of technology and how to navigate the process with a partner taking some of the mystery out of… well… the (for the time being) unknown:
Proof of Technology Defined
A proof of technology is a small project that tests whether an idea about technology is viable.
An initial version of a final product, brought to market to get feedback.
A working model of several aspects of a product.
There are a few terms that can get mixed up with each other because there are a lot of similarities, but we’d like to define what proofs of technology are and how to build a proof of technology. Equally as important, we’d like to define what they are not, to make sure we all start with the same expectations.
Proof of technology (POT) is a small project that tests whether an idea about technology is viable. It is introductory research that can save time and money, providing you with actionable data to make an argument for change.
A Minimum Viable Product (MVP) is an initial version of a final product, brought to market to get feedback so that continuous improvement can happen based on real-world data.
Like a POT, a prototype tests out an idea to see if it’s viable, but it is a working model of several aspects of a product/program/service.
The first thing we need to start a proof of concept is an idea. Your idea. That thought which started as just a spark and has consumed you. What is it? How do you envision it working? If possible, how does it change your company, your industry?
An idea can be difficult to communicate, which makes it hard to get the buy-in you need to move forward. Depending on your company culture and structure, “innovation” gets more and more difficult as time-tested, predictable ways are comfortable, safe, and provide steady revenue. A proof of technology lowers financial risk, allowing you to take an honest look at your business and where an innovative idea like yours could fit before fully committing to building out a potentially risky product. We took some of our learnings from Design Sprints to take an honest look at your business and find where an innovative idea like yours could fit. Here’s how we work with you to take this big idea and get focused.
How to Quickly Get Focused on the Right Idea
To make sure we’re considering necessary stakeholders and educating ourselves about the landscape, we run through a few exercises together: Expert interviews and “How Might We…” Expert interviews ask the opinion of you/your team/department/company “experts” — or the people who actively live in this work every day — and follow up by asking, “How might we do that?” While it may sound strange, it actually helps frame problems in a positive, actionable, and constructive way.
Before we go too far down any road, it’s important that we consult the experts. We’re looking to get a better view of the current situation, better understand roadblocks, and what kind of goals they have to keep top of mind.
- Tell us about your industry
- Tell us about the technical challenges that you face
- What is the product in its simplest form?
- What problem does your idea solve?
- If perfect, what would the product look like in two years?
- What are the philosophical goals for this increment of work?
- And any questions that shoot off of answers to help clarify any information uncovered
HMW (How might we…)
The second part of the expert interviews involves a bit of diligent note-taking and a bit of answering a question with a question. Instead of bulleted lists, our notes, taken on Post-its, will be in the form of “How might we [insert interesting challenge mentioned here]?”
- During each interview, we will create a ton of HMW Post-its and display all of them in their raw form at the end
- Our facilitator will help guide this process along by identifying top-level categories and patterns
- The group will help categorize them and move them around
- Everything then comes to a vote:
- Everyone gets two votes (we use dot stickers)
- Decider (previously chosen) gets four vote dots
The desired outcome of this exercise is surprising.
The goal is not to focus on exactly how we will solve the problem with specific features and functionality. The goal of this exercise is to allow your team and the Proof of Technology team to explore the actual problem that needs to be addressed so that various avenues toward the solution open, leading to discussion and evolution.
We’re looking to identify motivations and loosen the narrow focus on solving a problem with a specific technology. Less of “I want feature X” and more of “I want constraint X to be satisfied” or “I want users to be able to achieve this goal.”
Understanding the business value will help your idea to evolve as we learn more together, uncovering what does and does not satisfy a given criterion. Each step will be presented with technical challenges, some that can be overcome and some that turn into roadblocks. The business value will guide us around roadblocks, allowing pivots where needed.
Where to begin, where to begin? This is always the hardest part. How do you get started? It is very easy to get analysis paralysis at this stage. Looking at a problem or challenge in its entirety can be overwhelming and, quite frankly, a bit scary.
Think of this as the unpacking stage of a proof of technology: like a new LEGO set, we are ripping open the box, carefully opening each individual package, and seeing what pieces are available for our masterpiece. This is the beginning of our first hypothesis — our first way of bringing your idea to life.
We chart our course and we are off:
- List our assumptions — How do we think it could work?
- How will we measure success?
- What are our existing constraints?
- We break down needed components and see if they exist
To get a peek as to what this process is like on the technical side, check out how developer Terry May breaks down a problem to discover what is possible.
We know there are always many ways to create an outcome. However, If we are going to test whether an idea about a product is viable, the feedback loop needs to be small. Using the business value as our compass, we are going to prove that some technology works and some just does not — and at this point, that’s exactly what we need to know.
After assumptions are voiced, constraints defined, and the initial technical set-up is done, we have charted our first course and are well on our voyage. The word “first” is very intentional. Our first idea will not be our last idea and will likely not be the ultimate solution. We work together in an iterative process implementing, testing, documenting, and evaluating. Each iteration is used as a learning step along the way to inform the next.
How to be successful on an iterative project
In the iterative proof of technology process, there is a rapid and frequent demo cycle which not everyone is used to. In our experience, these two habits set teams, both client and candidate, up for success:
Informed decision makers
During project demos, it’s important to have someone who is well-versed in the business side as well as the technical side of your company. The iteration loop is so tight that a delay of a few days can really offset a schedule and putting our project in the hands of someone who knows the project and knows what we’re talking about is crucial.
Your feedback becomes our guiding principle, so giving specific feedback, contextualized within the limitations, is critical. To be more specific, consider the “feeling” or the experience. If your product is meant to simulate something in real life, does it “feel” like it? If not, how could changes make it so? If we discuss possible compromises to work past given constraints, what compromises can we live with and what is set in stone? Hearing your thought process is also helpful as we progress.
The conclusion can be both exciting and bittersweet. One of three potential outcomes may occur:
- The first, we use that first hypothesis with some minor alterations along the way and build the foundation of your big idea with a clear path toward accomplishing your business value.
- The next potential outcome will result in the defined business value, but through a series of iterations and pivots may be accomplished using a radically different technology approach compared to where we began.
- In the event that readily available technology does not allow for your idea to be built yet, we work together to document everything and prepare for the future. This is the third possibility and bittersweet outcome. Bitter because your idea is not possible today, but sweet because we have identified the potential missing piece and have done so before spending millions on research and development.