Prototype for Feedback

As some of you may be aware our roots stem from an entrepreneurship course at the University of Ottawa, where we essentially validated Frank's idea with a commercialization game plan.  We then followed that up with a pretty successful crowdfunding campaign and an appearance on Dragon's Den -- all in about a year.  For these reasons we get a fair amount of questions from students and aspiring entrepreneurs like ourselves asking how we managed the above, and concurrently develop products for both e-comm and retail channels.  So, I decided to summarize our approach to the above in this month's post.

Wipebook prides itself on being a lean start-up.  Particularly when it comes to product development, which is not an easy task by any means. And although I am a registered project management professional, PMP, I am not a PMP evangelist per se: I like some components of this professional framework, as all projects and programs need a certain amount of structure in order to be successful; however, too much structure can be a significant impediment to the creative process and hinder overall productivity — you need a balance I guess.  

Product development, Wipebook style, employs a "pen to paper” — or correctable to Wipebook — approach for us.  We are proponents of the mantra that doing something is always better than doing nothing. We design iteratively, and in a way, are looking to fail fast and make mistakes to validate our design ideas as quickly as possible.  Some elements that we employ in the process are provided below:

STEP 1 - PROBLEM SOLUTION APPROACH

Every solution requires a clear and succinct definition of a problem.  How much pain does the problem cause, and how strongly is a solution needed? We ask questions such as: What problem needs solving? Then we consider the context of the solution? How much will it cost? How long will it take to build a minimal viable offering, MVP? Can we use off-the-self components in the design itself to expedite things?

STEP 2 - DO SOME RESEARCH

We ask ourselves: Is there a solution available? For example, we recommend looking at the United States Patent and Trademark Office registry, Google Patent, Google Scholar, and even Amazon. If you find something similar to what you have in mind as a potential solution to your defined problem, ask yourself the following: Does the existing design have flaws?  Can you do something cooler? Can you do this in a cost effective manner? Do off-the-shelf solutions already exist? Can aspects of existing solutions be improved upon? Do similar solutions exist in adjacent areas that you can borrow from? 

STEP 3 - BRAINSTORM AND CHOOSE A PROMISING SOLUTION

Generally we throw caution to the wind, and brainstorm potential solutions by "Wipebooking it out” while keeping design constraints in mind at all times.  We then compare the best ideas and select the most viable to prototype relatively quickly. Again, we are always thinking in terms of budget, time-line, and overall product efficacy.  

STEP 4 - RAPID PROTOTYPING and MVP

Prototypes are functioning versions of the solution. Our early MVPS are rough and unpolished; but they help to quickly verify a design by identifying its strengths and weaknesses from the customer’s perspective.  Yes, the customer’s perspective; in other words, we get our stuff out there in the real world as soon as possible. Often, our MVPs are built to test critical functions. Not every MVP will test every aspect of the perfect solution. In most cases MVPs require incremental progress; employing a small change with each subsequent iteration. In this way, the design continually evolves.

Step 5 - EVALUATE, MEASURE, and IMPROVE

Thinking of an operable MVP as part of the working solution is a valuable tool in the development process because you leave room for the critical mass to critique the design, which will subsequently allow you to improve future iterations of the product.  It is imperative that you are open to communications from early adopters; they will impart complications or gaps in the design that will challenge your ideas and hopefully make it better. Also, you need to establish a mechanism to measure success. And once the initial MVP is tested, and measured, get everyone together to think critically about feedback. For instance: Did your design allow customers to solve the problem you originally identified? Did it work well for them? What didn’t work at all? 

Hope the foregoing was useful to some of you. Remember, comments are always welcome.

Have a good one.