Building a (Mobile-Web) Start-up: the 2011 way

Share & Comment

The era of business plans and presentations to raise money for mobile-web start-up ideas is over. In Silicon Valley, the venture incubator, Y-Combinator led by Paul Graham and his team have crushed this old school way of building an internet start-up by mentoring teams (with co-founders coming from a software engineering background) to produce a prototype and take the beta product to market. Recently, in my duties as an entrepreneur-in-residence for INSEAD Business School, I came across one MBA student who has totally got it right about building an internet start-up in the 2011 way. He actually built a prototype, tested it with users work out exact market traction with good hypotheses and did at least one product iteration similar to exactly how my co-founder, Saumil and I built Chalkboard. Here are a checklist of things which you might want to do if you want to execute the idea and not just talking about it using powerpoint slides or business plans.

Basically, the way I proposed is based on known methodology in product development and it is just a summary of three key principles: (a) Agile: Build a product in the shortest time and most effective way possible, (b) Iterate: Change the product quickly upon getting feedback from users and test until you find the killer feature, (c) Pivot: Upon failing in the fastest manner possible, learn from the lessons of why it did not work, change strategy and develop the product in a different direction.

  • Build the prototype with an co-founder with engineering background: The best thing to do is to deconstruct the idea into a few basic features and create a simple site or app to test the market. The best way is to adopt the agile development approach – where you determine the features of the site or app that you want to have and followed by breaking them down into “stories” on how a user will interact with them. Sometimes, it’s easier to produce mockups to get a sense of how the user flow will look like. Some might ask, what programming languages to use for rapid prototyping? My recommendation is to look at open source technologies such as Ruby on Rails, Python-Django or even PHP if you want it quick and dirty. As for mobile platforms – focus on either Apple iOS, Google Android or Windows Phone 7.

    I want to highlight two features which can help start-ups in setting up a rapid prototyping and at the same time, gain users at a quick rate. The first is in the signing up of a user. With an inundation of mobile web services in the world, user fatigue will usually creep with respect to signing ups. Take the Jumo approach, just sign up with Facebook, extract the particulars and provide two fields for the user: password and confirm password, and within seconds, you get one user. If you want your service to be viral, flip the model over and put a Facebook application on top of this, and push wall notifications that the user has just joined your service and make updates on how he or she is using your service. The second is in the amount of fields you want your user to sign up. There is an approach in product development that you should only have 3 or 4 fields at most for a sign up, otherwise, the user will just give up. Once you collect these basic sign up processes, lead the user to your product and the main killer feature that you want them to experience.

    I don’t recommend outsourcing your first alpha product development to a vendor which is common in Asian countries and trust me on that, I have bad experiences on that front, no matter how good the engineering team claimed to be. In fact, assembling the engineering team might be slower but it builds good foundation. Get your hands dirty and build a product from scratch. It will also help you in understanding how the programming structure that underlies your product can align with the business objectives you want for your idea. Try to build a tech team in your own house as early as you can. This is the most important lesson for me.

  • Test the prototype in the marketplace: The key lesson here is to take the prototype to market and let the market decide the feasibility of your idea. Move quickly into the market, and remove the “my product must be perfect before going out” mindset. A product with 70% completion with robust features can help you to determine how the users are interacting with your app.

    One important rule that most start-ups do not really do is to set up hypotheses to test the product feasibility with customers. Make a list of hypotheses, for example, “Which feature do you like or hate most?”, “What will you like to see in future versions of the software?”, “Will you pay for this service with $x dollars or cents?”, “Does this service really solve the pain point you are having?” and many more. The important thing here is honesty, do your product really nail the pain point or just your own wet dream that you think that they need it?

  • Collect data and feedback from the users and customers: I do know that some people exercise the principle but not to the fullest extent. Having N=1 to N=10 datapoints are useless. You need as many as about 100 data points to at least get a good statistical feel if the product does have traction. Collect case studies on how different users will interact with the product and what they want. Use the scientific method to create hypotheses and ask questions, “Do feature X resolve the pain point of the user?”, “What are the common uses of your platform?” and etc. You can always make sure that you have served your target demographic group. What are interesting data points? Here’s probably a few that I think will suffice before you go to an investor for money:
    • Does the service really resolve the pain point up to a certain degree and what are the issues which you can’t resolve?
    • Does the service gives the users satisfaction?
    • What are the top 3 features that they love and hate? That’s useful for the next product iteration.
    • Will the customers pay for the service and most important, how much you can get them to pay?
    • What is the cheapest means or methods to increase distribution of your product to your customers?
  • Iterate the product in a few cycles to see if there is traction: The start-up phase is the best time where you can iterate a product many times until you find the killer feature. Once you find that, just totally put all your resources onto that feature and crush the market, because in the mobile-web space, nothing is forever. Some guy from somewhere will steal your feature, and your only chance is to make sure that you quickly take advantage and earn the largest market share. What is important about iterating the product? Listening to customers feedback and discern which ones are really important and which ones are totally crap. For example, the reliable customer will explain to you what his or her pain point really is and wished for something you can actually build it to work. The person with crap feedback will keep harping on why it does not work but ask for blue sky technologies that it is out of your realm to make it or in some sense, have an illogical user experience flow.
  • Quality is worth paying for – Design, User Experience & Good Video: Well, some things are worth paying for and it’s better to go straight to the source, hire the best people and then get it done. For example, if you want to go to the US market from Asia, hire a designer, user experience engineer, copywriter and a good video maker from US. So far, my experience with them is great as compared to the vendors I worked with. The major distinction is on one thing, is their way to communicate effectively and giving you exactly in quality – what you need and what you want. I find that totally lacking in all Asian vendors on this. For such things, I have totally sworn off Asian ones. The best way to know how to pay for quality is to look at how prominent start-ups in US are scaling up with the correct set of marketing tools and design principles. That’s where the real difference is. Less is more in this game and totally work on one thing. The others can come later.

    Here is a good example from a US vendor who conveyed our value proposition very well:


  • Focus on that killer feature once you determine the market traction and paying customers: Well, we live in Asia, and so to get money, we need to demonstrate market traction, i.e. a lot of people want to use it and two, signs of monetization, i.e. customers are willing to pay for it. That’s the most important part, and if you can show those two data points, you are on the way to something interesting.

So, what if you fail? The answer is that it does not matter. The key is that you fail fast and move on. Life in a start-up is meant to be hard, and I don’t think people have talked about how tough and harsh the environment really looks like.

Author’s note: This post is prepared ahead that I gave today in the Rotary Club of Tanglin in the Police Mess on 25 April 2011. The slides are shared above here. Another thing is that this post has taken bits and pieces over a few weekends for me to construct.

Share & Comment

Published by

Bernard Leong

A Pragmatic Idealist

Have something to add?

Loading Facebook Comments ...

5 thoughts on “Building a (Mobile-Web) Start-up: the 2011 way”

  1. unless you have an engineering background, and you need to find the other half
    totally agree with the “stories”, I still am looking at the mobile web as the primary channel and using a cross-platform tool to build natives for the upcoming mobile OSes.

    I think I read it somewhere, you cannot avoid having a team and outsource any early product development simply because too little of the scope can be defined, fixed or even known!

    I feel that the rest of this article really can’t fit just ‘any situation’, and a lot of these arguments like customer satisfaction etc. is really no different from the bull* you get from any IT vendor.
    Still, a good reference point that must be taken with a pinch o’ salt ?

    1. The answer is that you can avoid outsourcing product development earlier. In fact, you should define the scope as simple as possible. The problem with most people is that they don’t make an effort in deciding what’s the baseline product and started adding scope creep when they are developing it.

      The key is that you built certain features to test how customers use it before really scaling up. The problem is that most people don’t follow that line of thinking.

      1. I agree. Testing before putting more resources into a feature is being fast (or, “agile”) – and is probably the smartest way to do things. How having said that… while I agree with “Agile”, and “Iterate” – is “Pivot” really a principle? Putting it in there would be the equivalent of saying that being “Agile”, and Iterating is definitely NOT good enough – and WILL necessarily fail?!

        Keep us informed about your talk, btw! Will be looking forward to it.

  2. I second what Bernard has posted above. I think having a minimum viable product is very important along with customer validation, pivoting and pivoting. Fail and learn fast. However, what some people are not willing to do, is try to validate their business with the initial traction of customers and the mentality that the product will attract customers once it is done, once money is pumped in for marketing, once bla bla bla. Why spend 50k on the development of a product when you are not even sure if anyone would like to pay for it?

Comments are closed.