It’s a long journey from ideation to having a working product that has prospective customers excited about it. It is no longer enough to have a great idea, one also needs to have a great way to communicate the idea – a process for learning and improving, while possessing the agility and foresight to recognize changes and execute them quickly.
To be successful in this lean startup world, an entrepreneur needs to have his ear to the ground and be able to openly and effectively communicate ideas. If the communication of an idea is not effective, then the idea itself is unable to generate any impact.
It is in this context that I am shedding some light on the necessity of building a prototype. By definition, a prototype allows one to test an idea, the assumptions behind the idea, and the understanding of the problem. Building a prototype helps one to figure out the right thing to build – something customers want and will pay for. As a result one need not spend months waiting for a product beta launch to change the start-ups’ direction. Instead, entrepreneurs can adapt their plans incrementally, inch by inch, minute by minute.
A prototype doesn’t need to be perfect, or be built to scale, but it should accurately translate one’s vision into something real and tangible. For products with longer development cycle, it can simply simulate the look and feel of the final product. Some of the important points to remember while building a prototype are – validating the customer need, the opportunity present, feasibility of developing the end-product, and demonstrating to the people around that the idea is implementable.
There are no rules as to how a prototype should be made. Infact it can be made on paper with sketches or paper prototypes in case of tangible products, while sketches of page flows or building wireframes would help if it’s a web services product. I would go a step further here and say that the uglier the prototype is, the better. The biggest problem facing the start-ups today is that instead of focusing on building quick and dirty prototypes companies are increasingly replacing it by polished ones and this is where all the trouble begins. While, with rapid prototyping one gets an outside perspective on the full merit of a solution; with an extremely detailed prototype, especially the one’s build early on in the development process cause a ‘ball and chain’ situation.
From my personal experience I have come to realize that something odd happens when people evaluate a clean and detailed prototype – they concentrate on the prototypes form and function. They end up ignoring the remaining ambiguities about the problems the product is supposed to solve or the obstacles in its way. Instead of throwing clarity on the path ahead, the prototype puts halt to the useful brainstorming. This is especially true with respect to technological products that are a bit complex in nature.
So the question now is how can start-ups avoid this pitfall? While thinking about plausible solutions, the one thing that stuck to me is that start-ups should try and retain the obscurity of the problem present and move on only after a consensus is reached on issues the product can solve and the ways in which it can solve it.
Let us for a moment go with the premise that rough ideas sell better than clean ones. I would justify the statement by saying that – when one shows someone a clean and polished idea there is very little for them to contribute. It becomes psychologically harder to give “negative” feedback on something that looks or appears to be a complete or a finished product. The key here is to include the prospective customers into the fold of product evaluation and make them feel a part of the process. Thus, people experiencing the idea for the first time will offer a different point of view–one that may help one’s project fail faster or lead one to the next creative breakthrough. In other words, since the outsiders don’t know how exactly the product is going to look, there is a scope for reinterpretation and in most cases this helps in the development and progress of the product.
An interesting case I would like to discuss here is that of Aardvark, a company subsequently acquired by Google for USD 50 Mn, developed a social search engine. The product enables users to ask questions, mainly subjective, that are then distributed to the social graph for users for answers.
The secret behind Aardvark’s success was acute awareness of how close they were to failure. Aardvark detailed a process of rapid idea rejection and extensive testing throughout its short startup history. The truth of the matter being that Aardavak founders had no idea what their product would be like or whether they would be able to build it. In order to find out, they got users to test-drive their ideas. For the first six months Aardvark prototyped ideas, gave them to 100-200 people, and if the ideas weren’t taking off, they abandoned those ideas. Once they figured out that social Q&A was their big ticket, they didn’t pull back on user testing, bringing in 6-12 users a week over the 30-month span of the startup.
Despite going through such an extensive testing phase, Aardvark didn’t actually build products right away. They continued to perfect the idea by using human intervention instead of automating their product right away, while the founders recruited its core team and raised $7.5 million. In fact, the founders claimed that it was easier to convince investors and prospective employees that Aardvark could figure out how to automate something that people were already using than to get people to use something new.
Once Aardvark felt it was on the right track, its next goal was to improve its ability to learn and engineer faster. The entire company — reviewed user testing and split testing for new features on a weekly basis. Aardvark also made sure that users and advisers alike knew their opinions were being heard and implemented. The lesson to learn here is that Aardvark tested its concept by building a series of minimum viable products (MVP), each designed to test a way of solving a customer problem. What became Aardvark was the sixth prototype that the team created which became a runaway success.
As a final note I would like to add here that, “consider doing 30 more sketches (more ideation is always better), building 1 more prototype, getting 1 more round of feedback and asking 5 more customers”. At the end of the day, the approach early on should not be trying to seek solutions but rather the issues the product needs to solve.
About The Author – Divya Sampath
Entrepreneurship is the last refuge of a trouble making individual. I consider myself a neophyte at entrepreneurship, someone who has had her tryst with the financial world and now is learning the ropes of business & management all in this lifetime.
