© 2019 SourceMedia. All rights reserved.

Want to build a successful product? Prototype, first

Imagine a product team is creating a pet-tracking product called PetEye. PetEye will monitor your pet and help ensure that they are happy and healthy. The team did its due diligence and surveyed pet owners to see if they would like a way of knowing how their pets were doing in real time. The team received overwhelmingly positive responses, and hundreds of people expressed interest in the first available product.

After four months of development, the team creates an end-to-end monitoring platform where pet owners place in their homes a specialized camera to detect a pet’s activity (even when the pet is in a different room!). The platform comes with its own mobile app that allows the owner to log in any time and check in on their pet. Product testing returns favorable results, and the team takes PetEye to market.

Unfortunately, platform adoption is underwhelming. As it turns out, pet owners don’t want to place cameras in their home because of privacy concerns.

So, what happened? The team did a good job surveying the market and found that there was a demand for the PetEye concept. However, without building prototypes and validating the solution, the team ended up with a product that did not align with the needs or desires of its target audience. Had the team decided to develop a simple prototype first, it would have learned that an in-home camera was not a desirable product base and changed its approach accordingly.

Prototypes = Learning Moments

Rather than jump immediately into product development, as the PetEye team did, development teams should instead first build a prototype. Prototyping is a crucial step for creating high-quality products or features. But plenty of organizations choose not to prototype in favor of simply doing what they believe is best or attempting to be first to market. The problem with those approaches is that they often lead to products that don’t address customer pain points or are built around unwanted features, like an in-home camera for pet monitoring.

No matter the outcome, the exercise of prototyping is always valuable and typically generates actionable insights that improve the final product or feature. To help companies that would like to develop sound prototyping practices, I’ll walk through the whys and hows of the process.

Develop a Hypothesis and Test It

Before building a product prototype, teams should develop a hypothesis or hypotheses about what problems they think their product or feature will solve. The goal of prototyping is to validate each hypothesis and assess the value of dedicating real resources toward the development of a fully baked product.

Rather than spending time trying to guess what people want and don’t want, the easiest way is to throw a rough version together and test it. More often than not, you’ll learn more about the product through feedback than you will from sitting in a room trying to perfect it.

Software-development-manager.png

The key takeaway here is that prototyping should take a fraction of the effort as a full product or feature to build, and the prototype should also illustrate a clear case for additional resources and development.

The Wizard of Oz and Goal Identification

The best way to frame a prototype is to understand the fundamental goals of the end product, based on your hypotheses, and then work backward.

  • It’s typically helpful to start with the primary call to action of the new product:
  • What is the major benefit your product will deliver that existing products on the market don’t deliver?
  • Is this a completely new product that customers will have to learn how to use? If so, how difficult will it be to learn how to use the product, and will that learning curve hinder adoption?
  • Is your goal to improve upon an existing product and if so how will you convince potential users to switch from the existing product to yours?

The purpose of the prototype is to answer these questions and make it very clear to yourself and your target audience that what you are building does indeed warrant production. In this sense, a prototype doesn’t necessarily mean building something that actually works. Instead, developers should attempt to simulate the user experience of the final product.

Teams can build prototypes through what’s known as the Wizard of Oz technique, something taught to software developers. Rather than build complex systems to create the full user experience, we can instead fake the interactions by hard-coding scenarios or having a human pretend to be a computer (the wizard, in other words). This will give the end user a rough idea of what the final system might look like without the overhead of developing large and complex systems.

Your team might build a prototype to test a new form of human-computer interaction. In that case, you’d want to simulate the exact interaction you’d like to create and understand how users respond. For example: Will users react unfavorably if you present them a product where the primary interaction is through an in-home camera?

Or, if you are trying to create a new workflow, instead of building a full system that handles complex use cases, start with a paper prototype and have a small group of people test out your hypothesis. You may find that existing products on the market already cover the use case you are targeting, or you may find that there is a much larger opportunity than you initially imagined.

After going through the Wizard of Oz versioning process, the development team should have an understanding of how users might adopt this new platform. This understanding will help determine whether or not it’s worth spending six months building a more fully featured product and improves the likelihood a final product will succeed.

While there is no hard-set way of building a prototype, there are fundamental principles that we can stick to to ensure we are making the most of our efforts:

  • Have an understanding of the final product and use that to guide your process along the way.
  • Once there is an end goal, figure out as many unknowns as you can before allocating resources toward building a final product.
  • Break down the unknowns into small pieces and spend the minimal effort required to answer whether or not your solution may be the right one.

Balance User Feedback With Product Roadmap

When you build prototypes, your goal should be to validate assumptions you’re making about the final product. Whether it’s building a brand new product, creating a new feature, or even making incremental updates to an existing product, you want to minimize any risk associated with dedicating valuable resources to an initiative.

The best way to get usable feedback is to put your prototypes in front of real users. Presumably, if you’re building a product, there is a particular group of people you are targeting as the primary audience. This group might include smartphone users, the population of a specific region, a particular age group, or even a type of enterprise. Knowing who your “power” users may be will allow you to get to know them and develop your prototype to properly serve those users.

Once you know who will be using the end product, including them periodically throughout the development process will help ensure that what you are developing does indeed solve their problems. In some cases, this is done through a formal process with strategic partners or sponsored users. These are people who will likely use the final product and have agreed to become a part of the development process to provide structured feedback. It is common in this case to offer these individuals some benefits such as early access to a beta product or even discounted rates on the final product.

The goal of having these sponsored users is to loop them in over the course of ideation, prototyping, and design iterations and understand how you can best solve their problems and make sure that the products and features you create are directly catering to their needs. This will eliminate a lot of guesswork that could cause the project to stray from the ideal solution. With sponsored users, you can learn a lot about your potential target audiences and clarify unknowns you may have about the way end users will adopt a product.

While you gather feedback from these various groups of potential end users, keep in mind that the development team should find a healthy balance of incorporating user requests with the planned roadmap. The prototyping process is always iterative and keeping a pulse on the market as well as internal goals is the most likely way to realize an optimal outcome.

Prototyping Offers an Ideal Testing Ground

Our hypothetical PetEye example is an all-too-real occurrence when companies try to jump from ideation straight to final product development. Without testing features and building iteratively, companies risk creating products or features that don’t address real user needs or don’t provide a viable alternative to existing products.

While it may seem tedious, the process of working step-by-step to build and test different concepts is crucial to the success of a fully fledged product. Prototyping presents companies the ideal way to work toward their ultimate goal without investing the resources and time a full product rollout would require.

The next time your team begins its product-development process, remind them that prototyping is sure to save a lot of headaches in the long run.

For reprint and licensing requests for this article, click here.