Leaving My Company
Two months ago I left the company which I co-founded 13 years back. Here are some of my takeaways after 13 years as its CTO.
But first, an introduction.
Back story
We are a company focused on education technologies that improve the pedagogical aspects of learning in schools.
Throughout our 13 years of operation, we've taken on work and projects of different scopes. We started with software training for adults. Back then Photoshop and its ilk from Adobe, and Dreamweaver and the Macromedia suite of applications were the must-knows for image manipulation and Web development.
Business was slow. A year or two after we started, we reached an inflection point. We had to decide to wind up or to pivot to a different business scope. Being the young and full-spirited youngsters we were, we wanted to give entrepreneurship another shot before throwing in the towel. With a stroke of luck, through the relationship that one of the founders had with people from Novell, we got on board a programme to supply training services to public schools.
Back then, there was a strong emphasis on graphical programs and interactive multimedia as a result of the Ministry of Education (MOE) IT Master Plan. With the fortuitous early investment (of time) I made into learning the Adobe and Macromedia suite of programs (think Photoshop, Flash, Dreamweaver and the likes), I was able to conduct the courses that we pitched to the schools.
Thanks to our partnership with Novell, we were able to gain some traction with school trainings. As Novell had acquired SUSE Linux not too long back, we also had the privilege of introducing Linux to schools. It was also then that I really sunk my teeth into Linux. (Since then, I've switched to using Linux on the desktop exclusively. I'm very thankful for that chance to really learn Linux well.)
The margins from training were already slim back then. Competition was intense, coming from one-person shops to existing incumbents. We thus had to be opportunistic, grabbing all kinds of deals that came our way. Along the way, through Novell and other channels, we also got a few deals that involved server deployment - completely unrelated to education.
As the sole technical founder, I had to equip myself with knowledge of Linux server deployment to perform the actual deployment while also conducting trainings in schools.
When it comes to the choice of projects, we were really not discerning, all in the name of survival. In 2006 (I think), we even clinched the deal for technical support for the Nokia phones distributed to the attendees of the International Monetary Fund (IMF) conference in Singapore.
Google
Sometime between 2006 and 2008, we had our first contact with Google. At that time, they were located at Shenton Way where they took up an entire floor (or was it two?) in AXA Tower.
It was also then when we were introduced to what is now known as G Suite. We were early to the party. Being education focused, we were the first to introduce Google Apps, as it was then called, to schools.
We also became a reseller, selling Google Apps to commercial entities (the education edition is free of charge to educational institutes).
That went on for a while until we also became a Chrome Device Management license reseller with our own brand of Chromebooks.
Applications
Along the journey, we also created a plethora of applications:
- Chromeclass (software to manage student Chromebooks),
- Woma (workload management tool for Google Classroom),
- WebNap (cyber safety testing tool),
- Jotterlab (this name was used for different projects as we groomed and killed a few initiatives along the way),
- VLS (stands for Virtual Lab for Science),
- Trusted Network Extension (an IP tracking tool),
- GFlip (video repository for flipped learning),
- Ductbooks (a book delivery and management system),
- Edurious (a component of an learning management platform for low bandwidth environments), and
- Locus (a shared access terminal for Chromebooks with more controls than a Chromebook in Public Terminal mode).
Among these, a third of them were just proof-of-concept. One third of these is still being used by customers. The remaining are in the trash.
Unified vision
So that was the story for 13 years in a nutshell. When we started, there were four shareholders. When I left, there were only two key decision makers, including myself.
Probably as a result of having only two decision makers, some of my realisations were more palpable than others.
In order for a company to move as a whole, there must be a clear direction to move towards. In corporate speak, this is the company vision and mission.
If there is no consensus as to what the company vision and mission are, then the baseline mission is profit maximisation. The organization then behaves like an indiscriminate eater, gobbling up every piece of morsel that comes its way, regardless if it's toxic or nutritious.
In some cases, a one-off project with seemingly low returns, if any at all, may be necessary as part of an overarching strategy, to augment the company's position in the market. These projects are necessary evils, medicine that the company must take to further its business interests.
In other cases, such one-off projects with seemingly high (potential) returns may feel like the sweet flesh of low lying fruits but they draw the company's resources away from its core focus. In the best case, they are profitable distractions. In the worst case(s), they are loss-making adventures that hold the company back.
Gauging product market fit
Before committing to making a product, make sure that a good part of the market wants it.
We made the critical mistake of “surveying a market of one”. We didn't do enough market research to identify the market demand for the Web app we were planning to make.
Just because we hear the need from one or two potential customers, it does not mean there is a market demand for a solution. This statement sounds so obvious that it is almost redundant to state it. The problem is that we often fall to the trap of hearing only what we want to hear. When the person at the other end is in 100% consensus with you, it can feel like the whole world is in agreement.
One trick to identify this kind of conversation is when the person makes sweeping statements like “Oh, everyone will need this solution.” It is not so much the accuracy or correctness of the statement (because who knows for sure?) that is the problem but rather that such statements lull the subconscious into thinking that they are facts rather than opinions or guesses.
Ease of use trumps value proposition
The value proposition provided by an application must be a magnitude greater than the effort to achieve it.
I learnt this lesson from the same failed project that showed the importance of market demand.
The software was to help students become better essay writers by making incremental improvements to their essays through a methodology called “process writing”. With this methodology, students write several versions of an essay. Their peers and teachers can the review the essay and make comments on areas that need improving.
This all sounds good.
The problem is that we did not realise the amount of work required in this process, for both the students and teachers. From the perspective of students, writing just one essay is already a lot of work. To have them write the same essay more than once, in addition to their other assignments, is a tall order. Ditto for the teachers, whose workload is already too much. There is little to no incentive to use such an application.
Despite the premise of the program, it was simply too much additional work for the users. The project was doomed to fail at conception.
What it takes to make good software
Being able to rapidly prototype an application to validate an idea does not mean it is trivial to write good software.
Very often, in the quest for rapid development, developers have to take shortcuts. Such shortcuts may meet the project's current and immediate goals but are typically detrimental to its future development. Such shortcuts are known as technical debt.
Like financial debt, the more you take on, the deeper you sink. Without understanding this, it is so easy to fall into the trap of thinking that a software project is done once all the checkboxes are ticked.
Feedback loop with early customers has to be proactive and regular. A software product is almost always never done. There are always features to add, and bugs to fix.
The people who put money with you before you have any traction is trusting you with their money. There is a moral imperative to reciprocate that trust by making the product/service the best that it can be. If, however, you need to keep getting different projects then either a) the model of creating your own software is not tenable, or b) the project is not something that the market needs i.e. the project should not exist, and should be trimmed to make space for (allocate resources to) other projects that might have a better chance of succeeding in the market.
In conclusion
The company is now, and has been for a few years, stable and growing the Chrome business. We would not have imagined the hardware business making up the main chunk of the revenue, and yet, the company now stands as the Singapore's leading company for G Suite and Chrome technology in the education sector. With any luck, the company may still soar to greater heights in the right direction and focus. I wish for only the best to the company and my former colleagues.