FUNDAMENTALS OF PRODUCT MANAGEMENT: THE PROCESSES
Prototyping: the essential component of product discovery
Prototypes are part of the philosophy of building things that don’t scale during product discovery. Prototypes are used to test information and workflows and gather user insights for value validation and risk mitigation. There are four major categories or use purposes of prototypes: 1) for feasibility testing, 2) for simulation, 3) for live-data gathering and testing, and 4) hybrid versions that combine features of the previous three categories.
The purpose of prototypes
All prototypes have certain characteristics and benefits in common. They include:
- Help the product learn something at a much lower cost that goes into building a fully functioning product. This cost-saving should be in the order of magnitude and meaningful. The right level of prototype fidelity will depend on the intended purpose and the complexity of the product and its intended audience
- Bring in data to help the team think rigorously and at substantially deeper levels — prototypes expose major issues that would be otherwise left uncovered until further into the product’s development lifecycle
- Improve team collaboration, by bringing members of the product team, customers, business partners, and senior executives to a shared understanding
- Tackle one or more product discovery risks: value, usability, feasibility, viability, and ethics
- Communicate what needs to be built, especially when the team is not collocated or the product is quite complex, the prototype can serve as specifications along with supplementary details
Prototypes for feasibility testing
While most often engineers will review product ideas and quickly provide little to no feasibility concerns, there will be times when they may identify significant risks including the following concerns and conditions:
- Algorithms
- Performance
- Scalability
- Fault tolerance and error handling
- Introduction of new technology
- Legacy system dependencies
- Dependency on other teams
- Use of a third-party component, API, or service
The idea with a feasibility prototype is to write just enough code to test for concerns and should be a small percentage of the total work for the shippable product. Most often, these prototypes are deemed as throw-away code, as it’s quick and dirty with no UI or error handling for example. Therefore, this is part of product discovery work and not product delivery.
Depending on the problem you are solving, feasibility-related prototypes can be made in a matter of days, or weeks such as when attempting to leverage ML technologies. If the relative cost of prototyping for feasibility testing is judged as large, the judgment call to pursue will be on the product manager.
Prototypes for simulation to users
User prototypes are simulations of the product with a UI but no backend. The detail of the UI can be high or low fidelity with simple mashups of interactive wireframes. Most often, low-fidelity mockups are used for brainstorming internally to contemplate information and workflows with little emphasis on the impact of design and visuals. However, high-fidelity prototypes are real-looking simulations that are trying to move toward a final product with an emphasis on gauging the quality of the final user experience. These simulation prototypes are most often throw-away or disposable simulations with little hard coding done.
One note to consider is that simulation prototypes are not good for proving anything including value validation or whether the product will sell or not. They will only be used for solution thinking, qualitative feedback on design, and gathering data to gauge behavior.
Live-data prototypes
At times, due to the risks mainly from value validation, limited live prototypes are used to collect user data to assess behavior and discover insights before the product idea is taken into development. Examples of this are abundantly found when growing user activity creates value such as with search results, P2P navigation systems, and content delivery algorithms on social networks.
These prototypes are substantially smaller than the eventual product and bear much lower quality in performance and functionality, but are cost-effective tools for assessing value risks. They run well enough to collect data for some very specific use cases and nothing concerning scalability, automated testing, or instrumentation. However, it does mean that you will need engineers for some coding and should not take more than one sprint to be delivered — if takes more, then you need to reconsider the scope of the prototype.
Hybrid prototypes
The last category of prototypes combines variations of previous ones such as the “Wizard of Oz” prototype that has a high-fidelity UI and a person on the backend performing manual operational tasks to deliver value such as a chatbot before automation.
Hybrid prototypes are not scalable and can not handle significant amounts of traffic, but can be created quickly and easily, while the user feels it’s a real functioning and behaving product.
Hope you enjoyed reading this article! :)
If so, then:
- Follow me on Medium
- Become a Medium Member
- Subscribe to hear more
- Let’s connect on LinkedIn
