This installment of the “31 Founders at Applied Intuition” blog post series delves into the process of building a company.
Once the decision has been made to start a company, the time comes to start building it. In this installment, former founders share some of what they learned as they began assembling the pieces.
Sales and Working with Customers: “I Should Have Been Talking to My Customers.”
For some founders, starting a company might be their first extensive exposure to customers and selling. For all founders, these are inescapable parts of the job, looming over everything a company does. The ex-founders recounted their experiences, lessons learned, and their recommendations for working with customers effectively.
What problems do they even care about?
He knew the problem. He knew the engineers were on board. What didn’t he know? That he had a disconnect with one critical audience. Two out of three was not enough.
“I noticed the people who would eventually sign off on such a deal had very different problems in mind,” said Fahrzin Hemmati, now Chief Operating Officer at Reviewable, who was hired as Applied Intuition’s second engineer and served as Head of Engineering.
Hemmati had been in close contact with the engineers on the customer’s manufacturing line, and they were in accord with the solution he proposed. He focused on the issues he and his team found significant, but did not realize the decision makers had different concerns. "I should have been talking to my customers much earlier. At a first level, just what problems do they even care about? I was going about it the other way. I had a solution and I was trying to connect it to their problems.
“Really I should have started with their problems and come up with solutions.”
It is not about the mousetrap
“As an engineer, I thought, ‘Oh, the technology sells.’ But no, it ALSO sells.’”
That strong technology is necessary but not sufficient was an epiphany for Roland Philippsen, currently Chief Product Officer for EthonAI. He was employee Number 4 at Applied Intuition and spent nearly five years with the company. He never set out to be in business, let alone start a company. He was a self-described academic—“for a long time” as he puts it—working in the field of robotics. With Google’s venture into that field, Philippsen found himself working at Google X. He later answered a headhunter’s call and started working at Applied Intuition soon after the company closed its Series A funding round.
“I'm so grateful for that,” he said. “I learned a ton about startups here, by working very early with the founders and their very early team.”
Part of that learning was about customers and the sales process. Yes, he learned that technology alone is not enough to close a sale. But there was more.
“It's much more nuanced. Another thing is being extremely meticulous about the sales process and attitude. When you're talking to customers, make sure that you understand them not only as a company, but also the humans you're talking to. What kind of role do they have in the company? What kind of motivations do they have in the company? How do you make sure that the sales pitch you're giving them resonates with the individuals in the room?”
Philippsen acknowledged that he’s not a salesperson. “But I've worked with salespeople who know these things. I know that it's required.”
Knock on the customer’s door—again
Sometimes, a delivery to a customer does not work out. Just ask Gaurav Bhatia.
“When you basically work a long time with one customer, and then suddenly the customer decides not to take you, I think it helps to understand that you didn't develop stuff just for that customer,” Bhatia said. “While you're doing that for the customer, remember that you're developing something that, if that customer disappears, you can now go to other people.”
Bhatia founded Ottomatika, which eventually became part of Motional, and he is now an engineering manager at Applied Intuition. He spoke of the confidence he now has to approach prospects even after rejections.
“A lot of times you feel like the customer, you dealt with them, we had a bad experience, or we couldn't deliver and the doors closed,” he said. “That's never the case. You know that you can always go back to that customer.
“In fact, it's much stronger, because they've already worked with you,” Bhatia continued. “You already have the door, you created the door, so you can actually go through it again. There's no problem. I can always go back to them—‘See, I have a better version.’”
“
At a first level, just what problems do they even care about? I was going about it the other way. I had a solution and I was trying to connect it to their problems. I should have started with their problems and come up with solutions.
Talk to the customer
It might sound basic, but this was a key recommendation from Greg Granito, an engineering manager at Applied Intuition, suggesting communicating by Slack, text, or any other means the customer might prefer, as frequently as possible. “So you can just say ‘Hey, we just shipped the new feature that you asked for. We'd love feedback on it.’ And so that way they're talking to a person rather than a company.”
Getting in the habit of building products quickly engenders confidence with the customer.
“They have a level of trust that they know that ‘they can do things fast, this is actually something that's difficult.’ And then giving them the context: ‘Hey, this is difficult because of this part of it and we're going to work on it. It's a priority for us, but this is why it might take more than a week. It might take two or three weeks to get it to you.’
“You don't want to be an opaque box that spits out things. You want to be a transparent box that they can see into and really feel like you're on their team, solving this problem for them.”
On Hiring: “I Made One Hiring Mistake. Well…More than One.”
Ask anyone why they launched a company and the answer probably will not be, “Getting to hire people.” Yet finding good talent is part of the job if a venture is to thrive—a company’s biggest expense is almost always people, and to execute successfully requires having the right people.
“It was sort of weird.” That’s how Granito described the hiring responsibility during his startup experience. Not yet 20 years old he was prodded to hire a significant number of employees. He describes that process as “interviewing a ton of people, a bunch that were older than me, a bunch that were [wondering] ‘who's this kid that's interviewing?’”
The former founders had a lot to share on their hiring experiences, including a few surprises. What was not a surprise? Harnessing the power of personal networks.
“My best hires were actually from a good network of entrepreneurs and founders,” said Yaser Khalighi, an engineering manager at Applied Intuition. “And those are the ones that built a lot of good products for us.”
Efficiency in the hiring process was another priority for Khalighi. Startups and small companies typically do not have the luxury of large—or any—recruiting teams, and the startup teams need to focus on creating and delivering products, securing early customers, etc. Processing the deluge of resumes startups can attract, and making sure not to miss the top talent, can be tough. Khalighi came up with his own approach, which did away entirely with the typical first step: the interview.
“
Who's this kid that's interviewing?
“Every week we would go through around a hundred resumes,” Khalighi recounted. “And then instead of actually doing in-person interviews—we didn't have time—we would just send them a coding exercise. They would do the coding exercise, and then it would take any of our engineers probably five minutes to see if they passed that first hurdle. So, we essentially optimized for the minimum amount of time on our side to vet the candidate.” With such a small team they needed to avoid spending too much time filtering a wide selection of candidates. “We wanted to focus on the bottom of the funnel.”
Candidates reaching the bottom of the funnel were rewarded with a 3-hour on-site session, after which the decision would be made whether to bring the candidate on board. Not surprisingly, the process reflected an engineer’s approach, grading candidates from zero to 100 on relevant attributes.
“For each role we had the ‘must-haves’ and the ‘good-to-haves.’ So, before the interview we knew exactly what we were looking for. Everybody that was interviewing actually had to grade on each of those components. After we did the interview, immediately we would get together and then review our notes and then give a score. And after the interview we would just actually be very metric based—should we hire or not hire?”
Contrary to what recruiters and job descriptions usually say, experience did not matter much to these ex-founders. Granito said that just from doing enough hiring you start to notice patterns.
“I found that over-indexing on cognitive ability and motivation ended up being the thing that separated the best people from everyone else,” Granito said. “People who had experience…the experience wasn't worth as much as you thought it was. Experience could be really good. If you find someone who is really smart AND really driven AND they have experience, that's great. But if you ask me to get rid of one of the three, I'm going to get rid of experience.
“Just in my own career. I've switched industries four times in 10 years, and the domain knowledge is definitely helpful,” he added. “But also, you can pick up domain knowledge really quickly. I find that within a year of working in an industry you can pick up 70 percent of what someone who's been there for five years knows. The 30 percent ends up being more nuanced. Sometimes it's really critical, but oftentimes it's not.”
And sometimes it is not the relevance of an experience that matters, but its diversity. Ryan Brigden, an engineering manager at Applied Intuition, tells of a hire whose background, on the surface, could not have seemed less appropriate. In the early days of the company, the team was bringing in new members they had known from their times at Carnegie Mellon University, or other friends.
“One of the most interesting people that we brought on was literally a family friend of my co-founder, and was a nursing student at the time,” Brigden recalled. “Extremely hardworking—smart, smart guy. It was like, ‘Let's bring you out to the Valley and you're going to run operations.’ He was someone who didn't really have too much of a technical background, but was probably one of the strongest people I've ever met. Could get in there, make friends, and not seem like a stuck-up engineer. He would go into the retailer, work with the employees, get everyone on board with using the product, and really understand a lot of the problems. He would figure out exactly what were the efficiencies that were not there. That was a super-effective hire early on.”
With all the effort put into hiring, mistakes still happen. Sometimes the problem is not in the who but the when. As in starting too late.
“
Hiring is not something that you just turn on a dime. You have to build the pipeline and continuously get people excited, and that also really helps with your fundraising. I think that was actually probably one of the bigger failures.
“It was always, ‘Once we have some traction, then we'll start to really scale the team,’” Brigden said. “Looking back, hiring is not something that you just turn on a dime. You have to build the pipeline and continuously get people excited, and that also really helps with your fundraising. I think that was actually probably one of the bigger failures, not having a more consistent hiring pipeline.”
“I made one hiring mistake—well more than one hiring mistake, but one that I really remember,” Khalighi recounted when asked about hiring misfires. “The person did actually quite well on the technical, but then after the negotiation was done and I announced that ‘OK, you're hired,’ I just didn't see any excitement. I mean verbally the person was excited, but I felt like ‘OK, there's something wrong.’ That person did technically well, but it was really painful to work with them. We had to manage that person out. And what we learned is to respect the metrics, but if there is something wrong, or if there's something alerting, dig deep into it.”
Khalighi took a pause during his recollection.
“When that person finally found a job and gave notice, I went out and treated myself to dinner.”
Short-Term vs. Long-Term: “Hack it Till you Make It.”
A constant for startups: Balancing the tension between short-term necessities and long-term ambitions.
“You're working at a company that you hope is going to be around for a long time, but you need to make decisions to allow it to survive in the short term,” Ryan Brigden said of that tension. He cited some of the questions that an early-career founder, who is likely recently out of college and from primarily a research background, is likely to ask. What is the proper system to build in the long term? What is the right kind of system? What are the perfect touch points?
Startup survival overrides those questions quickly: “The first thing you’ve got to do is strip down to the minimal set of requirements.” Brigden illustrated this with a story from his time developing the cashierless payment system, with a deployment in a specialty grocery store. Part of the system requirements was the ability to distinguish between different products, for which they created a short-term approach so they could launch and give the retailer the required accuracy. But one of the system requirements—tracking individual shoppers—was more challenging.
“From a long-term approach…one of the most difficult system requirements was tracking identities to the store. That's where we actually spent a lot of engineering time, and that's actually engineering costs. As you're burning money when you're at this stage, you're thinking weeks. Every week is another amount of your life blood draining out of the company, so it's important to identify ‘What are the couple things that are most important to build and get right?’”
“What perfect would have been”
There isn’t always time for perfect.
“We were very much focused on the immediate business needs and we didn't have the time or the bandwidth to necessarily implement the perfect version of things,” Fahrzin Hemmati said of wrestling with short term vs. long term. “The way I went about it was I made sure that myself or the engineers who were designing things had an idea, if not a proper design, for what it should be. What perfect would have been. But then from there cut corners, and I came up with something that would work in the short term.”
How about working in the long term? “We effectively had a roadmap for what it should be.”
“You can get away with stuff”
What is needed now? As in RIGHT now?
“You can get away with stuff. You can get away with things like, ‘Let's just bring up an instance of a server for every customer.’ Because when you have a dozen customers, it doesn't matter,” said Joe Moster, a software engineer at Applied Intuition. “If you're going to scale to 200 customers in the next three months, maybe you want to rethink that. You probably don't want to have one server for every consumer that's giving you five dollars a month. That’s debt you can't pay down because you're going to hit that number very, very quickly.”
Delivering in the near term is not just about hitting milestones and staying on schedule. It can also be about survival.
“
Every week is another amount of your life blood draining out of the company.
“At any point in there if we'd said, ‘Hey, let's slow down, let's delay the release of this feature so we can make it more scalable,’ that would have been what, maybe one fewer customer? That could have delayed a fundraise,” Moster said. “Delay of a fundraise could mean you don't get the fundraise. If you're slow, if you take your time—‘let me go rewrite this code, I think I can make it 10 milliseconds faster’—you might not get the opportunity to hit that scale.”
Similar sentiment comes from Greg Granito. “Just build for your current problem, and then solve the next problem,” Granito said. “Let's say you build something that will only scale to a hundred users, or a thousand users, or whatever the number is. It's usually not worth it to plan for 10 thousand users on Day Zero if you really aren't going to have that many for a long time. Just fix the problems as they pop up. When the scale becomes a problem, then I like to say 'You've earned the privilege of making it better.’ Because in the beginning you don’t have the privilege of doing things perfectly because your bigger, existential, risk is that it just won't be good.
“We would often use the phrase ‘that would be a good problem to have,’ he recalled. “Whenever someone would say something like ‘What about this?’ you’d respond, ‘Yeah, that'll be a great problem to have.’ And then, ‘Okay, cool, let's wait till then.’”
Yaser Khalighi reflected on this topic and summed it up succinctly: “Come up with an idea. Sell the idea. Hack it till you make it.”
Bravado has its benefits
Having a little bit of swashbuckler in them can help founders when it comes to sales. “You have to have a certain confidence in being able to build something on short notice,” said Roland Philippsen. “Such that when you promise it to somebody—even though you don't have it—you'll be able to deliver if they bite.”
And for delivering the product. “From the engineering side, I learned that you do need to be willing to cut corners. I think it's better to cut a couple too many corners, rather than be shooting for scalability too soon.
“Because if you never reach that scale, you will have wasted your time. The opportunity cost is just huge.”
Evolving Technical Skills: “Work with People Who are Better Than You”
Doing something for the first time involves acquiring new skills, and starting a company is no exception. While founders spend time up-leveling their skill sets, how do they remain current on the skills that got them to this point?
“It can happen kind of two ways,” is how Joe Moster described the phenomenon. “One is you have management responsibilities. All the stuff that I'm now studying is ‘How do you run a business? How do you work with people?’ But the other thing that can happen, and I think this is very broad, is you get too pulled into a very specific niche. Your view of the technology world is very, very focused. Which is what you need for your job.”
Moster described some of the steps he took to refresh his skill set. He took online classes, not always finishing the course but learning enough. He participated in hackathons—“72-hour competition and just code up a really hard problem.” There was no concern about optimizing the outcome since it needed to live for only three days. “But you can get some really, really rapid learnings that way.”
Perhaps part of the skill gap conundrum lies in the nature of being a founder and having to spend time on new functions and tasks. On activities that are different from those that the founder already knew and performed well, and which positioned them to start a company in the first place. For which there is no longer as much time.
Nip that in the bud.
“
You’re going to be smarter than other people in the room in certain categories. But you better not be the smartest person in the room for ALL categories."
“You just got to be deep in the weeds,” said Adriano Quiroga, an engineering manager at Applied Intuition. “You have to understand what people in the team are doing. You have to understand, to a degree, how to DO the things that the people in the team are doing. You might not be able to actually do it as fast as they, but you generally want to have a good direction of how to do it.”
Another tip: Do the work. Staying up to date and evolving technical skills is accomplished by doing work, in any form it takes. “Doing the work can mean you're actually doing the coding, or creating the spreadsheet, or you're doing the presentation, or you're getting in front of customers, you're doing the sales meeting,” Quiroga said. “Actually sitting down and doing the work. Super important.”
Starting a company takes time, and prompts founders to look for ways to save time. One way to do that when keeping skills current is to leverage insights from others and learn from the people around you. Quiroga joked that the trope of being the dumbest person in the room applies here, but in offering a cautionary note pointed out some nuance behind it.
“You’re going to be smarter than other people in the room in certain categories,” he acknowledged, “but you better not be the smartest person in the room for ALL categories. You can always find things that you can learn from each other.”
Anyone starting a company is busy, and finds it hard to keep up their skills. Some in that situation look at the glass as half full. What did Amir Shah do when he thought about how to stay current?
“One of the real reasons that I went into starting my own company was because I felt like I was getting stale in some areas,” said Shah, today an engineering manager at Applied Intuition. “I wanted to get much more hands on. I started as a systems engineer at Lockheed Martin for basically the entirety of my career there, so very little hands-on software engineering work, although that was something that I was quite interested and passionate about in my college days. I was interested in staying current, and so that was one of the big reasons why I thought this was important for me to do. And as the CTO I was able to choose what I wanted to work on.”
The challenge of maintaining current skills will not go away, but tackling it will probably take different forms in the future. Taking a look down the road, Moster mused the way knowledge is gathered is unlikely to remain static. “The idea that we still need to learn, kind of the first principles, the fundamentals of things, I think will always be there,” he said. “If you go to school to learn, you can still do basic things. But you’re a step behind where the latest and greatest is.
“Is that good? Is that bad? Ask me in 10 years.”
.webp)
.webp)
