6 (Latest) Tips To Help You Build An Effective Product Prototype

Creating a product prototype is one of the important processes while developing a software product. Not only that, but it can also be a challenging one.

What should you pack in? How much should you build? How can strategic roadmapping help? These are just some of the questions that come up while thinking about the prototyping stage.

As always, we’ve strived to bring to you a much better way to build a prototype if you’ve just engaged an app development company. This time, we spoke to 6 product managers to share their insights about effective prototype development that resonates with your goals and your audience.

#1 The prototype should answer the question about demand

David E. Weekly, senior product manager at Google

When you have an idea for a new technology that you’d like to make into a business, there are two classes of risk that must be addressed.

The first is technical risk: Can this thing be made at all (i.e. does it violate any laws of physics)? If you can make a prototype, can you make a production version at scale and with reasonable economics?

The second is business risk: If you build this thing, will anybody want it? Is the addressable market large enough to be interesting and is your strategy to enter the market sound? Will your acquisition costs and delivery costs overwhelm the revenue you’ll ever receive from a customer? How quickly does revenue come in from a customer versus when you have to undergo cost on a customer’s behalf? Do you have acquisition channels that can scale?

Finally, even when the produce has been de-risked from a business and technical perspective there is a further question of strategy: does this product give you a distinctive “perch” that enables you to observe trends others cannot and learn faster about a need than anyone else? Does it segue neatly into another class of products of demographics that provide an even larger market opportunity?

To get back now to answer your question of prototyping, it will depend on the product; if the underlying technology is not overly novel or complex (typical for most startups), then most of the risk is actually on the business side (building something nobody wants) and the purpose of the prototype should be to answer the question about demand.

A classic example of this is to do a Kickstarter, which can give you signal about the level of concrete interest the market has in your product at a given price point. Once the demand has been validated, the risk now is shifted back onto the technology side (can you actually deliver on your Kickstarter to an expected level of quality, at a cost that is profitable to you, and within reasonable time).

The classic extremely minimalist version of this is to of course offer ads for a product that doesn’t yet exist and see how many people click; the passive version of this is to observe failed searches (on Google or Amazon) to see what kind of products people wish existed, and then implement those. Finally, another way to operate with reduced business risk is to take a service or product that’s successful in one geography or demographic and bring it to market to another geography or demographic faster than the original party can.

On the other hand, if what is being demonstrated is deeply novel, the purpose of a prototype may be to convince an internal audience of the underlying technical viability of the approach – namely that it could work at all. This is often a gate to internal resources or venture capital and has the advantage of the device likely being patentable.

When it comes to website prototyping or mobile app prototyping, because it is fast and low risk to author software, I encourage people to tilt toward building live / simple versions of the product and iterating with real users instead of just doing mocks. Even with a trusted user base of only a few hundred people (the founding team’s friends and family) you can do some quick iterations on what resonates with people and then quickly ship it to more folks. Remember, if you’re proud of the first software you shipped, you probably took too long to ship. 😉

#2 Identify the ultimate purpose of the prototype

Anis Hoffman, senior manager & content creation at Idean

Before building a prototype, we have to consider the audience and identify the ultimate purpose of the prototype. The extent to which we prototype a product really depends on what we are specifically trying to accomplish with the prototype itself.

If the prototype is being used as part of a presentation to secure investors or sell a client on a new product, it may be more beneficial to focus on the look and feel of the product. In this case, the prototype that is highly polished and looks more like a “finished product” might spark the imagination of a business owner or investor more easily than a heavily functional prototype without a strong visual identity and appeal.

On the other hand, if the prototype is intended for an internal proof of concept or user validation testing for which certain interactions and flows are necessary to validate functionality, a team may find it more valuable to spend time on creating a visually low-fidelity but more functional prototype.

The ultimate goal for a prototype is that it is built as much as possible on target technology, demonstrates key functionality, interactions, and flows, and provides a strong visual identity and emotional connection with the user. If your prototype is successful at this level, you’re in great shape to validate the viability of your product.

#3 The correct prototyping is all about what you’re trying to learn

Simon King, design director at Ideo

From my perspective, the right kind of prototyping is all about what you’re trying to learn. Sometimes you prototype for yourself, building something to think through the problem in a more tangible way. Other times you prototype to learn something about people’s expectations and goals, where the thing you make is a research probe, designed to solicit understanding more than solve a problem.

The more common way to think about prototyping is in an evaluative sense, but even then I think there’s nuance in what you’re looking to learn that determines the appropriate form and fidelity. I like to break prototype fidelity in three components: visual, behavioral, and data fidelity.

You can combine these in different ways — for example, I’ve created prototypes with low visual fidelity but high data fidelity. The rough visuals made people feel that the design wasn’t locked, that they could still give input, but the high data fidelity meant that they could respond accurately to real information and determine if it was useful to them.

Deciding how refined the visuals or behavior should be is not just about saving time, but finding the right combination to get the kind of feedback you need.

#4 Prototype should be fast

Saptarshi Prakash, product designer at Directi Zeta

The whole point of prototyping is that it should be fast. Building a prototype shouldn’t take more than 1% of the time needed to build the actual feature /product. The purpose is, otherwise, lost.

A prototype can be built at different levels of refinement, from basic low-fidelity mock-ups to high-fidelity interactive visuals. To understand and finalize the flow, a low-fidelity box model built in marvel or InVision should be enough. But if you wish to use the prototype for user testing or presenting it to a potential investor, a high-fidelity prototype with complete flows (not necessarily functionality), resembling the real product is recommended.

There are prototyping tools like Principle in which a complete feature can be prototyped in less than 5 mins! The good news is, Principle can be learned and mastered within minutes.

#5 Keep the prototype simple

Sevket Arslan, product manager at emlakjet.com

“A simple prototype always talk better than words”

There are people who spend hours on creating prototypes that feel like real, and functional product but I am among those who believe that a prototype with basic functionality is adequate. Along with the UI UX design team, we try to get feedback from our users in the early stages of our product development process and iterate on the it with user feedback.

Spending weeks on a design, coding for its prototype and unfortunately getting negative feedback would make you lose weeks/months but incorporating the user continuously is the key to develop a great product. At Emlakjet, we use InVision for web and mobile prototyping, as I’ve said we’re constantly doing user tests on “simple” prototypes and I’ve never felt the need to create a feel-real prototype.

#6 Realize the core value of your product

John Valustik, UX/UI designer & product manager

Figure out the core value!

When thinking about MVP (minimum viable product) for your idea, the first step is to figure out why you actually do MVP. Do you want to get people excited and get momentum? Do you want to attract investors? Do you want to proof something is technically possible or do you want to start selling?

You have to know the value of your product and figure out what type of proof you need. There are many ways how to build a prototype to test your idea. You can create mockups and clickable prototypes in InVision, you can create paper prototype, you can record a video, or you can actually start building your product’s most important feature. For every idea there is a different approach how to test it.

It depends on what’s the core value of the product. Dropbox made a video of how it will work in the future and that was their MVP, it got people excited, gained momentum and helped the team to take off. Spotify actually built music player that was able to stream music without interruptions. They had to demonstrate it’s technically possible. There is no silver bullet, you have to know the value of your product and what proof you need.