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.

Abstract

This blog recounts the author's experience at the Beijing International Convention Center from May 14-15, 2016. It also offers useful directives and insights into planning your startup journey.

Introduction

Planning the journey of a startup is a challenging endeavor. After securing partnerships and finalizing the product direction, you will have to create a prototype of your product. Gone are the days of using paper mockups or prototyping tools. Today's investors demand for a beta version of your product to be released and tested on a small group of users. This allows investors to measure the product's usability before committing to a large investment.

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

When the author started his business, mobile app development was a hot topic in China. The author and his co-founders intended to profit by launching an average app that would quickly help them receive funding.

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

Automation makes processes more efficient and helps startups save resources. However, before implementing an automated process, the author recommends to complete the entire process manually and check if the solution addresses the problem successfully. Upon successful completion, your team can proceed with automation. This is a more sensible approach as it allows you to isolate design flaws from automation errors. Additionally, when your resources cannot support 100 percent automation, you can perform part of the job manually.

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 by .

"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

At the China PHP Conference at (BICC), the author met with Rasmus Lerdorf, a visiting consultant for many startups. During the conversation, they discussed about the common indecisiveness by startups on choosing a scripting language, particularly among PHP, Java, or Go. They talked about how startups waste time and energy in tool selection but fail to address significant problems. Instead of delving on this issue, startups should focus on differentiating their products from competitors.

Conclusion

Summing up, all startups experience failures at some point. To minimize the impact on your businesses, it is important to anticipate and avoid the common pitfalls mentioned in this article.

To get more details about the conference, you can watch a video of 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."

References: