Most software founders, particularly in B2B, need to get radically better at sales. @Steli , who is the best person for explaining the scrappy stages in the beginning and then building out a team with scripts and processes, wrote a guide to:

For technical founders it is irrationally, obscenely hard to reverse years of programming (ba dum bum) that sales is a value-destroying activity. Sales is CLEARLY a value-creating activity, contingent on you have a value-creating product.
The world will not drop what they are doing to adopt your work. This is particularly true in B2B, where simply building a better mousetrap won't overcome the activation energy required to get people with additional non-mice problems to prioritize changing mousetraps today.
This is very non-obvious for founders because founders are not often people who *want* to be sold to. We often come from a background where trying out tools is a bit of a fun hobby. We like looking at all the options, making charts, and ripping out partially complete tests.
"This week I unsuccessfully trialed four software options for automating that thing that has been killing us. Our actual production process remains the same as last week. Don't worry; this was a great use of time." is not a thing you want to write in a progress report to manager.
The process of sales pushes the burden for understanding the market and distilling it from the customer to the sales person. That is a very valuable thing; it is why almost all businesses buy almost all of their big-ticket purchases (including e.g. employees) from sales.
(A candidate is absolutely doing a sales job when attempting to get hired by a company. This is one of the things that both sides of that market are frequently in denial about, but I digress.)
Simply getting oneself to be comfortable with sales (or at least present as being comfortable for a phone call or two) unlocks a crazy amount of success for founders, because founders have a few advantages over every other sales rep.
One is that they present as being almost irrationally obsessed with the market. Founders tend to live and breath the product for a few years, and it often shows, mostly in positive ways.

Unlike most sales reps, founders can credibly promise tight feedback loops for product.
Stealing a line from @asmartbear which has paid for at least a year or two of my kids' education:

"If you go with BigCo, you can call them at 3 AM. Someone will listen to you politely, explain they have no solution, and open a ticket. If you call at 3 PM, same answer."
"You can't get a useless answer from me at 3 AM in the morning. But when I'm up, your business *really is* important to me. I am the engineering team. I will push fixes so fast you will be amazed. I *will* get this right because it *actually matters* to my business that I do."
Founders have to sell.

Many, many technical founders of my acquaintance want to offload this to someone ASAP. I've never seen this work: you need to have a deep understanding of your market and customers to arm that first non-founder salesperson. It is gained by doing.
(And even if you don't do sales day-to-day anymore, you still have to sell candidates, investors, and partners on the desirability of using your company. Though most B2B SaaS CEOs that I know still very much have an account in their CRM and talk to "opportunities" frequently.)
The transition from founder-driven sales to founder-assisted sales generally starts with hiring a "maverick" sort of salesperson; someone who is comfortable extracting what you know about the market, iterating rapidly on scripts, and doing "things that don't scale" to win.
This may often be a necessary step, but it generally doesn't last for growing companies, partly because there is a crushing market undersupply of very effective mavericks.

These folks are capable of writing their own ticket and then, by construction, getting folks to buy it.
So eventually one tends to hire a VP of Sales who has done this before. They'll immediately start hiring reps under them, and start systematizing what you've learned about sales into scripts and playbooks.
You'll see this maturity model start to creep into all parts of the funnel, too, which will probably actually be written down for the first time somewhere around this stage.

Sophisticated, mature processes for marketing to pass leads over to sales for qualification.
Sophisticated, maturing processes for sales to actually physically close deals. ("What, you mean we don't just edit a few things in Word and then ask them to print, sign, scan, and send back?") Defined, scheduled startup calls, onboarding, and handover to AMs / CS aftewards.
(Sales, like many professions, benefits from specialization of labor. One that happens early is splitting the team into "account executives" (AEs) focused on getting new accounts and "account managers" (AMs), focused on keeping existing customers happy and expansion revenue.
(Some companies even split their AM teams into dedicated subteams for doing true expansion, for cross-selling products, for winning renewals, and for the generic "I want the direct contact information for someone at your company because our business must be important enough" job)
If you're at all interested in these topics, the people to read a heck out of are Steli and @jasonlk (who writes ).

Steli is so effective at sales he has closed deals he wasn't even a party to. My favorite anecdote about this:
At a previous company I had invited myself out to lunch with a software CEO, with intent to get them to sign up, but was not really sure where we were at end of lunch.

"Hey apropos of nothing: do you know Steli?"
"Oh yeah he's great."
"He is. Steli wouldn't let me leave lunch...
... until you explicitly tell me you're going to use our product."
"He wouldn't, would he."
"He wouldn't."
"OK then; we will."
"Great! Email me and we'll figure out logistics."
That is called "asking for the sale" and, while that is a very unconventional way to ask for the sale, a *ridiculous* portion of all energy expended in the art of sales is to get conversations to the point where someone has to actually say yes or no.
Relatedly: in the highly likely event that you get an answer which is not a yes or no, effective salespeople follow up until the sun goes nova waiting for either a yes or no.

More from Patrick McKenzie

There are a *lot* of software shops in the world that would far rather have one more technical dependency than they'd like to pay for one of their 20 engineers to become the company's SPOF expert on the joys of e.g. HTTP file uploads, CSV parsing bugs, PDF generation, etc.

Every year at MicroConf I get surprised-not-surprised by the number of people I meet who are running "Does one thing reasonably well, ranks well for it, pulls down a full-time dev salary" out of a fun side project which obviates a frequent 1~5 engineer-day sprint horizontally.

"Who is the prototypical client here?"

A consulting shop delivering a $X00k engagement for an internal system, a SaaS company doing something custom for a large client or internally facing or deeply non-core to their business, etc.

(I feel like many of these businesses are good answers to the "how would you monetize OSS to make it sustainable?" fashion, since they often wrap a core OSS offering in the assorted infrastructure which makes it easily consumable.)

"But don't the customers get subscription fatigue?"

I think subscription fatigue is far more reported by people who are embarrassed to charge money for software than it is experienced by for-profit businesses, who don't seem to have gotten pay-biweekly-for-services fatigue.
So the cryptocurrency industry has basically two products, one which is relatively benign and doesn't have product market fit, and one which is malignant and does. The industry has a weird superposition of understanding this fact and (strategically?) not understanding it.

The benign product is sovereign programmable money, which is historically a niche interest of folks with a relatively clustered set of beliefs about the state, the literary merit of Snow Crash, and the utility of gold to the modern economy.

This product has narrow appeal and, accordingly, is worth about as much as everything else on a 486 sitting in someone's basement is worth.

The other product is investment scams, which have approximately the best product market fit of anything produced by humans. In no age, in no country, in no city, at no level of sophistication do people consistently say "Actually I would prefer not to get money for nothing."

This product needs the exchanges like they need oxygen, because the value of it is directly tied to having payment rails to move real currency into the ecosystem and some jurisdictional and regulatory legerdemain to stay one step ahead of the banhammer.

More from Tech

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective

Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.
The 12 most important pieces of information and concepts I wish I knew about equity, as a software engineer.

A thread.

1. Equity is something Big Tech and high-growth companies award to software engineers at all levels. The more senior you are, the bigger the ratio can be:

2. Vesting, cliffs, refreshers, and sign-on clawbacks.

If you get awarded equity, you'll want to understand vesting and cliffs. A 1-year cliff is pretty common in most places that award equity.

Read more in this blog post I wrote:

3. Stock options / ESOPs.

The most common form of equity compensation at early-stage startups that are high-growth.

And there are *so* many pitfalls you'll want to be aware of. You need to do your research on this: I can't do justice in a tweet.

4. RSUs (Restricted Stock Units)

A common form of equity compensation for publicly traded companies and Big Tech. One of the easier types of equity to understand:

5. Double-trigger RSUs. Typically RSUs for pre-IPO companies. I got these at Uber.

6. ESPP: a (typically) amazing employee perk at publicly traded companies. There's always risk, but this plan can typically offer good upsides.

7. Phantom shares. An interesting setup similar to RSUs... but you don't own stocks. Not frequent, but e.g. Adyen goes with this plan.

You May Also Like

I like this heuristic, and have a few which are similar in intent to it:

Hiring efficiency:

How long does it take, measured from initial expression of interest through offer of employment signed, for a typical candidate cold inbounding to the company?

What is the *theoretical minimum* for *any* candidate?

How long does it take, as a developer newly hired at the company:

* To get a fully credentialed machine issued to you
* To get a fully functional development environment on that machine which could push code to production immediately
* To solo ship one material quanta of work

How long does it take, from first idea floated to "It's on the Internet", to create a piece of marketing collateral.

(For bonus points: break down by ambitiousness / form factor.)

How many people have to say yes to do something which is clearly worth doing which costs $5,000 / $15,000 / $250,000 and has never been done before.