Richard Wu was accepted at YC Summer 2019 to pitch his business idea for Simmer. No matter how prepared he was, Richard committed some mistakes that he wants you to avoid. Learn how they almost failed and what could have been done better.
Richard Wu is the co-founder of Simmer, a dish review app. He currently lives in Washington D.C. However, in mid-August he left his city and traveled to San Francisco, where Y Combinator Summer 2019 was taking place.
For YC newbies: YC provides seed funding and guidance for startups, twice a year in 3-month high-intensity “batches”.
How can a review app that requires a double-side market and that hasn’t even launched be accepted on YC? Simmer has mastered the use of machine learning to cover the issue. They realized that to get users, they would need reviews for dishes, and to get reviews for dishes, they needed users. Therefore, they scrapped online reviews and used ML to generate quantitative ratings.
That was the key differentiator Simmer had from competitors and that allowed them to have hundreds of ratings & reviews per restaurant without any users.
However, not everything went as expected. Being his first YC batch, Richard committed mistakes that got Simmer almost into failure.
1. I needed consensus with my team on everything
My founding team needed to agree on everything. While it is imperative to get consensus with your co-founders about important topics like hiring, I found myself spending long hours by a whiteboard fine-tuning minute details.
These conversations, which often turned into arguments, felt right, because late nights at a coworking space resemble productivity. A few weeks later, however, we would receive user feedback which would lead in a redesign. In fact, during the batch, we redesigned our app’s homepage four times. Never once did a user value form over functionality. Looking back, we could have saved dozens of hours if we had just agreed to disagree on the finer points.
One of our YC partners, Michael Seibel, founder of justin.tv and socialcam, shared a story about a similar experience (he recently blogged about this). He and his co-founder, Emmett Shear, spent an entire day deciding on displaying AM/PM when a user sends a message. Emmett was determined that having AM/PM would add too many characters. Michael felt strongly that folks on different time zones would be confused if AM/PM were excluded. At the time, the debate felt important. However, after two hours of heatedly weighing the pros and cons, both founders to ran out of steam and the debate turned into an argument— and the team spent the rest of the day not talking.
How we almost failed
In Seibel’s words, needing consensus “pushes people to turn small decisions into productivity killing arguments”. Know this, the majority of your design will change. Pre-product/market fit, you’re not optimizing— you’re building up and tearing down on a weekly cadence. In other words, most of what you build will be tossed away, anyway. Before you launch, spending time over-optimizing will waste your time— your most precious asset as a startup (along with cash). Worse, over-optimizing looks an awful lot like micromanagement and distrust, which will erode on your founders’ relationship over time.
What we should have done
Agree to disagree on most things. I can’t emphasize this enough. You don’t have to be on the same page as your co-founder. In fact, you shouldn’t; you will move faster that way. Ask first: (1) does this move the needles, then (2) how much you and your co-founders care about this, before you engage. You’ll find that, 90% of the time, it won’t matter within a month.
2. I viewed self-improvement as startup progress
During the batch, YC’s bi-weekly group office hours were a forcing function to move as fast as possible. There is a stark difference, however, between feeling productive and making progress.
I read books, listened to podcasts, and sat down with successful founders. I thought consuming these high-level startup materials would make a better founder. Doing so resulted in spending less time and energy on what matters: building product.
How we almost failed
In the startup space, everyone is a salesperson. As a result, every book, podcast, and blog post appears to be useful. Instead of talking to users, I would block off dozens of hours a week on Google Calendar for “self development”. I once spent an entire weekend binge reading Blitzscaling, meant for companies far post product/market fit .
Over the course of the batch, this time adds up. In the meantime, my peers and competitors were growing their companies.
What we should have done
The takeaway is not “don’t read books”, but “align your time with your core metric”. Core metrics are most often either revenue or usage. Be purposeful with why you choose to read, watch, or listen to something. Is your company launching a blog for customer acquisition? Go nuts and read binge that SEO podcast (so long as you execute). But, don’t go reaching for the new Tim Ferris book if you have a lengthy JIRA backlog.
A “counterintuitive” mental model here is do what is boring. In the tech space, everything new is shiny. The hardest thing you’ll do as a founder is sit down with blinders on and execute, continuously and purposefully. If something less sexy has been on your to-do list for a week, it’s highly likely that that’s the first thing you should be doing. In the words of Shia Lebouf, just do it.
3. I let users steer the product roadmap
Make something people want is the YC motto. The only way to make something people want is by talking to users and building product-- the two most important actions you can do during the batch. Where we went wrong is missing an intermediary step: how can you tell if a user actually wants this?
There are actually two parts to this question. First, who do you talk to? Michael Seibel wrote in YC’s Essential Startup Advice that it is better to “recruit 10 customers who have a burning problem than 1000 customers who have a passing annoyance” . Second, what do you actually build? Talking to users will yield an eclectic and complicated list of features to build. If we let any user steer the product roadmap, we would (and did) end up half-solving a lot of problems.
How we almost failed
Simmer has reviews for dishes, which helps users order the best thing on the menu. The question Simmer answers is what to order at a restaurant. At the restaurant Tiger Fork, for instance, we would recommend the Cheung Fun (8.1 rating) and to steer clear of the Ong Choy (4.0 rating). This can be controversial at times, when we say the American Honey Pizza from &Pizza is the best on their menu… but it makes for great word-of-mouth fuel.
When we first launched, we looked for every foodies to use the app and provide feedback. A problem many foodies expressed was remembering which restaurants popular food shows mentioned, and what they got there. For example, our users loved the late Anthony Bourdain’s No Reservations. Everyone we talked to adored the show-- and could never remember which restaurants he explored. If at this point you’re thinking this feels niche, you’re right. But, when a half dozen early users tell us they want this, you think you’re onto something.
To build this feature, we spent 3 weeks. We found and imported every single restaurant Bourdain went to in the United States (this entailed a lot of Netflix binging). Then, we transcribed every dish recommendation Bourdain and his friends into the app -- and built out a push notification system that alerted users when they were passing by a restaurant he went to.
The feature was well received. The catch? They forgot about it. It turns out, this problem wasn’t severe at all. Not only that, but the problem itself was infrequent-- so infrequent that people opened the app on a monthly basis, not weekly (let alone daily). Yikes. We spent time and focus on building a product that people didn’t love. And, it didn’t get us any closer to product/market fit.
What we should have done
The first thing we should have done is stayed zeroed in on the problem: what to order. We should have been aggressively stubborn with our goal and left this feature off the roadmap from day one.
While this example is an extreme one, there were other features that came down the line that left us unsure-- the potential felt there, but who’s to say users want this after we spend weeks shipping an MVP?
This leads to my second point: we should have been smarter about testing with no-code . As Product Hunt CEO Ryan Hoover says, coding is one of the most expensive ways to test things. There are many no-code products out there to test assumptions. Instead of building out a whole feature in our app, we could have propped up a landing page with Sheet2Site with a Stripe integration. We could have ran $100 in ads overnight and validated if people would pay even $1 for this app.
Try to adopt this mental model: what is the fastest way you can test if the next step of your roadmap brings you closer to product/market fit?
4. I drank the hustle porn kool-aid
At the end of the day, the most important piece of advice I can share is to be self-disciplined in your self care. It’s easy as a startup founder to adopt an unhealthy sleep schedule or diet as part of the “hustle”. Reddit co-founder Alex Ohanian calls this Hustle Porn, referring to the fetishization of working long hours. Oh, Gary Vaynerchuck worked a decade without taking a vacation? Then, a Soylent-only diet for a week must be my rite-of-passage to become the next kajillionare.
How I almost failed
During YC, I was prideful of my dark eyebags and my triple espresso 11PM coffee. But, when I added up the hours, I could have had the same waking hours if I had just woken up at 6AM and slept at midnight. I would have been more productive. I would have been happier, too. Tim Ferriss says in the 4 Hour Work Week that being busy is being lazy. I agree, in that being too busy to take care of yourself is being too lazy to take care of yourself. This is something I still work on.
What I should have done
Having no self care is easy. It feels great because anyone can brag about their “hustle” and achieve a dopamine hit. But if you don’t have self-care, you may find yourself less happy and less productive. Who wants to invest in a founder operating at 80% of their potential? It’s bad for you; it’s bad for your business.
Although the title of this article is how we almost failed, I’m not suggesting that we are succeeding. Like you, I am still very much on the road of discovering how to make a successful company. You still might find us on the failed startup page a few years later.
Want to connect? Say hi! If you’re keen on checking out Simmer, check us out on our website.
 YC does not encourage early startup founders to “blitzscale” (in fact, Paul Graham, founder of YC’s famous proverb is do things that don’t scale). This method is from Blitzscaling by Linkedin CEO Reid Hoffman. The blitzscaling method teaches counterintuitive growth strategies (e.g. don’t talk to users) for companies that have to grow 100x or die. This shouldn’t apply to 99.99% of early stage startups.
 You can tell I respect this guy. You should take a few hours one day to read every article on his blog. While this pointer may seem counterintuitive to my second topic, YC partners have a fantastic batting average for spot on advice. The content YC partners put out is unique in that the partners not only have successful exits themselves as former founders, but they have seen hundreds, if not thousands, of startups succeed and fail.
 Ryan Hoover’s essay on building products with no code is awesome. Whether you can code mobile apps in your sleep or you just learned what HTML is, every prospective founder should try to test their MVP with no code first.