Archive for the 'Business' Category
Sunday, July 5th, 2009
How Startups can Evolve, and the E.V.O rule: Establish, Verify and Optimize
There are rarely successful businesses that followed through what they had wanted to do originally. See Facebook - if you have seen the original interface at thefacebook.com (its original name), you will know Facebook was meant for college students in the early days, particularly for Harvard students. Apple changed its name from Apple Computers because they realised they have evolved from just selling computers. Yahoo was supposed to be a directory service, and Google’s page rank algorithm was pretty much the only USP. Dell remains pretty much a JIT operation but they are now better known to produce cheap business desktops. Saying all startups should be adaptable, agile enough to adjust to the business climate and needs of the market is akin to saying the Moon is round. The room to evolve is critical for a startup because great ideas do not happen overnight, and instead many times through much trials, pain and even dark moments to finally get the right mix. Other times, its purely luck that the right person comes along to join your team or to refer you a great deal.
In itself, evolving a product is an art. There are many evolution outcome of a kickass idea:
1) Vertical Evolution - Your idea evolves in a manner where you start earning bucks off the guy up/down-stream of your supply chain. For e.g. if you originally planned to sell cupcakes, you need flour and sugar. If your business begins selling flour and sugar as well, that is vertical integration, and if you decided that flour and sugar are much more profitable, that is when your business will evolve vertically.
2) Horizontal Evolution - This is a much more common form of evolution; using the cupcake example, you may decide to sell brownies, pizzas or even coffee instead. Your business model may change a little, but you are still generally making money from almost the same group of consumers, or similar consumers.
3) Business Model Evolution - Instead of making money from the consumer that stops by your shop, your sales may from from mainly corporate customers. Your cupcakes may instead become complementary products for other cafes. You may even give cupcakes for free to the public and instead ask people to donate to your piggy bank, or even request them to do a survey, and get paid for the surveys from a research company.
4) Radical Evolution - Now, your cupcake business is not really selling cupcakes anymore. Instead, you have decided to become a school teaching how to make cupcakes. Your business model has changed, your staffing needs are adjusted, and even your supplier is no longer the flour man, but an Internet marketeer.
5) Bad Evolution - To be honest, this really isn’t a brand new category of evolution; it really is a bad evolution that can happen from any of the above strategic decisions. Bad evolution happens in many cases, such as when your competitor squeezes you out of the original domain forcing you to adopt poorly thought business models or diluting your brand by doing selling desperate products you have poor knowledge in. In a nutshell, bad evolution is an evolution of an idea which is not properly controlled and ill-managed.
I come up with the EVO rule which I hope some can find useful for managing this process - namely Establish, Verify and Optimize.
ESTABLISH your needs, your weaknesses, your strengths and the market conditions. Establishing the status quo in a wholesome manner is beneficial to seeing the whole picture. There are many ways you can do these: Porter’s 5 Forces model, or a simple SWOT analysis. Is there an opportunity you should exploit, or is there some fundamental weakness in your startup which no VC can agree with? With the cupcake example, you may want to establish firstly that your sales are bad not because you suck in baking, but that the recession is looming around. Back such statements up with good data, such as focus groups and conversations with peers in the industry.
VERIFY comes in after you decided to evolve. Verify that you have not steered off into a road where you have no competence in. If you have been baking cupcakes your whole life and that is the only thing you know, do not sell brownies just because it is the trend for the year. If you indeed possess the expertise to make brownies, verify that this is the new startup life you want to lead; pretty much selling anything that is in trend, and getting ready for more evolutions. Ensure also that the evolutions you have executed do not confuse your current customers, and articulate the new offerings clearly. Be sure that your passion has not been led astray, because without passion your startup life is going to be very very miserable! Lastly, verify that your evolutions are meaningful, financially of course. Run them through your potential customers, in networking sessions and your board of advisors. After implementing them, monitor them closely and note the progress.
OPTIMIZE your knowledge/intelligence in the new inroads you have carved. Bearing in mind you are almost starting all over again, you are slightly disadvantaged compared to your peers. You can expand such business intelligence through more reading of books, blogs (of course!), or get a team member/intern/consultant to run through such research in a dedicated manner, and impart to the team afterwards. Employ someone who is already experienced if you have the money is definitely the optimal solution.
I know I am being generic here about the EVO rule, but someone has to start somewhere (; Please feel free to drop me some comments.
Sunday, June 21st, 2009
The BIG fuss about Agile Developments
I recently attended a session by Mr Joichi Ito on the topic of “Consumer Web in Focus” , and those who are lucky enough to get selected to pitch should know exactly why I haven’t stop praising the man since with the one-on-one session on FAME. I tweeted immediately on the most important takeaways on that day; #1 Develop a Scientific Approach (A/B) for Testing #2 Establish that WOW factor in the first 5 mins #3 Ensure Survivability in our game for all players.
In the talk itself, Joi spoke about the different stacks in the Internet, different tiers of VCs and how good products do not necessitate good a strong traction. The best lesson of the day imo to most aspiring entrepreneurs is on how startups should really “just do it” because it may cost more to find out if a product is really feasible than to work on the actual application suite itself. And to do that, your development methodology has to be agile and iterative.
Meet Extreme Programming (XP), one of the Agile methods Joi spoke about. The most “notorious” rule in XP is the arguably the concept of Pair programming. Most of my peers swear by the inefficiency, but they also tend to overlook some core benefits. Having multiple pair of eyes on the same screen in theory can produce better codes and applications in the long run. The programmer becomes disciplined while getting the occasional slap-on-the-wrist from his comrade. The comrade provides a second opinion on the functionalities, style and refactoring method that the programmer coded. The end result is both of them learns from each other and one can be sure pretty sure that the codes do what the client requires because 2 heads think better than 1. Still, time is an expensive commodity in the IT industry, and people gets edgey over such perceived redundancy. I would suggest that pair programming can evolve into 2 developers sitting alongside each other with their own macs, constantly checking on each other’s progress and using Subversion to sync their codes. (I will talk about SVN in another post) - lots of communications take place verbally to ensure the requirements are “what they are”.
The most important rule of Agile Development is probably the iterative nature where you can expect many many releases. Again, having multiple releases (not of the whole damn suite, but instead of individual components) again reaffirms the product development guy’s vision, as well as allowing the marketing person to track with his focus group. Any cost in changes is limited to between T=0 and T=1, where 0 marks the start of development and 1 marks the first release. At the end of the day, it’s about coding that “thing” quickly (e.g. with ROR) and roll it out to the market quickly in anticipation of Change Management. In Joi’s view, this makes much more sense than trying to figure out if your product works. Doing it on the cheap is feasible compared to 10,20 years ago (think waterfall approach, gasp*)
I would like to take the liberty to suggest an extension; Invest in refactoring your codes and deploying elegant framework (MVC is a nice pattern). While Joi is right about developing a product quickly to feel the market pulse, that does not mean you prioritize speed over scalability and elegance. I propose the 40/30/20/10 rule; Spend 40% of your development efforts coding, 30% testing, 20% refactoring, and 10% documenting and making sure others understand whats going on. The Web is an amazing paradise to launch products, only if one can scale and adjust at god speed.
Friday, August 15th, 2008
Review of Project Management Tools - Google Docs & Calendar, Zoho, Codebeamer, Dotproject, gForge
Project Management suites are, in my own words, absolutely essential for application development companies. They empower project teams to manage documentations, plan milestones, organize meetings and facilitate communications - and more importantly, involves our precious clients seamlessly so you don’t have to waste too much managing tedious, angsty, never-ending back & forth communications. I can now claim myself to be a real matter expert in this field because I have tried all of the above mentioned applications before settling for 1 for my purpose. I must say there is no 1 single perfect suite for my needs, as they certainly have different offerings and features. I certainly have my preferences though. While the above apps are not the only one, (there are others like 37signals’s basecamp which cost quite a tidy sum.. you try them and let me know how they fare), they are certainly free at least to a reasonable certain extent. Without further ado, there is the lowdown on them:
Codebeamer
This is the very 2nd project management tool I have ever used after Project-lifeline, a now defunct project management tool developed in house by SMU Students. Codebeamer, developed by Itland, does not come cheap for its commercial version. Its free version allow only up to 5 users, and with many functionalities disabled. When I contacted the salesperson to enquire about the cost, they give me the impression of being rather shady - they evaded a question I have regarding whether the free version had a certain feature (which he told me its only available on paid for version, but I later discovered myself that the free version had that feature), and quoted me quite an astronomical price - about USD$1,000 for about 100 users (though my company has obviously not grown that huge)
Service aside, Codebeamer has a subversion integration capability that allows administrators to set up SVN easily. Under documentations, ACL is nicely implemented. You can even plot sequence diagrams and other uml notations with text. CB has a very nice interface which is using to create your own wiki blog, and a nice integration workflow structure which allows linking of documents to everywhere else. Like Zoho, Codebeamer has a forum functionality and notification mechanism for new documents and forum post.
What I do not savor however is the lack of Calendar function. Codebeamer has a tasklist and milestone feature but for me that is insufficient. Codebeamer, which is being supported by JavaForge, may be well-liked by big software firms but for my purpose, I needed something that is easier to use and integrates well with word documents. One more thing; it looks horrible on Safari and Firefox 3.
Google Docs & Calendar
My pursuit of an integration tool with Calendar and Documents bring me towards exploring Google’s offering - Docs and Calendar. Now there is a huge problem 2 hrs into my experiment; Google Doc does not offer project management features at all. Instead of a many-users-to-1-portal-with-many-docs model, they use a many-users-to-many-docs model. Meaning, documents are being shared at a user level, instead of at a project level. Thus, it becomes difficult to manage these documentations. A solution would be everyone share a single Google account to log into the portal, but this opens a can of worm on audit trail issues. Without any doubt though, Google Doc is easily the best in the office suite in terms of usability.
On a separate issue, Google Calendar is just beautiful to bits. It is easy to move and drag events, and has a nice reminder feature (I heard if you are in States, you get SMS reminder service). Google Calendar allows users to share calendar and to publish their own. I will be looking closely at Google’s foray into project management aspects.
Dotproject
This is an open source project from the land of Mercedez (and CB). The best part of it? It is free, deployable on your own server (like Codebeamer), runs on PHP so you can just use some webhosting companies and has many plugin availables from the OS community. However, the userablity of Dotproject has a lot of room to improve; In an age where AJAX is so commonly used, Dotproject lags far behind in user interactivity.
gForge
To be honest, I only tried gForge, which is vastly similar to Codebeamer in its core features for a while before I give up. I cannot comment much except that it is free, and allows users to set up SVN and track bugs easily - just like Codebeamer. What stops me from proceeding further with it is in its lack of abilities to allow me to write documentations immediately without having the need to upload.
Zoho Projects
I love Zoho to bits. Ive told many friends about it, and even the forum moderators in Zoho. To me, Zoho projects is almost on the brink of perfection, except for some minor bugs and wishful features I really want; such as integration with Zoho Calendar (which is nice to drag and drop), and offline synchronisation of documents. Zoho projects is Google Docs in a project management suit. It has a wonderful multiple portals and projects management which allow users to change portals and projects easily. The calendar features is easy to use and Zoho Write (MS version of Ms word) and Zoho Sheet (MS version of excel) is very friendly (:
Another article about Zoho that gives you a better idea on the office applications:
http://www.twistermc.com/blog/2006/06/20/zoho-online-office-applications
I feel Zoho Projects has huge potential, with its killer low price and responsive replies response from its support. With its all round integration functionality, the value curve offering, imho, is a notch above others.
Thats all folks. Please leave me a comment if you disagree or if you like what you read (:
Wednesday, July 30th, 2008
Review of panel discussion: What are the next investing opportunities in new media?
Something very funny happened before Damon, my trusted sidekick, and myself headed to Swissotel for the iJam networking session (announcing launch of iMatch) yesterday. We happily walked towards Raffles City and go up to the ballroom in Swissotel. What followed was a series of confused hotel staffs not having a clue of any IDA event when we couldnt spot nor sniff a single clue of any IT geeks. It turned out we were at the wrong Swissotel (as Damon put it,”Oh there are more than 1 Swissotel!” and to which I replied,”*gasp*”). We were supposed to be at Swissotel, Merchant Court. Nice.
Ok so lets move on to discuss more serious “Series” - Series A, B, etc funding. These are terms use for different stage of fundings for startups by Venture Capitalists (sometimes jokingly nicked Vulture Capitalist - credit to my portfolio management professor, whose identity i shall not divulge :). First of all, I must say that it was a fruitful talk which was worth all the hassle Damon and I experienced prior to it. The panel boasts of a excellent concotion of local and international VCs and Technology experts - notable attendees: Ms Lauren Liang, Mr Pierre Hennes, Ms Ong Siu Leng. While they offer some pointers which many of us would have already known, they reinforce some beliefs in myself and offer new perspectives to what VCs want to see in young startups.
Some important takeaways buried deep in my head:
1) Early stage VCs look not just for a great idea. The assessment team plays an important part.
- How creative is the team?
- How is the synergy and energy of the team?
- The character of the team: Are they determined enough to walk the talk throughout? (without falling for the temptation of bigger money and job elsewhere?)
- Keith: An academia pointed out in a research that a trait of successful startups is that it has more than 1 founder, between 2 to 5, while 3 is the optimal number.
2) Localisation or Globalisation? The panel is quite divided on this. However, they all agree that it is important to focus on a segment of consumers on whatever choice you make. More importantly, get your first dollar in quickly, at least to assure your backers.
- Keith: Bear in mind Singaporeans being Singaporeans, we are a very unique breed of citizens compared to many others in the world (just hear our accent, our English, our love for durian, our loyalty to the ruling party :P). E.g. We can largely generalise consumer habits of Malaysians and Indonesians, or Taiwanese and Japanese, but what works in an already small Singapore market more often than not will not work for many other countries. Be prepared to customize radically when scaling abroad.
3) Be prepared to sacrifice, even if it means you being the CEO. When big brother wants to bring in someone more qualified and experienced to be the CEO, you should let go.
- Keith: Which is why, please hedge yourself with an MBA education (:
4) VCs require that the team has enough stakes nonetheless, so to ensure they remain motivated and responsible for their gains and losses.
5) Cold Calling the VCs may work, but networking would speed things up to establish a relationship between the VC and the Startup team. No one said it better than Mr Pierres when he said it is “like a life long marriage”. Relationships, or guan xi always work like a charm.
- Keith: I have to admit that I’ve never enjoyed networking, so I always go in with a mindset of making friends for learning, rather than other tangible benefit. It helps.
6) LIVE: One of the panelist said a rule of thumb of a successful product encompass the following attributes: Lively, Interactive, Visual, Experiential.
7) Me-Too Products - VCs generally do not require startups to be a from-scratch-innovation based company. Me-Too products can equally be, if not, more successful and astute investments for them.
8.) Are Singaporeans really that un-creative and un-innovative? Mr Douglas Abrams from Expara disagreed, and had seen his fair share of innovative local start-ups. Singapore, while not comparable to Silicon Valley at the moment in terms of the eco-system of funding, has good potential with our good infrastructure, supporting government schemes and growing amount of wealth (especially private) in Asia.
- Keith: I suppose the link to how growing wealth in Asia equates investing in Singapore startup is this: 1. Singapore being a financial hub for Asia 2. It is easier to manage startups in Singapore if the money comes to Singapore 3. Thus, with 1 and 2, go for local startups.
9) The question of IPO came up when a gentlemen asked what are the other exit points other than IPO and M&A? I didnt really get the answer other than a brief remark on convertible debt aka convertible bond (which I don’t think have to be these 2 exit points anyway), a panelist cautioned startups not to be overly confident and declare “I will be IPO-ing in 2 years”. No one can guarantee an IPO.
10) This has to be the best advice all day: You will always need more money and time than you think. So plan carefully and do not overspend. The worst mistake that can occur to a startup is to hold multiple series for extra funding when they realised they do not have enough. A business should be focused on the product, and not funding at all times.
Please feel free to comment on any points (:
Sunday, July 20th, 2008
Doing it right the first time .. or does IT matter?
When releasing a product (especially innovative ones) in the IT domain, just how important is it to do it right the first time?
The experts are divided on this: Some would advocate the importance of showing others something that works and impresses, and emerge from your dark garage with a huge big impact that gets everybody’s jaw open - at the expense of time/effort and perhaps lost ground to competitors.
Others would tell you to build a community with a beta launch early, get their feedback and consistently improve. The latter situation helps you gain a first mover advantage, gain some sort of credibility as a company that delivers gradually, assures your VCs, but as you would have guessed, the wow effect would have been subsided. In terms of branding, your company is gauged accordingly to that buggy beta launch you have. In terms of marketing, you could miss out on the advantage of viral marketing (my reasoning is that if you potentially lose part of your community with a less than perfect application and miss out leveraging on their “word of mouth”)
I do not believe dude-my-solution-works-for-you-and-all exists. As usual, I listed down some guidelines that will help a startup determine its strategy, and end off with a possible solution startups can consider.
1) Can you foresee competitors that are already working on something similar?
If you do, you probably should release your application in iterations, even if it its less than perfect. First mover advantage has so much benefits that you simply can’t miss out in the fast moving IT world, and building a community with your beta can lock them into your application. Releasing early iterations also place pressure on competitors, forcing them to show their hands with less than perfect applications. You are better off than ignoring them and run the risk of competing with a even better application which the world saw earlier than yours.
2) Can you decide well enough what is good for the community? (Do you even know em?)
One of the best lesson I have learned in many years is from the trendsetting guru, Mr Steve Jobs, who quipped that focus groups are useless because most of the time, your customers does not know what they want. However, if you feel pretty inadequate in deciding what THEY want, you are better off releasing your early versions of your ugly application to them. Who knows, they may be more than happy with that! Also, if you are still unsure about your target market, an early release may help you decide. It is common in every business to evolve and adapt to the market pays you more.
3) Do you have enough engine and dolli?
The later you release, the less confidence your investors will show in your company, and so will you to your corporate bank statements. Slow release may also result in demotivated staffs who have been waiting to capitalize on their equity stakes. You run the risk of your best programmer quitting you for another company just because the work they do don’t seem to see daylight as the days dragged on with another of your “Oh I think it will be great to add this function!”. At the same time, releasing your application gives potential new talents a preview of what great idea you have, thus attracting them towards you.
In a nutshell, the 3 questions above in fact are point to the same rhetorical question: Just how important is your product coming in with a BIG BANG? (Kaboom and Cracklings)? If it is a matter of life and death (which is implied from your answers from above posers), and yet the disadvantages bother you all the time, you can consider what I call a ring-fence launch.
In a ring-fence launch, you ensure that competitors and general public are not able to access the application. Get only friends (preferably close ones) to see your application, as well as reiterate to them the importance of keeping to themselves. Explain to them your motive, and ensure that this is far from being the final product, and that their word-of-mouth help is critical to success when you eventually do the final launch. This is helpful because you do not want them to ignore your fiinal product due to boredom and lack of excitement.
Personally, I would chose to launch something that is 50% completed - with quite a different look to the final look and feel. I would even use a slightly diff name for this application in my url ,e.g. such as myproduct_beta such as as myproduct. This is to illustrate the key difference in both releases to the test community.
In my next post, I will discuss the different kind of beta launch and more strategies in doing so. Please feel free to comment on this post!
Saturday, January 26th, 2008
Pensée - Doing Business in Cambodia and Thailand
As promised: The takeaways from the trip (:
The crux of “Business Study Mission (BSM) to Cambodia and Thailand” is in understanding both aforementioned countries’ business environments, chiefly through participant observation. Indeed, this BSM has not only provided key insights in the differences between both developing countries and ‘developing’ Singapore, but also successfully illustrates the innate distinctions between the 2 countries themselves; such learning opportunities would otherwise not be realized in any Prentice Hall or McGraw Hill textbooks. In other words, this was a fruitful BSM trip which would be analyzed in the following aspects.
Read the rest of this entry »
Friday, November 16th, 2007
Singapore PHP User Group Nov 07 Meeting Review
Out of curiosity and support for a fellow developer, I accepted Michael’s invitation and attended his baby event yesterday. I reached around 7.30pm and was pleasantly surprised to see Hazel coming along with Euquin too. And it was over subscribed too! (darn.. looks like my support wasnt so helpful). Michael started the party at 8pm with his PHP crash course, but I missed almost the whole entire bit on the 2nd presentation to chat with a few old friends outside the room. The 3rd, from Uzyn of Ping.sg, was refreshing; Having been exposed to so many SMU style of presentation, geekish presentation is a fresh whiff of air. If you are interested, you could get more materials from http://blog.simplyjean.com/2007/11/15/get-your-php-user-group-presentation-slides-here/; I must say, I am immensely impressed with the live blogger, Jean, too.
Now for the review; Certainly, A+ for Michael’s almost 1 man show for this. Generally, this get-together was not bad. Not lousy, Not overly fantastic, but pretty not bad. Firstly, I’m not too sure how interesting it is to make experienced php coders to sit through the opening 1hr. Perhaps this cant be helped, since this event aimed to get as many people of different background together. I have to admit it was great for me, a non-php coder, coming from a purist Java background, with MVC framework like Struts my weapon of choice. PHP certainly looks fun to me! (I am trying to pick up ROR though right now too).
Next, moving on.. While going through Jean’s live blog on Raymond’s bit, I found several debatable points in the floor’s discussion and presentation. For happiness, peace, harmony and prosperity, I shall not elaborate too much on them. If you have read my very first post in this blog, I adopted a very neutral view towards open source solutions vs commercial solutions, so you will now how I feel towards the presentor’s arguements. I also wonder where that someone gets the fact that “most banks do not run Linux or PHP”. Maybe he/she meant something else like for frontend or for office work/purposes? Anyway, many banks I know of have extremely complicated technology infrastructures and organization that span globally from India, Singapore and even Hongkong, and they obviously do not run on a single platform all the time in their server operations. While PHP may not be adopted on the frontline of banks, they sometimes use it for intranets or some 1-time event websites.
The security workshop was a good refresher for me, with a couple of more web applications related security concepts which can apply to all other languages. However, at some stage, I felt the meet up was going to spiral out of control with questions popping out frequently, probably due to some rushing through of the presentation which defeated the purpose. By the time the whole thing ended, it was close to 11pm - something which I had not expected when I reached the seminar room at 7.30pm. Perhaps, each talk can be scaled down to just 30 minutes in future, with 10 minutes of discussion time in future! All in all… this was a relatively enjoyable event abeit the lengthy session. Unfortunately, I will not make it to the Dec session as I would be abroad, but I am sure it will be very much looked forward to by many others.
And yes, something was missing throughout. REFRESHMENTS! *hint hint* 
OT(not related to event review, and warnings: technical dangers ahead): I have to also point out that web application developments arent that straightforward as some inside the room seem to think so. Yes I know PHP has its own MVC model too - afaik CakePHP is one of them. However, many PHP coders I have asked do not even know what that is (to date, Michael and I are still looking for CakePHP programmers for a project, please contact us if you are one!). I cannot comment much on how effective CakePHP functions as a MVC framework too, but my experience in using Java to code many web applications has been beautiful so far. I cant complain much about the support, the community, the elegance, MVC frameworks such as Struts, and commercial Java Servers for superior performances. The only thorn is probably EJBs for me, which its true intrinisic value is something I have yet to figure out. Similarly, some systems would require thread applications in the background on top of the web tier application. It is thus desirable at many times to use the same language for the entire system so the team does not have to deal with multiple languages. This is where Java and even ASP.Net would come in very beneficial for many companies; Disclaimer though: I do not know if PHP is a good language choice for thread or background applications (it can be done i think for scripting), nor know much on perl’s features. Perhaps, to draw a more compelling comparison of PHP’s true value compared to the rest, I should try developing a PHP web application myself (=
On the point that banks prefer more established technology, thats spot on, but its more than just that too. In evaluating web technologies, as mentioned earlier, we should look at other factors such as framework and number of developers who understand that framework, and availability of established vendors who can deliver robust applications. This goes as well for MNCs. Now, the golden rule of IT development is the all familiar “if it aint broken don’t fix it”, which these companies would follow religiously, especially when these platforms are already working so well for them. Even if PHP is established, I doubt the switch to PHP will come so easily. Another suspicion I have, though I cannot confirm, is that PHP programmers generally charge less than their ASP, JAVA peers, and thus are more suitable for SMEs and start-ups.
* I apologise for this very unstructured review, as I am doing this at the wee hours of the morning. *
Wednesday, November 7th, 2007
Looking to innovate a successful IT business? Get your hands dirty!
Recently in our shared office in SMUBIG, I had a chat with Leonard Lin, one of the key founders and drivers of Tyler Projects (already relocated elsewhere though!), who has brought us Battlestation in Facebook, and Mobile Weapons. Do check their very cool applications out! Anyhow, we discussed very briefly about the business of innovations in the IT world; A theory popped out of my head. Looking at the most successful technology companies in the world - Apple, Microsoft, Google, Oracle, and recently Facebook, they all had a very common similarity.
They all had founders who got their hands dirty.
All of these companies had founders and leaders who did everything themselves, or at least got heavily involved in the developments. Bill Gates hid in his catastrophically-sized room for months while coding; Facebook was almost singled handedly coded by the founder and current CEO Mark Zuckerberg (of course, with a little support from his buddies); Google “Wonderkids” Page and Brin both coded their PageRank algorithm and offered many companies who laughed them off, and the rest they say, is history. There are many more examples in Dell, Creative and LinkedIn. And now, the closest to heart local example whom I mentioned right in the start; Leonard and his team of developers. Now, dont kill me for stating the obvious, but this is exactly what a geek can have in advantage over many people! building a giant business on their computers. My point is, you can’t just have a great IT idea and expect some others to execute it all beautifully and perfectly for yourself. Heres 5 reasons why.
1) IP Issues. Heard of Connectu.com? Mark Zuckerberg was supposed to code this pre facebook social network for them as a paid developer. He is currently facing a lawsuit and charge that he had stolen the concept from his former employers.
2) Failure in translation. This is a classical case of vision mismatch; the CEO articulated his ideas to the CTO. The CTO builds him something. The CEO screamed and ranted. The CTO remains helpless. The programming team scratched their head. The COO shaked his head in disbelief. The designers cried their heart out after learning they had to change the whole design.
3) Lack of ownership. The programmer and his master, the visionary sit down together. The visionary promises 10% equity stake to him. The programmer must finish everything. If everything works out nicely the visionary will be CEO and the visionary will get rewarded. If everything fails, the visionary does not lose anything. The programmer wasted his time. If you are the programmer, you would probably give your all, 110%.. NOT.
4) Misalignment of vision. The developer and the CEO have different ideas and dreams. The CEO wants a cube, but the designer thinks a bubble is nicer. Would this partnership ever work out? Yes, if the CEO force his ideas on the developer, and the developer became grumpy, and finally deliver a half past six job. yay.
5) Inexperienced IT Leader. The CEO thinks technology is magic, and expects the developers to give him the world; 3 months down the road, the team gave him half of what he expected; the least important features which took more time then any other important functions.
Of course, these problems can be mitigated through counteractive measures in each of them. However, that technically-inexperienced leader should be articulative, charismatic and trusted as well. So far, I have found very few examples of such leaders in innovative IT products. Now, the innovation process is very complicated and tedious - clearly, just having an idea is not sufficient; nor does having just the technical skills. If you have a wonderful and killer innovation in mind, I urge you to either pick up the relevant IT skills yourself, or establish a clear rewarding system for your team, properly outlined.
On the first point, I recently heard that a middle aged friend is picking up Ruby On Rails. It did not surprise me a bit; That bloke has wonderful Web2.0 ideas and concepts, and probably want to build a killer web app himself. I applaud him on his efforts. On my second point, no one likes to work with nothing promised, and thus you will get nothing too. If you have some spare cash and want to outsource it, sure, do it, but make sure for your money that company understands exactly what you want, and does not steal your idea somehow. If not for these potential touchy issues, at least, getting your hands dirty will mean saving you some costs (yes yes… theres the opportunity cost… but well…. )
Finally of course, a best friend who is a geek would really help your business idea a long long way. Trust me, if not, at least trust Steve Jobs (: Start befriending one now!
Saturday, October 20th, 2007
4 Lessons for Innovative Projects Consulting
I quote the following from SMU knowledge Hub, which is an article which I posted earlier in the Voice Biometrics post featuring one of my projects and team. On closer look the writer, Low Shiping, had really articulated well whatever we were asked on in consulting projects during the interview (which we could not really translate well to words!). The following are excerpts from the article.
* In consulting projects, clients are often uncertain about what they want as the end result. The onus is therefore on the consultant to assist their clients to accurately define and understand their needs and problems. This process could require a significant investment of time, effort and patience after which the imperative is on the consultant to articulate the various possible end results as well as the means to arrive at them.
* It is vital to keep the end user in mind at every stage of the business process. Consultants must put themselves in the position of the end user and try to imagine how their proposed solutions will affect them. Ideally, the solution should be user-friendly and hassle-free, no matter how technically sophisticated. The goal is to retain the end user and attract new ones, not to put them off and drive them towards the competition.
Keith: These 2 points really emphasize the importance of having good communications skills and acute business acumen. Bear in mind, in consulting projects, clients often want to act “fools”. What I really mean here is, clients tend to allow the consultants take charge and lead the war. Thus, it is important to remember to find the right questions to ask our clients, so we could unveil some hidden business values and concerns they had in mind. Do not wait till it is too late
* Dare to innovate. Every problem has an infinite number of solutions, but finding the best ones can only be done by taking risks and facing rejection. Without innovating, there will be no forward development.
Keith: If some part of A does not work, try B. If some part of B does not work, try C. If some parts of A,B,C do not work, try A+B+C combined - who knows, it may finally work. Technology acts in a mysterious way!
* Work with a multinational team to lend a “global” perspective to the task at hand as far as possible. Solutions that need to be applied in a global context can benefit from being developed by a diverse team whose members represent different educational and cultural backgrounds. Thus, different points of views can be presented and challenged, leading to well-rounded discussions about how to deal with the tasks at hand.
Keith: This was a team with 1 Burmese, 1 Indian, 2 Indonesians, and 1 Singaporean. Our China friend Huang Liang left for his master’s education in CMU; otherwise it would have been an even further amazing combination. The synergy, creativity, and dynamics - amazing stuff. Singaporeans indeed have a lot to learn from our counterparts, since we are brought up in an education system that have already been destroyed and revamp - one which do not encourage us to think out of the box, think creatively. Surely, our efficiencies alone won’t bring us too far in this dog eat dog work, but once “sprinkled with the different flavors” of the world, we can excel and ride the waves together in this globalized economy. A diversified environment definitely works for me, and is a hell lot of fun too!
Saturday, October 13th, 2007
Good Industry Email Etiquettes and Practices
I am a self confessed EMAIL addict. Almost every time I have access to any PCs, I immediately log onto my web-based mails. And when I am using my IBM x41 at work, I frequently check my Outlook to make sure I do not miss out any mails. The first thing I do when I wake up, is not brushing my teeth - no prize for guessing correctly; is checking that darn mailbox(es). The anxiety and obsession associated when I do not check my mailboxes for 1 week include facing 100 unread mails, in which one of clients asked when that IT project finally is getting delivered, an announcement from the Professor, or a notification from Facebook.
Kind to think of it, there is no need to be panicking around even if I do not check my email regularly - it is just a natural habit, akin to not carrying your cell phone for 1 day. My life has become so intertwined with emails (& technology), and Im sure that is so with bulk of you too. The emails that you send out invariantly define and shape you, and so does the email that you do NOT send out when others anticipate your response. Clear, effective communications between parties too, has a prestigious place in modern emails. In this post, I will share some important email etiquettes and practices ensuring rightly that EMAIL, possiby one of the best inventions after Internet ever, does not screw your life.
1) Reply when expected.
This is a silly point to even bring up, but many people suffer from this basic dysfunction. When a simple email for availability for a meeting goes ignored by some, it frustrates the sender into doing extra work like calling them up. Even if you are unsure, the general expectations is to at least let everyone knows that you are NOT too sure, and you will inform earliest time possible (of course, this depends on whether you are able to find out promptly and if the email is urgent).
This is simple courtesy and manners. There is no rule of thumb when you should reply. You simply have to use your best judgment for different situations.
2) Let others know you arent checking that mailbox!
Again, this is common sense. If you are not going (or a chance where you are not going to exist) to visit your emails in 3 or more days, (a long time in the modern email standards for professionals!), it will do you good to inform your peers! For a start, an auto responder (e.g. out of office wizard) like what you see when you sent an email to complain to your favorite manufacturer, is appropriate explaining where you are, what you are doing, when you will back, and a disclaimer that you will try to reply where possible as soon as possible is the bare minimum.
Note however, this is insufficient in certain cases. If you expect someone to write to you anytime soon, or there is a party whom you have been liaising with for some time, remember to inform them before you go kaput, so they do not get a surprise door gift when they write to you expecting you to be around. It reeks of irresponsibility, especially when that party is a client of your company whom has been having some problems with a product you sold but urgently needs attention. Handover the case to a colleague, and inform your client about it if you are not going to be around for a week. That client would appreciate your thoughtfulness and considerate attitude.
3) Check, Double Confirm and Verify your To-List! ( i.e. check, check & check)
Reply-to-all appears to be a deadly invention. Many times, I have received emails that are supposed to be addressed to just one subject, but I end up getting it because the victim mistook Reply to All for Reply. Other times, fingers have lightning speed reflexes and hits Alt-S before the brain reacts. How deadly is this oversight when a Reply-to-All gets executed disastrously?
Remember not to tell Jason about …….
That client was a joker! LOL
Nice email. Now… when are we going to get that dinner sweetie?
Till today, I do not know of an email client or any technology at least in Outlook that prompts you to double check if you are going to send that email. Some ideas that emulate this though includes a Spell Check function that forces you to confirm sending the email or deferring sending all your email by 1 minute (allowing you to cancel sending if you have a bad feeling; silly but effective!).
Otherwise, it is good to cultivate a habit of making sure the email should reach the right people. On a side note, in the past, I often forget to attach attachments though I have not made the above mistakes before. It would too, reflects negatively, especially on my carelessness, and I have since decided to cultivate a habit to check my email contents too.
4) Is your content understood by your mum?
The above statement is an exaggeration, but it is crucial to be clear and explicit in your email nonetheless. And where possible, reply to all points in an email addressed to you. Imagine a chain of emails like the following about a web project
A (project manager): The interface .. something wrong. Cannot click somehow. The buttons on the top too.
B (designer): Interface? And buttons on the top too? Which page? All the time?
C (designer): Arent buttons part of the interface?
A (project manager) : I mean, there is something wrong with the interface. The buttons at the top. They cannot be clicked even after I tried clicking on it 10 times later.
B (designer): And what page is that at? Did you experience it all the time?
A (project manager): It is at the front page. Yes it happens all the time I tried for 10 times!
B (designer): I mean, even after you log in? or before you do?
C (designer): … lets just meet up.
The number of emails exchanged would have been reduced by half had the project manager been clearer and answered every question. The designer, B, too was guilty too but it is possible he was frustrated by the vague content provided by the project manager earlier too. Now, poor C has been copied in all these emails and has stepped in appropriately to stop the rot.
One final point: please do cache your emails on a personal folder where possible, if your mailbox has a defined amount of space. You will never know when you need to refer to these old forgotten emails!