What I Learned From Building and Exiting 2 Companies - by Snehal Patel with permission

I'm fortunate to have built and exited 2 companies - most recently Sokikom, an online multiplayer math game, acquired by Jumpstart World, a subsidiary of the Chinese public company Netdragon Websoft. Previously, I started and sold a math tutoring company as the top performing franchisee for Mathnasium. Ever since the Sokikom acquisition, I've been taking some much-needed time off to travel, spend time with family and friends, play video and card games, and catch up on Netflix. The time away from building a company has given me the opportunity to reflect, learn, and grow.

In both my companies, I've been lucky enough to experience success in a variety of areas including: developing an award-winning product; raising money from noteworthy investors like former CEOs of Intel, Charles Schwab, and the cofounder of Zynga; winning more SBIR (Small Business Innovation Research) grants from the U.S. Department of Education than any other math program ever; building and getting to work with a world class team; doing a TedX talk; getting invited to the White House twice and receiving the prestigious Tibbett's award. On top of that, our math program was used in over 60,000 classrooms from all 50 states and 120 countries. Hundreds of thousands of students used our program and collectively completed more than a quarter of a billion math questions. I could continue, but you get the point.

At the same time though, I've encountered even more challenges, some of which were the result of stupid mistakes I made. Each mistake emanated from an incorrect decision where I expected something to happen, but in actuality, it didn't - resulting in a lesson learned. Before I get into the actual lessons learned I think it's useful to share one of the decision-making frameworks I use.

People working at startups, e.g. founders, CEOs, CTOs, VPs, etc., all make tons of decisions each day. Some decisions are trivial and are made unconsciously, for example: I'm thirsty, so I'm going to take a sip from my water bottle or walk to the water dispenser. Other decisions that are important require deliberate thinking. For example: One of my employees might be stealing, how should I handle that? Or, we're not seeing the traction we had hoped, what should we do? I wanted to get better at the way I made important decisions, so I started documenting them and looking at the expected outcome vs. the actual outcome. In turn, I became more aware of the decision-making rules I was operating under and whether they were working or not. Let me explain. When I make, or choose not to make - through inaction - important decisions, three factors go into each decision:

    Environment, i.e. what's the situation, background, and what people or factors are affected?
        Decision, i.e. what I decide to do (or not do).
	    Expected Outcome, i.e. what I expect the result to be.

Together, these turn into a hypothesis like the following: Given E (environment): If I decide to do D (decision), then the result should be EO (expected outcome).

Later on, I would compare the EO with the AO (actual outcome). My hope of course, is that the AO is as good as, or better than, my EO. However, this isn't always the case. When the AO was worse than the EO, I asked myself if I would do anything differently if faced with a similar decision again. If so, I created a principle (i.e. lesson learned). So far, I have over 50 principles that I review and refine over time. I should point out that my approach is by no means novel. I was inspired by the mental models presented by a few key people. Notably, Ray Dalio in his book Principles, Peter Drucker in Managing Oneself, and Warren Buffett's Tap Dancing to Work.

Now, back to some of the stupid mistakes I made. A few of my lessons learned had to do with market (i.e. customer) validation. When I was in the early stages of Sokikom, our team was laser focused on developing the most engaging and effective elementary math game in the world. We wanted to develop a math program so fun and engaging, even students that hated math would want to play it. At the same time, we knew the program had to be more effective at increasing students' math achievement than traditional textbook curriculum. Given the state of poor math education (Environment), I believed if we could accomplish this (Decision), the market, i.e. schools, would gladly pay for it (Expected Outcome). I was wrong.

Even though we practiced lean startup principles and agile software development, we hyperfocused on one group, elementary students, which was an error for our market. We spent nearly 4 years developing and optimizing the student experience before generating any revenue. It took longer because we had to use a methodical, research-based approach according to the SBIR (Small Business Innovation Research Grants) we won. Nonetheless, it makes me cringe now just thinking about how long we spent before making any sales. During that time, we conducted over 100 student usability tests, mostly in classrooms, which led to a product that improved math achievement and elementary students loved. However, students didn't pay for it and we didn't sell the product during the development period. Similar to other early stage companies, I was concerned the product was premature and too early to sell. That decision cost us dearly.

We discovered the real buyer of our product wasn't teachers or even school principals. Rather, it was curriculum leaders at school districts. Consequently, the needs of the curriculum leaders were very different, and in many cases, directly conflicted with features we spent years developing for students. For example, we meticulously developed an exploration-based student interface that encouraged inquiry and allowed students to learn at their own level (screenshot of main interface below). However, most schools use standard curriculum adopted by curriculum teams at school districts. This standard curriculum required teachers to go through a certain amount of content in a given period - regardless of whether all students understood it. This directly conflicted with much of our system's design. Furthermore, school district curriculum budgets used to pay for products like Sokikom had specific requirements regarding curriculum standards, sequence, testing, and grading, among others.

Eventually, we went on to meet these requirements and generate millions in sales from school districts. We developed new features to address the buyer's needs and ultimately, a completely new product yet to be launched. However, it was super expensive, wasteful, and slowed us down tremendously. Had I steered our team to validate the customer needs earlier, we would have known who the real buyer was and their core needs. As a result, we would not only have developed a different product, but saved precious resources testing invalid business models and strategies. Based on that experience, I formulated the following principles:

It's important to note that Sokikom sold to school districts, i.e. government, which are a unique beast in and of themselves. If you're working at a business-to-consumer (B to C) company that monetizes via ads, things are going to be very different. In most other companies however, I believe these principles still apply. I advise a number of early-stage companies and this is one of the big things I emphasize with them. I hope these principles will save you time and money from pursuing unmonetizable businesses. As I shared earlier, I have developed over 50 startup principles that I review and refine over time.

Stay tuned for more in Part 2...

Go To Angel

Copyright(c) Fred Cohen, 2018 - All Rights Reserved