Simba speaking in front of a crowd at UC Berkeley Skydeck's Demo Day

Lessons Learned: From Google to Building a Profitable Startup

Simba Khadder
August 12, 2021

Hey everyone, I'm excited to share that I'm starting a new journey founding Featureform! A lot has happened that got me to this point, and I find myself telling stories to new founders or soon-to-be founders who reach out for advice. As I embark on this new journey, I wanted to publicly share the hard earned lessons I received along the way.

I left Google in 2017. I wasn’t able to push myself as hard as I wanted to in such a large company. Alongside Ryan and Billy - friends and hackathon partners, I quit my job and moved up to SF to start a company. We didn't even have an idea yet, but we knew that we needed to keep pushing ourselves and seek out a fast-paced environment. We didn't have much in savings, but we  found a three bedroom and stuffed eight people in it. Space was in such short supply that we literally built a wall in the living room to make another room. We drove Uber, walked dogs - anything to make ends meet.

I loved it. We spent most of our days cold emailing people and taking as many meetings as we could. We wanted to learn. We started to see some of the same problems over and over in B2C subscription companies, and felt there was a product to be built. Not long after, Triton was born. We managed to bootstrap Triton to a profitable company that processed data for over 100M monthly active users. Though the company was profitable, it wasn’t growing quickly. We felt like we were plateauing both as people and as a company. In the end, we made the difficult decision to shut it down. Afterwards, I started a new company, Billy went on to do his PhD in environmental diplomacy, and Ryan went on to become a Head of Product at Wikipedia.

In those five years, I’ve learned innumerable lessons about sales, engineering, starting a company, and about myself - and picked up more than a few funny stories along the way. I want to share some of them with you.

The Triton Founding Team: Billy, Simba, and Ryan

Sales

Don’t “engineer” early sales

In sales, building a relationship allows for more room for error, and allows you to find product-market fit faster. As cliche as it sounds, early sales is all about relationships and the “little things”, and for an engineer, that can be tough. Before Triton, I spent years wiring my mind to break down problems like an engineer, and my first approach to sales was influenced by this experience. I wrote down all the problems I assumed our product solved, and I would list them all to every prospect I spoke with. They would rarely care. We hadn’t spent enough time figuring out product-market fit. In the cases where our product resonated at all, we would end up annoying the prospect by acting like robotic sales people. Conversely, my co-founder Ryan was naturally amazing at sales. Once, he spent an entire sales call talking about everything except our product. He told me how he and the prospect’s nephew had gone to the same high school and had a shared interest in surfing Ocean Beach. At the time, I was a little annoyed. I didn’t know how sales worked and I felt like this was a waste of a call. Later, that same prospect explained to us why they didn’t have the problem that we solved, and that he didn’t think it was the right problem to be solving. However, he offered to connect us to a few VPs at other companies to get more data points. Later, he even signed a small consulting contract with us to allow us to work on their data and learn from it.

It’s not over until a contract is signed

Once things are moving, your job as a salesperson is to shepherd it to close. I learnt this lesson the hard way when Triton lost a six figure deal at the last moment due to a re-org. We had been working with a prospective client for months. We had put together a full case study and shown a huge incremental increase to their conversion rate. To strengthen the relationship,I had flown out multiple times to meet them in person. I thought all was going well, but one of my advisors told me to get a contract signed ASAP. We sent it over, and started the implementation process. They knew they needed the product, they had the budget, and they were now putting it onto their website. I didn’t follow up for a few weeks on the contract as I got busy with other things. Then, the CEO left the company and the budget froze. A few months later, a new CEO came in and reorganized the company. They moved our main points of contact around and revamped their budget. They never signed the contract. It doesn’t matter how far into the negotiating process you are - a deal isn’t a deal until it’s signed. If you don’t or start getting lazy, you’ll get a big wake up call like I did.

Don’t be afraid to ask the hard questions

Building strong rapport with prospects is essential. As counter-intuitive as it sounds, having strong rapport can also make you afraid of asking hard questions. When I felt like a sales cycle was going well, I didn’t want to be too pushy, piss off the prospect, and jeopardize the deal. I wanted to keep the status quo, and explain away why the sales cycle wasn't moving forward. In reality, a never-ending sales cycle is far worse than a lost deal. It gives you false hope, and keeps you from continuing to iterate. Sometimes, you have to force the issue.

Back in 2019, I was working a large deal with a F500 company. Their VP of Product loved us, and kept telling us how Triton’s personalization API was a game changer for them. He’d been telling me this for over a few months, but I couldn’t get him to commit to anything in writing. There was always another blocker, another week to wait. Finally, on a trip to NY I met him for dinner. I printed out a copy of the contract and brought it with me in my backpack. After dinner and a lot of chatting, I pulled out the contract and asked him why he won’t sign this right now. He finally told me what was holding him back: Though he believed in the power of personalization, the only thing that mattered to the company was driving more subscriptions. They didn’t know why users subscribed. There were so many touch points from when they would first see a user to when they would subscribe. They wouldn’t be able to decipher how much lift we gave them, and many teams would try to take credit. If the CEO asked him why they were spending so much on Triton, he wouldn’t feel comfortable defending it.

I offered to build him a model to fractionate the importance of each touch point in a subscriber's buying cycle. That changed everything. He told me that if we could do that, he would sign right now. 

This interaction showed me that we were solving the wrong problem. We pivoted not long after this conversation from personalization-as-a-service to a subscription intelligence platform.

Finishing an escape room with Sterling and Ward from our Product and Engineering team at Triton
Finishing an escape room with Sterling and Ward from our Product and Engineering team at Triton

Product

Build solutions not technology

As a founder, your goal is to get value to customers as fast as possible. If you do that well, you'll be able to get to the point where you have enough engineers and person-hours to actually build the final product. When talking to investors, prospects, and potential hires, we spent a lot of time talking about our cutting-edge technology. We’d go in detail about how we used deep learning to build a generalized recommender system. In reality, customers don’t care how things work in the background as long as we’re providing the value we promised. For most of our first clients, I would hand tune their models. There are many examples of “AI” companies hiring people to perform AI tasks. Though it sounds silly, it’s often well worth doing. Unless you’re in a true deep tech company, you can assume that anything you need built can be built. 

Your engineers should know your customer as well as your sales reps

Bringing engineers into the product development process is crucial in early-stage startups. I once came back from a conversation with one of our biggest customers who had tons of feedback on our dashboard. I went back to our engineering team and described how we should change the dashboard to meet the customer’s needs. Afterwards, one of our engineers pulled me aside to express his frustration. He vented how I had told him to build another page three weeks ago, and today I’m telling him to scrap it. I explained how this is the reality in startups, but that didn’t ease his frustration. I took some time to think about it and realized why we weren't seeing eye to eye on the issue. As CEO, I understood why decisions were being made, but our engineering team only saw a bunch of randomly changing requirements. From that point on, I focused on bringing our engineers into every customer conversation possible. Where that wasn’t possible, I would share as much substance from the conversations as I could.

My original goal was to avoid frustrating our engineering team, but we achieved much more than that. Now that everyone was talking with and listening to customers,they were coming up with product ideas. They were evolving the product to solve customer problems without my direction. I almost didn’t have to manage them, as they took ownership of their parts of the product. Each engineer had effectively become their own PM.

Build the 20% that drives 80% of the value

As engineers, we love to build, and we will build way more than they have to. Startups are about providing the most value possible with our limited resources. In most products, 20% of the functionality provides 80% of the value. As a startup, one of the best decisions we made was to build out that 20% - the highest value features - first. 

In an early version of Triton, we spent the majority of our time building a model that broke down why users subscribed. We spent as little time as possible on the UI. We used to send a weekly email, then we added a slack integration. Finally, we spent $10 on a pre-built HTML/CSS framework for dashboards. It looked generic, but our customers didn’t care. They didn’t pay us because of how beautiful our dashboard was. UX and the design were valuable for us, but we focused on things that really moved the needle. Later, when we grew the team, we built the dashboard from the ground up because the return on investment made sense. If we had focused our time on UI, and not on subscriber predictions, at the beginning, we almost surely would have failed. By focusing exclusively on our core functionality, we got it right. Then, we could afford to build around it. By staying at 100% capacity, and focusing on the most high-leverage features, we were able to maximize the value that our team could give to our customers. The building never stops, but prioritizing correctly is the difference between failure and success.

Hiring

Don’t rush to be a “CEO”

When starting a company, people become infatuated with the idea of being at the helm of something big. I've seen so many founders rush to become "CEO"s and hire people to put themselves in a management role. This doesn’t work. One advantage you have in the early days is that you, as the CEO, are directly contributing. You’re working on the product, doing sales calls, and more. This gives you a direct line into what's happening with the company, and allows you to be nimble. Over time, you hire people to take on and improve the things you’ve built. 

One common trap is hiring sales people too early. In the early days of Triton, we didn't know much about sales, so we decided to hire one of our friends who was a salesperson at another fast-growing startup. By no fault on his own, he fell flat on his face. Why? Because we had no product-market fit to speak of, we weren’t ready for sales, and we should have doubled down on customer discovery. We thought that hiring a salesperson would magically close customers, but we didn’t have the product-market fit to justify a sales hire. 

A large part of the reason that companies buy technology from startups is because they have a personal relationship with the founders. Simply put, they trust them. That trust enables customers  to take on more risk than they would if a junior sales rep made the pitch instead. A CEOs role changes constantly, but in the early days, developing deep trust with customers is existential.

Hire people for their potential

Everyone now and then I meet someone who I know will become the best in whatever they chose to do. These are the people I hire - it’s the one thing that’s not negotiable. Startups grow very fast, and when people don’t grow at the same rate, it drags the whole company down. There's a reason that early employees at great companies typically go on to start their own successful companies. 

 Ryan, a Triton co-founder, went on to become a Head of Product at Wikipedia. I felt amazing that Triton gave him the platform to get there. Great people will use a startup as a tool to put their all into, and they’ll reap the rewards as a result. The CEO’s job is to convince these great people that their company is the right one  to pour time and energy into.

Hire owners not workers

Once companies raise angel money, they tend to hire a ton of interns and cheap contractors. This sounds great in theory, but it often fails miserably at early stage companies. The thing is, the more people you have, the harder it is to share information and be nimble. On top of that, it takes up a ton of your time as CEO just to manage everyone. As the CEO at the earliest stage, the more time spent on things that directly move the needle, the better - and managing interns probably isn’t one of them. Don’t rush to be a “CEO”. 

To this day, I give new employees a very small scope of ownership, but I make it clear that they own everything in that scope. As they develop, the scope increases. Over time, and with the right access to customer conversations, people can start making the best decision for the company in parallel. Everyone understands where we’re trying to go, everyone is smart and capable, and everyone is empowered to make their own decisions. It drastically cuts back on meeting time and allows more productive work to get done.

Kayaking in Sausalito with Shab, Featureform's Head of Operations
Kayaking in Sausalito with Shab, Featureform's Head of Operations

Entrepreneurship

Only two things matter, iteration speed and stubbornness

I recently caught up with a friend who sold his company for billions of dollars. He offered to angel invest in our new company, Featureform, while it was very much an early idea. He’d known me since I worked at Triton, but I was caught off guard that he offered to invest so early. He told me that he saw the two attributes that led to startup success: iteration speed and stubbornness.

I thought a lot more about this later and realized how right he was. If I wasn’t stubborn and refused to fail, Triton would have died years ago. Startups are way too hard and often feel like they aren’t going anywhere until they suddenly are. Yet simultaneously, if we hadn’t been nimble, and constantly iterating towards product-market fit, we would have failed no matter how stubborn we were. I keep that in mind as I hire because, eventually, high iteration speed with a team of people who refuse to fail results in success.

Ask the right questions

A good CEO knows how to ask the non-obvious questions that provoke a high-value response. They ask questions that don’t have an obvious right answer, and in doing so, force you to reveal something about yourself. 

I remember selling Triton to a media company in LA. We had buy-in from multiple VPs across the organization. The final conversation was with the CEO. We spoke for thirty minutes, mostly small talk - and he only had one question for me. “Simba, is this gonna work?” It caught me totally off guard, and I answered truthfully that I thought it would and that I personally would do everything I could to make it so. He signed that day. Over time, I found myself asking similar questions to a lot of success.

Give it two years, It’s a marathon, not a sprint

Most companies that look like overnight successes took many years to even get off the ground. Take Slack: It took a team of repeat founders over four years until they finally pivoted to something that became a huge success. I started Triton when I was 21, and had the illusion that within six months we would be off to the races. Little did I know that six months later we would be pre-revenue and in desperate need of  product-market fit. It takes two years until things start to get good in SaaS, and you will commit many more years of your life if you do end up being successful.

Why I do this

Building a successful startup feels like setting a goal to win a gold medal in the olympics. It’s an almost impossible task that takes everything from you. Even when you aren’t working, it’s always there, in the back of your head. I love it. If I didn’t, I would have quit a long time ago. There are much easier ways to make money than starting a company. It comes from a drive, the feeling that I have to give it my all and to become the best version of myself.

I started my first company because I felt that I was plateauing at Google. I started my second because I felt like I was plateauing in running a profitable, though slow-growing, B2B business. I had the option to sell multiple times and make a good chunk of money and get an awesome job at a larger company. The thing is, I wasn’t ready to do it then, and I’m not ready to do it now. I want to keep running at 100% for as long as I can, and see what I can achieve. What does the best version of myself look like? Starting Featureform wasn’t a financial decision, or an ego-driven one. Starting Featureform was a personal decision to push myself to the max, and see how I come out the other side. There’s nothing else I’d rather be doing.

I look for this trait in people I bring on the team. I’m looking for people who are driven by self-growth and want to see what they can accomplish when given the opportunity to give it their all. If that sounds like you, please reach out or apply on our careers page. I’d love to chat.

Related Reading

From overviews to niche applications and everything in between, explore current discussion and commentary on feature management.

even more resources
blue arrow pointing left
blue arrow pointing right