Philip Thomas went to school for applied math and physics. “I fell in love with operations research. I remember the moment with clarity. We had these four soldiers who taught the class and they were always explaining real math applications in the military. ‘How do we determine where to route gear? Who gets fuel first?’ Just really fascinating problems that made academia seem practical.”
But it was when Philip stumbled upon a paper from Taco Bell that he was exposed to operations research in restaurants. “The paper was old. It was from the 90’s. But it discussed models for queuing and how opening and closing registers would impact. It even delved into real wait times and perceived wait times, and why that mattered.” The paper stuck in Philip’s mind as he worked in coffee shops throughout college and even helped him with his senior project.
“With all my work exposure I thought it would be good to marry academia with what I knew. I ended up creating a model that would optimize labor for small businesses. It seemed to me that labor was a huge business expense but managed very poorly.” Philip wouldn’t touch the model again for a few more years.
After a job in finance upon graduation, Philip packed up his bags and headed to software mecca: Silicon Valley. He landed a job a OpenDNS, where he served as a software engineer. “Even though I had this nice job, I was still living in what would be equivalent to a flop house. It was called a ‘hacker house’ to seem cool, but it was a real dive.” Philip talks about how the landlords, one of whom was a former lead on the Google self-driving car project, had converted an old church into barely passable living quarters with bunkbeds stuffed into every corner.
“It wasn’t all for naught: being in the hacker house exposed me to people who wanted to build tools to solve problems. In fact I had learned operations research in GAMS (an expensive and proprietary data programming language) and learned about an open source alternative called Julia from my roommates.” Philip soon discovered there was more than one way to skin a cat, contrary to how most academia teaches software, and rebuilt his senior project in Julia.
Philip met Jeremy Cai, the 19 year old founder of OnboardIQ (now Fountain.com), through a founder Slack group. They were selling HR software to startups in the on-demand space, and many of their customers needed scheduling software. Philip saw an opportunity to put his model to work. With a highly manual approach, Philip began scaling up a list of food courier customers on nights and weekends. “All these on-demand companies were getting funding but they had no way to scale up and manage their scheduling. I remember one of our early customers was doubling every week. They would email me what they needed, I would tinker on the model and email them back a schedule. The market was definitely booming.” Philip thought there could be something here so he slipped in an application to Y Combinator, the prestigious Silicon Valley incubator that’s more selective than Harvard, for a new program they were testing.
Three things happened then that changed Philip’s trajectory.
The first was that OpenDNS, Philip’s employer, was acquired by Cisco. The second, as Philip had observed, was the explosion of on-demand hype. And the third: Philip had been accepted to Y Combinator (YC) for their inaugural Fellowship program. “It became pretty obvious what we needed to do at that point.”
Philip jumped into YC with both feet and went to work full-time on what was now known as Staffjoy. He and his cofounder built out the app over YC’s 2-month incubation period, scaling up customers as they went. “We had some initial success in on-demand markets and then we started exploring call centers and other business types.” With a growing number of pilots, Staffjoy hired their first head of sales and raised some money.
Yet something didn’t feel right. Pilots became hard to convert into customers, customers didn’t stick around all that long, and Philip and his team realized something. “It became very hard to scale our algorithms across all these business verticals. It’s almost like each business had these fringe cases that required customizations that made them wildly unprofitable and unscalable. We either had to go after large customers – which takes too long to do on a startup budget – or change our customer profile.”
Philip recalled the Taco Bell paper and his time in coffee shops. Staffjoy would focus on brick and mortar.
Shadowing restaurant owners, Staffjoy set out to build a v2 focused on the restaurant industry. “Restaurants had a massive communication problem. They still used pen and paper. There was a ton of misallocated labor. We built v2 to text schedules to people and I would go door-to-door selling the solution. I joined Meetups, local organizations: anything to get in front of restaurants. We even tried blogging and podcasting about the industry, hoping that a featured restaurant owner would tell their friends and they would join our platform.”
The goal was ultimately to do POS integrations. “We tried an integration with a major POS system since that would make getting labor data easier; it would allow us to sidestep the nasty work in spreadsheets.” Of course, the integration didn’t pan out (which we might have predicted).
Staffjoy also started receiving feedback from the restaurant owners. “For starters, our email campaigns had a 0.1% conversion rate. That might have subtly told us something.” As a point of reference the average passive SaaS conversion rates are pegged at 7%, with qualified leads converting around 25% of the time. When we asked Philip why he thought the conversions were so low he told us that, “well, restaurant people just don’t respond to emails. Take that for whatever it’s worth.”
Other problems became apparent. “Getting the right decision makers at chain restaurants proved troublesome. Even if we could get someone on the phone – which would take forever – they didn’t really know who would make the decision for this software.” Then Staffjoy was confronted with the most enjoyable restaurant truism of all.
Restaurants are more interested in making money than saving it.
As reliable as the “you’ll shoot your eye out” tagline, restaurants have made companies like Groupon and Opentable successful by their inabilities to understand basic math. Ignoring fundamentals at their own peril, restaurant operators get caught up in ridiculous gambits to increment revenue at whatever cost.
This was the death knell for Staffjoy: a product that didn’t make money for restaurants was proving too much to scale. They folded operations and the founders went their separate ways. Philip went on to build Moonlight, far, far away from the black hole of brick and mortar.
When we asked Philip what he learned, his message was pretty clear.
- “Focus on an industry you know. We spent too much time trying to understand the intricacies of restaurants and time wasn’t on our side.”
- “Relationships, relationships, relationships. Restaurants care more about relationships than anything else. This might be because they’ve been fleeced so many times that they’ve erected barriers to entry.”
- “Restaurants had a hard time complying with rules. Staff was coming in and doing work, but making sure they followed federal, state and local laws was impossible. We talked to a major retailer about their needs for scheduling software, and it included language and compliance support for 32 countries. There’s probably some solution in here that should be built.”
Lastly, we requested for a closing recommendation (or warning) for other startups thinking about entering brick and mortar.
“Keep in mind these businesses have been functioning forever. Not much has changed over hundreds of years. These businesses are not necessarily broken and they will be skeptical of anything that says otherwise.”
It is Philip’s closing remark that keeps us bullish on automation replacing many of these businesses. In fact, Amazon already is. If you refuse to adapt, you will eventually become irrelevant.
Add comment