Author’s Note: this piece is written in the first person, because I'm sharing the lessons that I learned, personally, as a founder. But I learned these lessons alongside my co-founder, and she deserves more credit for any wisdom contained herein than I do. She was always the wiser among us. One of the things that never went wrong and has always remained true from day 1 is how much we had each other's backs -- we would have failed earlier and less fruitfully without one another. Find the right co-founder.
A Lament on Failure
Before we start with the lessons, I'd like to share the lament of a newborn fool:
I sit here in Cafe Reggio reflecting on a mountain of failure. I convinced my friends and family to invest in my venture, foolishly believing that I had stumbled upon a brilliant idea, supported by a mountain of “testimony” that the problem was real, except each piece of testimony had its own crucial caveat, always different.
Unaware of the contradiction directly in front of me, I forged onward, strung along by "just enough" traction to keep me going, convinced by faulty interviews that I was "onto something", that the world only needed to wait for me to execute it perfectly before they would love it. So I convinced the angels to support me on this holy mission (to build SAAS that everyone could use, but no one deeply needed, yet) -- they would be my wings.
I was so naive to my own naivety, and now I plummet from the famous hill labelled Dunning-Kruger, bashing my face against hard truths and slamming against hindsight, my precipitous decline in confidence only slowed by my own stupid and desperate attempts to hold on to the few remaining cliffs of this mountain of false confidence. But these were, of course, just postponements of the inevitable truth: I was in over my head and had no idea what it meant to "have a good idea", to "test a business hypothesis", or to "find product-market fit". At least now I have enough wisdom to know that I still don't! I only have substantiated ideas about what these things Definitely Are Not. A consolation, a shard of truth, hard-earned through failure.
I thought that if I watched enough startup school, and read enough Paul Graham, and worked with enough talented people, I would be able to tell the truth of things. How foolish. Oh, but I suppose only a fool could do what I did. So here I sit, at the bottom of one mountain, staring up at the peak of the next, thinking to myself "Do all founders go through this, or am I just an idiot?"
Regardless, there's nothing to do now but climb. Soon, I will dust myself off and begin the arduous journey of mastery, with the grounding and foundational belief that I am an utter fool serving as my comfort and companion. If you ever meet me on my journey, know this: I am but a fool. I will likely ask dumb questions and give dumb answers, for I no longer see any point in pretending. Do not come to me in search of advice unless you too are a fool, I am not an authority on anything else.
But for now, before this next chapter begins, I should rest, reflect, and tend to my wounds. Enough lamenting, what follows are my reflections on this failed venture, synthesized into lessons. Though you might be just as foolish as I to think you can learn anything from them except in hindsight. Still, giving words to my failures will help me, so you can at least take comfort that one of us is benefitting from these lessons.
1. Ideas are Experiments, not Babies
Don't treat ideas as sacred or "worth protecting". An idea is a test, an experiment. Write down your hypothesis and try to prove it wrong as quickly as possible. Don't trust non-double blind studies (aka. "User Research"). This is basic stuff, but I failed over and over again. I SO wanted my idea to succeed that I read into remarks and convinced myself that "more features" would solve the problem.
The idea of an "MVP” got in the way here. In your mind, you will justify months of full-time work as just "working toward an MVP". Stop that! Most good scientists do not need websites, marketing, or designers to test their hypotheses. Neither do you. If people don't want your shitty prototype, the problem isn't big enough. CONGRATULATIONS!! You invalidated your bad idea, now go hang out, socialize, and do leisure with real people until you come up with another interesting idea/experiment to run. Throw the baby out with the bathwater! There is no baby!
Be very careful with User Research. In fact, don't do it at all unless you're going to ask someone to pay or sign an LOI at the end. It's extremely easy to accidentally get people to support your idea in an interview. Don’t take "Yes" for an answer; if they don't use it or pay you for it or PUSH you to build it RIGHT NOW, then it's not a 9 or 10 problem. Again, Go Find Something More Important!
1b. Ideas suck by default, especially good ones
Ideas mostly don’t work. If you're SURE it will work before people are practically begging you to solve their problem, you're drinking your own Kool-Aid. It probably won't, it probably sucks, but you should test it out quickly and then write down & publish your lessons. Even though most ideas suck, most experiments have valuable lessons which don't suck. Don’t let investors, friends, co-founders, or anyone except users convince you that your idea is good.
2. Better to be a fool than an actor
It sucks to come across as a fool who doesn't know what he/she is doing. It is so much worse to come across as competent and to be wrong. Don't act, don't pretend, don't exaggerate, don't say a f*cking word you don't believe. The people around you want to help you succeed, but they cannot help you if they can't model you accurately. They can't model you accurately if you're acting. F*ck Machiavelli, you're not The Prince, be vulnerable so people can actually help you with your real problems, even if they're embarrassing, even if they're the problems of a fool.
NOTE: this advice is not saying "don't lie." Only an idiot would lie. Obviously don't lie. I'm saying don't even exaggerate! Life is too short for bullshit.
Napoleon, the Emperor of Europe, had no qualms showing his soldiers how much of a fool he was. You simply can't be helped if you pretend to be more competent than you actually are, even if you're as competent as Napoleon. Be more like him:
Some of his questions showed such a complete ignorance of the most ordinary things that several of my comrades smiled. I was myself struck by the number of his questions, their order and their rapidity […] But what struck me still more was the sight of a commander-in-chief perfectly indifferent about showing his subordinates how completely ignorant he was of various points of a business which the youngest of them was supposed to know perfectly
— an officer under General Bonaparte
2b. Better to be disliked than to feel trapped
Every exaggeration, every promise, every act of false confidence is an act of cognitive dissonance within yourself. By bending the truth you distort reality and create a prison for yourself, trapped into a persona you never really believed. Trapped by your own acting. It is so much better to be disliked, judged, or thought a fool than to feel socially trapped. Don't pretend to have answers when you don't. Don't pretend an employee is doing well when they're failing.
Being honest is a great filter, anyway. You don't want fair-weather fans, friends, coworkers, or investors. If the people around you don't like you when you're honest, welcome to hell. Sure, it's painful to be rejected by others, but it's not as painful as failing.
3. Execution is NOT all that matters
In hindsight, I honestly can't believe I bought into this one. No amount of execution can turn a 6/10 problem into a 10/10 problem. Yes, execution is crucial, but it's also expensive. Invest in execution proportionally to the amount of traction you actually have. If you don't have traction, consider executing on more & better experiments, and throwing out your bad ideas, because there’s nothing sacred about them.
4. Only work on 10/10 problems
There's this classic PMF advice: as soon as you get your first real users, ask them anonymously "If we shut down, how disappointed would you be from 1-10?" If nobody answers 9 or 10, you have a big problem. Also, if you don’t have first users in the first place, the problem isn't big enough. Either way, it's either a 9 or 10 or you should GIVE UP.
You should be able to give yourself the same question: "How important is solving this problem to me?". Don't trust this one as much, because it's hard to be honest with yourself, but if you KNOW that it’s not a 9 or 10 for you, then just save yourself effort and give up. Either solve a 9 or 10 problem or go work for someone else who is and absorb their passion.
If you're not sure what to do with yourself, go socialize with ambitious people, have fun, travel the world, work with geniuses, do whatever until you actually find an important enough problem to solve.
5. A better theory of burnout
This is straight from Sam Altman because I agree with him after seeing it up close.
Many think burnout comes from overwork, and that the cure is rest. But no, this isn't the most common cause of burnout for founders. Burnout comes from working on projects with no momentum even when you're out of energy, and the cure is giving up. In other words, burnout comes from continuing to work on the wrong thing even when you subconsciously know it's wrong.
I now like to imagine there are two pools: the founder's Energy and the project's Momentum. When you first start, a project has almost no momentum, but you have a lot of energy. You have to invest your energy to fill the momentum pool. If a project has momentum, it is energizing to work on, refilling your energy pool and in turn letting you invest into even more momentum. It's a virtuous cycle, a flywheel effect. But if you run out of both energy AND momentum, it's game over. Burnout comes when you force yourself to keep going in this state.
If this condition persists for more than a week, please consult your doctor. The doctor won't help, but maybe while you're in the waiting room you'll remember this lesson and give up on your idea instead of continuing to spin your wheels.
My advice if you're in this spot is the same as Sam's: give up, take a vacation, and start over w/ a new, better experiment.
6. User Research can cause more harm than good
This one is insidious. When we first set out to validate our idea, we interviewed dozens of companies who needed booking software. The most common refrain was "I wish I met you 6 months ago when we were first building our booking system." This should have been a red flag, but instead I interpreted it as a positive sign -- "all” we had to do was find these companies at the right time to make the sale. Wrong.
I drew exactly the wrong lesson. What I should have heard was "we don't have this problem because we solved it 6 months ago." Instead, I heard "we have this problem [just not right now]". If your target customers are capable of solving their own problems, this is a warning sign that the problem is not painful enough. Ultimately, our value prop was saving money and time, but our customers were willing to spend that time solving their own problems (which is honestly a more general problem with selling software to software engineers; I probably won't try to do that again...)
If I could go back, I would have just paid $500 for some mockups of our software and asked for LOIs directly: "will you pay us for this software if we deliver it in 6 months?" There's no ambiguity here. I could have gotten to the truth much faster: will people pay me to solve the problem? For us, the answer was: not enough people. We got strung along by a few design customers who ultimately wouldn't have felt 9 or 10 disappointment if we shut down service. (We should have asked them that question, though)
Use User Research responsibly, or you will waste your time.
7. Why aren't you working on the most important problem?
My final lesson is also the most painful to confront. Simply put, I didn't truly believe in my heart of hearts that Qrono was the most important problem I could solve. I know I'm capable of solving serious, world-changing problems, and I even write about & research those problems in my spare time! But I worried it would be too out of reach for me to start my entrepreneurship career with my most ambitious ideas, especially in the middle of a pandemic. I thought "why not pick a problem where I know I can execute well" (this also shows my incorrect bias that execution matters more than ideas). I was confident in my software skills, so I shoe-horned myself into writing software; I wanted an "easy-to-execute" company to learn all the other skills of being a first-time founder. How foolish.
Ultimately, this would eat away at us. The looming thought "why aren't I working directly on the most important problems" would haunt me during the harder weeks, making them even harder than necessary. If I could start over, I wouldn't commit to any idea so quickly, and I would pursue many of my ideas in parallel, or in quick succession until they found traction."Lowering my sights" was a losing strategy, because it also lowered both my motivation and my impact.
It was also so premature. We narrowed our focus to one idea before we found real traction. If we had kept a more experimental approach, we might have given our most ambitious ideas a shot before committing to anything "full time" (whatever that even means). My new philosophy? Life is too short to work on anything less than the most energizing projects. First startups aren't "stepping stones" to more ambitious startups, you always need all the motivation you can muster. I wish I didn't constrain myself so early and hadn't let the fear of failing or looking weird keep me from doing massively experimental things with our company. We need more people willing to experiment -- in the future, I'm going to do just that.
So, What Next?
We’ll both have to wait and see. I have no shortage of ambitious ideas (you can keep track of where my head is at here) and neither my co-founder nor I are done with entrepreneurship. But it’s too early to commit to anything; I need to compose myself.
As for the future of Qrono’s IP, we’re not totally sure. We have a complete product, but it doesn’t seem clear that anyone would acquire it — maybe we should open source everything? If you have ideas for what to do with all of the software to run a full-stack booking system (backend, APIs, docs, frontend components, dashboards…), I’d love to hear them, you could really help me out.
Also, if you want to hire any of our engineers, please reach out to me. More than anything, I want to make sure they have a happy landing. They’re all junior full stack and frontend engineers, trained on Django/Python + React/JS. Two of them are Latin American engineers from SoyHenry with very affordable rates.