7 Pengajaran yang Saya Perolehi dari Pengalaman Membina Startup

Beberapa perkara yang saya pelajari daripada pengalaman projek startup saya (Ikon.my & Hadoko.com) dari tahun 2008-2012 saya kongsikan di sini.

  1. User/Customer cuma mahukan produk yang boleh membantu menyelesaikan masalah mereka. Spesifikasi server? PHP? MySQL? Node.js? Slack? Bagi customer, semua term-term teknologi adalah umpama screw & paku.
  2. Adalah kita menyelesaikan masalah user/customer? Adakah kita cuba menyelesaikan masalah yang tidak wujud di tempat kita?
  3. Pengiklanan blog sudah lama mati. Dulu pada awal 2003-2010, tak ramai yang mempunyai blog. Teknik SEO masih boleh dimanipulasi, Google Ads boleh memberikan pulangan sehingga RM 150,000 sebulan kepada blogger. Sekarang sangat jarang-jarang, kecuali kalau kita spam FB dengan blog yang tak memberi faedah. Kita membaca blog sekarang untuk mendapat value (nilai) dari pembacaan, bukan untuk membuang masa.
  4. Sejak dari mula projek, pastikan produk/servis tersebut adalah berbayar. Produk/Servis berkualiti mesti dibayar, bukan diberikan secara percuma. Contoh: Astro.
  5. Bina platform/produk yang memerlukan maintenance cost. Jangan bergantung kepada one-off payment. Contoh: Coway.
  6. Disrupt! Apakah servis yang sesebuah startup boleh selesaikan dengan cepat? Yang sangat anti-birokrasi? Kalau dulu nak pos surat mengambil masa sebulan, tapi sejak wujudnya startup seperti DHL/UPS pada satu masa dahulu, servis pos negara cepat-cepat menawarkan servis pos ekspress untuk melawan startup.
  7. Disrupt! Apakah penyelesaian yang lebih mudah yang kita boleh berikan? Yang mempunyai user interface yang lagi intuitif? Ingat, software is eating the world. Banyak pekerjaan pada masa dahulu yang sudah tidak wujud semenjak wujudnya komputer.

Business-Idea-Execution-Luck Equation

where, the values of the constants (IDEA, EXECUTION and LUCK) are held as below:
GREAT EXECUTION = $1,000,000
LUCK is the wildcard you just have to accept as an entrepreneur or investor.
To make a business, you need to multiply the two.
The most brilliant idea, with no execution, is worth $20.
The most brilliant idea takes great execution to be worth $20,000,000.

The Age of Software was fun. Welcome to the Age of Data.

The data is clear: while there is substantial money in software, the difficulty of employing it as a primary revenue mechanism is increasing. This supports our observations of generational shifts in attitudes towards the importance of software [coverage]. In short, we recognize four basic generations of software producers.

  • First Generation (IBM) “The money is in the hardware, not the software”:
    For the early hardware producers, software was less interesting than than hardware because the latter was harder to produce than the former and therefore was more highly valued, commercially.
  • Second Generation (MSFT) “Actually, the money is in the software”:
    Microsoft’s core innovation was recognizing where IBM and others failed to the commercial value of the operating system. For this single realization, the company realized and continues to realize hundreds of billions of dollars in revenue.
  • Third Generation (GOOG) “The money is not in the software, but it is differentiating”:
    Google’s origins date back to a competition with the early search engines of the web. By leveraging free, open source software and low cost commodity hardware, Google was able to scale more effectively than its competitors. This has led to Google’s complicated relationship with open source; while core to its success, Google also sees its software as competitively differentiating and thus worth protecting.
  • Fourth Generation (Facebook/Twitter) “Software is not even differentiating, the value is the data”:
    With Facebook and Twitter, we have come full circle to a world in which software is no longer differentiating. Consider that Facebook transitioned away from Cassandra – a piece of infrastructure it wrote and released as open source software – for its messaging application to HBase, a Hadoop-based open source database originally written by Powerset. For Facebook, Twitter, et al the value of software does not generally justify buying it or maintaining it strictly internally.

The question, as I asked the audience last week at the Open Source Business Conference, is what this means for those in the commercial software business. The answer, from my vantage point, is simple: they need to begin leveraging data alongside their software. As we’ve been saying since 2007 [coverage].

Hackers currently rule the world. But in reality, really good product people should.

via Quora:

Hackers currently rule the world. But in reality, really good product people should. Here’s how to become one.

Overview: Recruit a killer technical co-founder once you have a front-end demo. Establish yourself as the product leader / business person with this demo, then recruit. Here’s how to do this:

  1. Get your version 1 and 2 from back of the napkin to .psd phase (work with an outsourced designer for this, you provide the detailed draft mock-up drafts and the inspiration for the stylesheet). Print designers or designers fresh out of school are surprisingly good for this step. Outside of raw design ability, curiousity / desire to learn is next trait you want. Use something like Pivotal Tracker to manage the iterative process. Use Skype to communicate longer details. Pay hourly, ~$20.
  2. Find a technical advisor, someone that can help you with hiring, specifically. Ofter them ~1%. Quora or StackOverflow is a good place to look for this person. Show them your designs, give them your escalator pitch, let them know you need a founding advisor. FYI this person could be a board member down the road. Always wise to have technical leadership on your early BOD.
  3. Get your .psd’s into html/css/javascript. Again, hire a frontend specialist off c-list, elance, odesk, etc. Have them do a .psd conversion test or two for you, pay them an hours worth of work for it (~$15). Have your technical advisor review quality of code, then hire the best communicator / best executioner. Also, use object-oriented CSS. Goal is for this frontend code to serve as same frontend code in final working version of your service. OOCSS is pretty new, but best bet at getting to scale with any version 1 or 2 of your frontend code. Can use Skype and Pivotal Tracker to manage this process.
  4. Write interaction stories for your designs. So when I click on this button, it does this, etc. Think about how various features behave as a user interacts with your service. You want to details as many of these stories as possible. You want to own the user-experience.
  5. Have your frontend designer build a working demo of version 1 and version 2 of your product using these interaction stories. Ask your technical advisor to review final quality of code before acceptance and pay. It’s “done” when it feels right to you–when you’re ready to sell your product vision to the world.
  6. Reach out to engineers in all forums. Tell them you have a killer demo for a world-changing service you’d like to show them. Get them to NDA (use an e-sign service like EchoSign for this). Let them know you’re looking for a co-founder to build out the backend, while you focus on the frontend user-experience and business logic.

Offer them vested 20%-30% to build out your vision. Make sure you give yourself Founder shares (fully-vested) at incorporation of the idea though. Your co-founder gets a combination of fully-vested shares and stock options shares. Especially since you put up the initial time and capital to get to Frontend demo state.

If for whatever reason your co-founder bails, then have confidence that by being a product-focused founder and owning the UX, design, interaction, business logic, etc. you can recruit technical co-founders and eventually lead engineers with this process. Then put their unvested shares back into the stock option pool.

You can get pretty far with this process but to scale you’ll need a technical co-founder to help with architecture, data modeling, API-stuff, etc. All stuff you want to understand, but don’t want to do. You never want to be in the weeds with technical. Do the heavy lifting to understand it–so you can compensate and manage it accordingly.

Conclusion: Have confidence technical people want to work with product-people that understand frontend, UX, and business logic execution. The farther you get with this process, the easier it gets to recruit a technical co-founder, angel financing, or just a lead engineer (employee).

Again, hackers currently rule the world. In reality, really good product and business focused people should. This entire early product development process can be managed–if you have a vision that technical folks can play with.

So what are you waiting for? Get your vision to demo state! Ideally, so the backend can be developed and your MVP can get to market with the same frontend html/css/javascript that powers your demo.


  • Art and Design schools are good places to source talent, too. Can find these folks on Craigslist but best bet is to contact the hiring office at these schools to get on their mailing list
  • The “back of the napkin” mock-up process is critical. Use Keynotopia, Balsamiq, or basic desktop soft like Publisher or an Adobe product. Key is to communicate user-experience (features) you’re delivering to the marketplace.
  • Think of everything as a user-experience. Yes there is code beneath it and interaction design on top, but you as the product owner need to truly own the user-experience.
  • You’re the editor to the entire product creation process. As you scale, creation is overtaken by curation of the best ideas and processes from your team.
  • This approach is controversial in the hacker-driven world we currently live in. I realize that, am willing to go to bat for this advice. My general belief-system is building scalable products on the web with exceptional user-experiences should follow same process as building real estate (buildings, etc.) in real-life: It should be predictable, should have a definition of “done”, and should be able to be led by a non-developer–or a really good product person that understands technical and can manage the creation of the frontend user-experience from back of the napkin to frontend interaction. A technical co-founder (if you’re under capitalized) or a lead engineer (if you’re capitalized) can lead the backend execution, architecture, and scale.