Notes from co-founding

Things I learnt from doing the work, from books, and from talks — Y Combinator's online Startup School in particular. I add to this list whenever a new realization stabilizes.

Communication about, or during, the work

Radical transparency (as Ray Dalio describes it in Principles) is what lets everyone on a team make the best decisions they can. The more accurate and complete a person's picture of reality is, the better-informed their actions. Find ways to share information openly, and keep updating each other when it shifts.

Clear meetings. What are we meeting about? Agenda points from everyone, in advance. One of our early meetings had eight discussion items with no stated outcome for any of them — I took the time afterward to categorize what each item was actually trying to do, and every meeting since was more effective for it. The four categories I landed on:

• brainstorm together about X
• find or research X
• reach consensus about X
• divide labor on X

Before ending: what did we just learn, where are we writing it down, who's taking what out of the room, and when do we meet next. Accountability is the closing beat.

You will get frustrated. Unless you are a saint. The mistake is not feeling it; the mistake is not addressing it. When I notice the frustration, I take a break and try to figure out what it actually is — a misunderstanding, a fundamental disagreement, or a personal need being challenged (often one of autonomy, competence, or relatedness). I sort my thoughts out alone first, then bring them to the relevant person. Reading psychology helps enormously here — self-determination theory¹, non-violent communication².

What am I working on?

• In a startup, nothing moves forward unless someone moves it forward. The gears only turn if you turn them.
• Modulate between research and exploration at the macro level, then slate that work into small executable steps and split it up. Executing in the present is the only path — don't fantasize about hiring someone to do it. There's no money. Do the work, however rudimentary.

Sales

Sales isn't evil — it's about meeting people's needs. Sales is mostly listening, not persuasion or manipulation. For designers it's a natural extension of talking to users — the same conversation, continued past "what are you struggling with" into "how can I help you with this?" If you can truly help them, they see proof of it, they trust you, they like you — and then they may buy from you. (Some of that sentence is paraphrased from Gitomer's Little Red Book of Selling.) If you're shy about getting paid, that's an internal hurdle worth examining. Money is a medium of exchange that represents value; someone parts with theirs when the exchange brings them an equivalent. Willingness to pay is subjective — not everyone needs the same thing as badly.

The three phases:

• Prospecting — who might be interested? Which user groups? Where do they spend time, and where can we find them?
• Conversations — talk and learn. Is this the right product for them? What problems are they facing? What risks might they perceive in committing to your product?
• Closing — the buying process itself.

"Build it and they will come" is not guaranteed, and usually untrue. Find the early adopters of a hair-on-fire problem — one that has to be solved urgently, no matter how badly. Read about sales. It's not manipulation; it's giving people what they want.

Adoption curve. There's a bell curve for who's willing to adopt new things³. Some people are deeply resistant — expecting them to say no is correct. You target innovators and early adopters — people who can see both the upside and the downside and choose to try anyway. Innovators are roughly 2.5% of any population; early adopters another 13.5%. Which is the reason to cast a wide net: most rejections aren't because you're bad at sales, they're because most of the population isn't ready for the unfamiliar. Accept the no and move on. It's a numbers game. (related talk)

Letting go of perfectionism

Building from scratch is hard. There's no how-to manual, because startup work is inherently novel — you're betting against the consensus of what already exists, so there's only so far you can follow existing methods before you converge back to something already done. Going through it makes you more empathetic toward developers and startups in general.

Execution beats planning, because the first draft is going to be bad anyway. "The first draft of anything is shit." — Hemingway. The benefit of time spent planning diminishes past a certain point; the trick is noticing when that point has passed and switching modes. Doing produces learning and adjustments as you go. The habit of trying to foresee every problem in advance is mostly the mind trying to resolve the discomfort of uncertainty by thinking — but thinking isn't action, and only the act itself will convince you a worry wasn't worth carrying. Quantity leads to quality. No one is counting; only you are. Sometimes the first take is the best take anyway. The best time to nurse an idea is the moment it's born. Just do it, now.

Notes