Five Lessons From my First Three Months at a Startup

Vincent Tsao
8 min readJun 19, 2023

--

Photo by Wes Hicks on Unsplash

I started this draft over four years ago.

It was to be the first entry in a series of monthly posts in which I’d share learnings from working at a startup as the first hire. Future employees would read the posts and get a firsthand look at the company’s evolution.

Though the draft ballooned to thousands of words, I never hit publish. Thankfully over the years, I’ve written about many would-be topics in other posts (e.g. Speed > Process) and year-end reviews (e.g. My 2022 Review). And just last year, I started an internal company podcast for the same purpose.

But I finally decided to cull through the draft and share the learnings that’ve been fermenting — this time without the monthly commitment 😅.

Table of Contents

  • Spend money to make money
  • Tools are for fools
  • Sell vs build
  • B2B basics
  • Roles don’t matter; titles do

Spend money to make money

I tend to be too frugal, which is a mentality I’ve had to fight against at Persona. In business, you spend money to move faster — startups live or die based on their ability to run uphill faster than incumbents.

In fact, investors actually prefer their startups spend money and collect signal as fast as possible on the potential trajectory.

Most startups aren’t swimming in cash, but follow a simple rule to maximize what’s in the bank:

Spend your time on core competencies — spend money on everything else.

Core competencies are customers, product, and people. You’ll spend money on these too, but more importantly, you’ll need to invest time.

Money often affords access to opportunities you wouldn’t have otherwise. On the never-ending list of problems, many can be solved or sped up by calculated spending. Pay for top talent, hire consultants, find contractors for specialized projects, and upgrade to better tooling. Expertise and efficiency are worth paying for.

We worked with a well-referred design agency to build the first iterations of our product. One of our core hypotheses was that a thoughtfully designed UX would be a key differentiator in a market historically dominated by API-first solutions. But we didn’t have the network to hire experienced designers or time to train less experienced designers. While it wasn’t cheap, the agency helped launch our first flows and website that confirmed our hypothesis and gave us confidence to invest in designers.

As a company handling identity sensitive data, we knew we had to get a SOC 2 report to close deals, but had no experience in the world of InfoSec certifications. After countless hours of confusing online research, I reached out to a friend who was an IT consultant and auditor. We flew her out to SF for a weekend and paid $2k to pepper her with all our questions. She reviewed our tool stack and provided insights that saved us time and money we would’ve otherwise spent working with a less transparent, costlier auditing agency.

That said, there’s ways to spend smarter: do it yourself so you know what to look for in a solution, try before you buy, and spend within your means.

We’ve made plenty (but not all) of these mistakes

Don’t use money as a crutch, use it as a lever!

Tools are for fools

The header is purposely hyperbolic — tools are critical for any company. But they command a disproportionate amount of attention.

My spidey senses tingle whenever someone recommends a new tool!

Sometimes it’s the right decision, but oftentimes it’s not. It’s easier to recommend a new tool than to unpack and solve underlying problems of how the team functions.

In fact, the process of deeply understanding the problem before choosing one tool or another ends up being more valuable in the long run.

When properly wielded, tools make a team faster, but they’ll never inherently make the team better.

As a PM, I’ve had my share of thoughts like these:

It’s always a struggle to understand how far along projects are.. do we use a different issue tracking tool?

The business team doesn’t know what the product teams are working on next quarter.. do we use a different roadmapping tool?

I researched the gamut of PM tools but decided not to use them. They can calculate prioritization scores for the backlog or automatically ping stakeholders with status updates on feature requests, but they can’t replace intuition.

Different tools make sense at different stages. But as a company grows, the stack needs to handle an ever-widening range of use cases. So the most flexible tools ultimately win — it’s why many Fortune 500 companies run off GSuite.

I find this quote from Ken Norton spot-on:

If you want to be a better tennis player, you could ask Serena Williams what kind of racket she uses. What brand? Grip type? Swing weight? Rackets are undoubtedly important in tennis, but there’s a lot of other shit you need to learn before they even begin to matter.

Compounding on the pitfall of new tools, there’s also so many of them!

Ironic that while building a B2B company, my key learning is that there are too many B2B companies.

Over my first three months, I created a doc of all the competing identity verification solutions. To my surprise, the list was in the hundreds. There were all kinds of solutions that specialized across regions, verification types (e.g. scanning ID cards, database records), and use cases (e.g. fintech, age-restricted goods).

It takes time to understand how the solutions are different. And for B2B, it’s extra confusing. Nine times out of ten, you have no idea what a company does even after combing through the entire website. Personally, I like to skip the marketing pages and read the API docs instead!

Sell vs build

Start selling as soon as possible. You don’t need a functioning product. Sell ideas. Sell yourself. Build trust.

In the early stages, product discovery is the priority. Validate problems (even if they weren’t the ones you set out to solve), test different pitches, ask questions, get feedback, and ask for intros. Set goals for the number of conversations you have per week.

There are definitely scenarios in which it makes sense to build before you sell. One example is products that have life or death implications. Another is products that fall under specific regulations. But overall, the above is widely-accepted advice for startups.

There’s a corollary, however, that’s harder to master and less intuitive — sell faster than you build.

Many early sales conversations hopefully go something like, “Your product looks great. Can you do X and Y too?”

And regardless whether you can do X, Y, or neither, you should say yes.

It’s uncomfortable, risky, and undoubtedly backfires periodically. But it’s worth it. If we sold what we’d built in the first three months, we’d never have sold a thing.

In a matter of seconds, often while still actively listening or participating in the conversation, you decide 1) whether you can build what’s being asked for, and 2) in a timeframe and way that makes it seem like you had it all along.

Technical or product-minded folks are best equipped to make these decisions, so make sure they’re on the call!

I still marvel how one of our early engineers would immediately say yes with such confidence anytime a customer asked about a feature. And he always delivered in a matter of days.

B2B basics

I worked in B2B SaaS at Amazon, but it was at a drastically different scale. Working at zero scale was eye-opening to say the least.

There’s some advice above around early stage sales, but here’s a couple more learnings worth sharing:

  • Build qualitative intuition from your conversations. It’s more important than gathering quantitative validation. You don’t have customers, so you don’t have data. And even when you do have customers, it’ll be a while before you have enough data to drive meaningful decisions.
  • Get comfortable operating in gray areas. Due to the historical opaqueness of the identity industry, rapidly-changing data privacy landscape, and emergence of biometric technologies, we had to embrace making risky decisions with incomplete information. We imperfectly juggled the interests of end users, customers, vendors, and legal counsel, but we did it as quickly as possible.
  • Work your network. Everyone you talk to has the potential to become a mentor, investor, co-worker, or customer. Case in point, Rick, our CEO, was introduced to Parker Conrad through YC. Parker was trying to sell Rick on joining the upcoming YC batch, but he ended up giving us the best sales advice we’ve ever received, invested in Persona, and ultimately became a customer. Not every interaction is as fruitful, but it’s incredible how much help you can get from your extended networks. Arguably the biggest advantage for older founders compared to their younger counterparts is their network.
  • Find your champions. Working your network is one thing, but knowing how is another. Referrals are key, but they work differently for B2B vs B2C. In B2C, you’d never refer a product you don’t use yourself. But in B2B, that’s not true. Even if you’re not talking to the end user, they pass on messages to their colleagues. In every outbound sales email, always include a line like, “Let me know if there’s someone else we should be reaching out to!”. The B2B goal is to find the internal champion who can influence their teammates. The champion may also be the decision maker, but you need both to close the deal. We’ve lost deals when our champion couldn’t convince the decision maker, but we’ve also won deals with the reverse.
Hunting for B2B champions is less direct than B2C

Roles don’t matter; titles do

I didn’t have a title when I joined Persona — I barely had a role. Since the two co-founders were engineers, I just did everything else.

Is “business” a role?

A snapshot of my first two weeks:

  • Set up payroll on Gusto
  • Wrote and committed new copy for the website
  • Set up Hubspot and then Zoho as a CRM
  • Run pitch practice with the co-founders for seed funding
  • Set up Outreach for outbound campaigns and sent cold emails
  • Wrote an onboarding doc

The prevailing advice is to have a clearly defined role and title before you join a company. While I was nervous about the ambiguity, we made it work because Rick and I have been friends since high school, so we already had an established level of trust.

My title has never changed, but my responsibilities change monthly. We’ve always had open and honest conversations about my future and where I want to have an impact. And as a generalist, that’s ultimately what matters to me. I decided a long time ago that I’ll worry about titles when I leave Persona.

That said, titles matter in external contexts like sales or customer relationships:

  • When I set up the first outbound campaigns, I sent and replied to sales emails via a fake CEO email account for rick.song@withpersona.com to increase our hit rate. I A/B tested a campaign using my email vs the fake email and saw a 2.5x higher response rate with the latter.
  • In customer meetings, we often bring in “big titles” to make sure we signal the importance of our relationship or simply balance the table. If there’s a senior leader on the customer’s side, there’s a senior leader on our side too. So at this point, I’ve unofficially held every title at Persona 😃.

I have the advantage of hindsight as I write this four years later than intended. But time has only helped me realize that these lessons are truer than ever.

--

--

Vincent Tsao
Vincent Tsao

Written by Vincent Tsao

Endlessly curious, always optimizing. Startup and product enthusiast. Building at Persona. vincenttsao.com

No responses yet