Nuthin’ but a Prototype Thang

I was at a PM meetup recently and a lot of questions came up about prototyping. The questions were mostly about when you can and can’t use prototypes. The thing is, you should always be prototyping. Discovery is all about testing hypothesis using prototypes. Adding a new page to you application flow? Prototype it. Adding a store locator? Prototype it. Collecting a new data point? Prototype it. Want to add free tacos at checkout to increase conversions (sorry i’m hungry), prototype it. You get the point.

You should aim to have your tech lead or engineers looking at prototypes daily. I know that sounds hard, but just 30 minutes a day looking at a prototype can go a long way. The most expensive prototype is the one that the engineers build to cover every use case, takes a sprint or two and then gets pushed to production to be A/B tested. The point of a prototype is to learn fast and cheap, and if you already spent a sprint building something than it defeats the whole purpose. This is one example of what Paul Graham means when he says, “Build things that don’t scale”.

Now there are a few different types of prototypes you can use when you are in discovery.

1. Feasibility Prototypes
   • These are used to determine technical feasibility risks. Feasibility prototypes are typically created if engineers identify a risk with performance, algorithm, fault tolerance, scalability, new technology, legacy systems, or a third party. The code should be quick and dirty and intended to be thrown way, so don’t worry about UI or error handling.
   • A feasibility prototype will help mitigate against the risk of grossly underestimating or overestimating the amount of work that would need to occur.
2. User Prototypes
   • These are what most PMs are used to. User prototypes are usually wireframes made with software like Balsamiq, Sketch or Invision and come in two forms:
     • Low-Fidelity Prototypes which are used to gauge the information or the workflow. Low fidelity prototypes are wireframes sketched out on paper or using software like Balsamiq to create rough sketches.
     • High-Fidelity Prototypes are wireframes that look and feel like the real thing. They are interactive and the user will typically not be able to tell the difference. Often these are made with Sketch or InVision.
3. Live Data Prototypes
   • Used to collect actual data to see if we can prove a hypothesis or gather enough data to support one. Live data prototypes need to have access to live data sources and be able to send enough live traffic to test the hypothesis. The prototypes are typically used for work flows, new designs or features.
   • Some examples for use are for applying game dynamics, product funnel, or search result relevance. You will use a live data prototype to collect data on how the new approach performs.
4. Hybrid Prototypes
   • These are a combination of the above. An example of a hybrid prototype would be one that combines a high-fidelity user prototype, but having a live person taking care of back-end processes that would be automated in the shipped product. An example would be a lead gen application funnel, where the live data is collected from the user but then a person will manually submit the leads.

The important thing to remember for all these approaches is to keep it simple. Prototypes are intended to be thrown away, and not scaled. You don’t want to waste designers or engineers time building something that will be thrown out. These are justs tests to see if a hypothesis is valid. There is no point in building something flushed out that might not even see the light of day.

Happy Discovery! Time for me to get some tacos 🌮