Lessons on Prototyping for Early Entrepreneurs and Startups

Note: All “products” mentioned in this text refer to “Internet products.” The information provided here is applicable to a wide variety of industries despite the differences in implementation.



To create such a prototype, your startup needs to have a standard team structure, which includes a business manager, product manager, development engineer, and a user interface (UI) designer. In the early stages of your startup, it might be more feasible to have your employees filling multiple roles.

After developing a team structure, follow these simple steps to build a prototype:

  1. Design product sketches and workflows as led by the business manager and product manager based on product and audience research.
  2. Plan internal brainstorming sessions, perform external research, and adjust the product sketches and workflows accordingly.
  3. Present a design drawing as led by the designer based on product sketch and workflow.
  4. Plan internal brainstorming sessions, perform external research, and adjust the design drawing accordingly.
  5. Assess technical difficulties, make schedules, and begin development as led by the product manager and development engineer.
  6. Release the beta version, collect user feedback, and implement iterative improvements.
  7. Repeat from Step 1 as the product is evolving.

Undoubtedly, problems will arise when performing these seemingly easy steps. For a successful prototype development, your startup needs to anticipate and be able to resolve these problems.

The author, a newcomer in this field, does not have all the solutions to the many problems of running a startup. However, based on the author’s experience, these are some of the possible pitfalls startups should be aware of, and the appropriate responses to minimize their impacts.

Pitfall 1: Narrow Scope of the Product

After six months, the author and his team successfully developed an app and started looking for potential investors. However, this turned out to be a series of failures.

Their most memorable experience was the conversation with Morningside Venture Capital’s partner, Liu Qin. Although Liu Qin showed interest in their project, they failed to provide satisfactory answers to questions pertaining the business model and closed-loop system. Consequently, Morningside Venture Capital did not invest in their app.

Now, one and a half years later, the team realized that the rejection had nothing to do with inadequate preparation or a limited target market. It was more about the narrow project scope; the investor’s product definition was not the same as theirs. The conversation with the investor helped the team see the bigger picture, allowing them to test new ideas on the product.

The takeaway from this story is to widen the definition of your product and adapt to market requirements. In the Internet era, a complete product includes a solution, business model, closed-loop system, and many other factors. The development of a single app is only a specific part of the solution and a small part of the product.

Pitfall 2: Excessive Passion for Automation

Feasibility testing focuses on just solving the problem irrespective of its efficiency and quality. Upon verifying the feasibility, you can work towards complete automation as permitted by your resources. This allows you to find an optimal solution achieved through a combination of machine and manual operations, utilizing limited resources and fulfilling your goals.

The below example is a story about PayPal, excerpted from Chapter 12 Man and Machine, from Zero to One by Peter Thiel.

“Complementarity between computers and humans isn’t just a macro-scale fact. It’s also the path to building a great business. I came to understand this from my experience at PayPal. In mid-2000, we had survived the dot-com crash and we were growing fast, but we faced one huge problem: we were losing upwards of $10 million to credit card fraud every month. Since we were processing hundreds or even thousands of transactions per minute, we couldn’t possibly review each one — no human quality control team could work that fast.

So we did what any group of engineers would do: we tried to automate a solution. First, Max Levchin assembled an elite team of mathematicians to study the fraudulent transfers in detail. Then we took what we learned and wrote software to automatically identify and cancel bogus transactions in real time. But it quickly became clear that this approach wouldn’t work either: after an hour or two, the thieves would catch on and change their tactics. We were dealing with an adaptive enemy, and our software couldn’t adapt in response.

The fraudsters’ adaptive evasions fooled our automatic detection algorithms, but we found that they didn’t fool our human analysts as easily. So Max and his engineers rewrote the software to take a hybrid approach: the computer would flag the most suspicious transactions on a well-designed user interface, and human operators would make the final judgment as to their legitimacy. Thanks to this hybrid system — we named it “Igor,” after the Russian fraudster who bragged that we’d never be able to stop him — we turned our first quarterly profit in the first quarter of 2002 (as opposed to a quarterly loss of $29.3 million one year before). The FBI asked us if we’d let them use Igor to help detect financial crime. And Max was able to boast, grandiosely but truthfully, that he was “the Sherlock Holmes of the Internet Underground.

This kind of man-machine symbiosis enabled PayPal to stay in business, which in turn enabled hundreds of thousands of small businesses to accept the payments they needed to thrive on the internet. None of it would have been possible without the man-machine solution — even though most people would never see it or even hear about it. “

This excerpt clearly explains the need for a right balance of man-machine workforce for startups and growing businesses.

Pitfall 3: Indecisiveness While Choosing Scripting Language


To get more details about the conference, you can watch a video of Rasmus’ speech (English, no Chinese translation) and answers to questions (starting from 00:50:00, English, with Chinese translation) recorded by Hu Bo, Sina Weibo Architect. This video will help you differentiate between the thought process of the creator and users, and listen to his understanding of “tools.”

Zero to One by Peter Thiel: http://gsl.mit.edu/media/programs/south-africa-summer-2015/materials/0to1.pdf
Rasmus speech (English, no Chinese translation) and answers to questions (starting from 00:50:00, English, with Chinese translation)

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.