“Now What? Your Post Launch Growth Plan” Podcast and Transcript

Adapted from a presentation on “Now What? Your Post Launch Growth Plan” at the KASE Entrepreneur Seminar on October 16, 2007.

What Was Heroic Must Become Routine: Your Post Launch Growth Plan

Download: MP3

If you take away nothing else from tonight, it’s that going from your beta to your launch requires that what used to take an enormous amount of effort to achieve a level of performance has to become routine. You cannot rely on heroics once you are scaling the company: you have to build process and procedure into it. So, we are going to talk now about how you grow after launch in three areas:

• at company level
• in customer development (sales, marketing, and business development)
• in product development

At a company level, what’s the challenge after launch? The challenge is that you have to build an effort that you can sustain and scale, which means you have to develop things like process and metrics and dashboards.

So…process, metrics, and dashboards…most of you probably have left big companies where you had process dashboards and metrics, and you are thinking “I don’t want any more of that.”

Just as little process as possible is a good thing, but you can’t get away from it completely.

After launch, you grow from a small team of generalists to a larger team of primarily specialists, because with that comes division of labor and the ability to scale. You can’t just keep hiring generalists, utility infielders who are comfortable in the white space on the org chart–an org chart that used to be pretty much entirely white space now has a lot of boxes on it. You’ve got to hire people that are outstanding in that one particular box, in part because they can rely on the folks in the boxes around them to be outstanding as well.

In the beginning, as you are adding customers one by one, you are just trying to get that next customer. After launch it’s about next quarter, it’s about a business plan; it’s about a revenue target, it’s no longer one by one.

In the beginning there are only one or two people–typically the CEO and CTO–who can actually make a binding commitment. But for your company to scale up, a whole bunch of people start to make promises to a lot more customers. This means two things:

1. If you don’t have a plan, it’s like running a development effort without a source code control system: you don’t know what you are changing, so you need a plan.
2. If you don’t agree how you’re going to change that plan; if you don’t develop a change process, you are going to spend more time arguing about how to change the plan, then on the merits and drawbacks of the change that is being proposed.

So post launch, there is much more need for a plan of record and a change process that people buy into.

Audience Question: Roughly, how long are these plans? It sounds like there is lot of work to develop these plans and targets and commitments and keep updating them.

So, one or two pages is reasonable length for a plan, that’s what most people can absorb. Especially for your near horizon, a one or two page written plan is normally enough to get you there; you don’t need a book. But, you have to have it written down and documented: it can be a wiki page, it can be something as easy as that to change–and track changes–but it has to be in writing.

How many people have sales guys in their company? [No one raises a hand.] Okay. Well, after you launch they may become more important.

Right now the sales incentive for Beta is very simple, if we make the sale we all get to keep our jobs. It’s a pretty easy thing to focus on. But, after you launch you get what you reward, so you want to pay very careful attention to whatever you put into that compensation plan, and how it aligns with your business model.

As you scale up, it’s more than just new accounts. Right now for most people that are in Beta or just have early customers, it’s all new accounts. Later on there are also renewals and upgrades, these require a different focus and different incentives.

So, we do a lot of work with software companies; this talk is aimed more at software companies than hardware companies. With hardware it is hard to add features to a chip once you’ve shipped. The point is that software startups are tempted to of accumulate a whole bunch of small features into some kind of shotgun blast full of birdshot, and hope that something will stick; some golden BB against the wall.

The reality is this that big features, important features, are what drive interest and adoption. So, as you are doing your planning, think about one or two things that are actually going to move the needle on prospects’ interest, and plan the release around that.

Also, just because you don’t know about the bugs you are going to have to fix in the next two weeks or four weeks or six weeks: they are going to show up. Leave some cushion in the schedule: don’t try and put eight pounds of feathers in an eight pound sack and discover another three pounds as you are half way down the road.

In the beginning, as we are going one by one for customers, a special for this customer makes a lot of sense. After you launch, when you are going after markets, this becomes a much more unattractive approach. You want to limit the amount of work you do for any one customer.

Early on, early adopters are very smart people, and they have a couple of wonderful features:

• They are highly risk-tolerant.
• They don’t mind if things don’t quite work–as long as you ultimately get them fixed.
• They’ll actually buy the product without having to be sold.

Problem is they are just not enough to actually build a company on, but they are wonderful folks in the beginning. And, a lot of people think this is going to go on forever, and alas it doesn’t.

So, nobody had any sales guys, so right now the CEO is selling in your startups? Who is selling in your startups? CEO, alright; so typically one guy is kind of like the gorilla, the tall thin engineer whatever doing the selling, right? And, still figuring out what works in the sales pitch and what doesn’t.

The founders have to be directly and intimately involved in selling, because maybe it’s not the sales pitch, maybe the product sucks, right? Maybe the business model is not quite right for what you are trying to do. The founders have to be intimately involved to be able to make adjustments between the message, the product, and the business model. Also, if they are not involved now, they can’t manage later on as they scale its sales force. So, you have to learn what’s involved with managing the sales force. It’s not magic. It’s not hire the best liars you can. It’s a real art.

We sometimes talk to firms that have hired and fired several sales people. They don’t yet have a sales pitch that works, and they are just burning money. Don’t do this. A real sales guy will give the same pitch over and over again, because that’s what works in the corporate world, and that’s what normally works post-launch. Because, most of the time they have been handed the pitch that works, and so if it didn’t work with this prospect, then it’s the prospect’s problem. During beta and for your early sales, your pitch may suck and will need to be changed.

A lot of engineers we talk to say we can’t figure out how to get the sales guys to do what we want them to do.

We reason with them.
We talk to them.
We invite them to meetings.
We show them the corporate mission statement.

Let me explain you, it’s very, very easy to get a sales guy to do what you would like. You adjust his compensation plan; you pay for what you want and you manage against that. It’s very simple. If you don’t do that, you are wasting your time and his.

Now we are going to look at customer development in Beta versus after-launch. In the early market you are exploring; you launch when you believe you are going to accelerate. You’ve found a market; you’ve found a way to go.

In the early market, you’ve got a number of hypotheses that you are testing. After you launch, you better be working based on facts and metrics. Now, some people launch and nobody comes, I submit to you, you are still back in the early market.

In the early market, you are trying to adjust your business model, adjust your promise. After you launch, you are penalized for changing that promise a lot, so you better figure that out before you start to put the big megaphone in front of it.

In the early market you are trying to find a niche, you are trying to find some place to insert and get some foothold. After you launch, you are trying to find a big market. Don’t confuse those two.

Here’s an example of how I learned how sales guys look at problems. At the time I was running support at MMC Networks and over a period of about nine months we hired nine or ten new staff. We scaled support from about six to fifteen people. We were supporting more than sixty active design projects with more coming in every month.

I went to John the VP of sales and said, “we can’t support all the people you are bringing us, can we slow down? Can we focus on the big guys? Can we–you know–focus for effect?”
John would say “you know you are absolutely right.”
So I would say “Great!”

Next month more new evaluations.
Back I go to John: “We can’t support this many new firms, they are falling on the floor. We have so many that the thrashing in talking to them is taking more time. We are actually getting less done then if we had fewer evals.”
“You are absolutely right.”

Next month, more evals. Finally asked him, “John, how are you compensated? Are you compensated on revenue?”
He says “No, that’s way too hard to figure, that’s way too downstream. We are compensated on design starts.”
So, then I knew my argument was not with him.

How many people have heard of Jotspot? About two years ago they were kind of struggling against Socialtext, they announced three thousand beta users. Big press release, big news, big noise. Months go by, much testing, the development guys are very happy, because they are getting the product tested; this is great, this is great. Then they launch, and they say now that we are launched it’s not free anymore. You have to pay, or in thirty days we are going to turn you off.

They figure they’ll get probably half or at least a third of these beta users. It’s more like 2%. They have to go back into the garage and figure out how is it that you actually find guys that want to pay for the product, that don’t just want to use it for free.

For all of you that are doing free, freemiums, social networks, and all this free stuff, I would submit to you, there’s a hell of a difference between getting guys to use stuff for free than for a penny. You are better off now–day one, user one–figuring that out.

Finally, we get to product development.

The interesting thing is we talked in customer development about how things change. The challenge you have in running product development post launch is, you want to hang on to the values and the things that got you where you were. So in fact, you don’t want things to change; in particular you still want a fast clock cycle in decision-making. And, you want to maintain as much creativity, flexibility, and intelligent reaction as you can. You want to fight bureaucracy as hard as you can.

In beta its really simple: does the thing work yet? No. OK let’s not ship it. Later on, you can’t do it that way, because you end up in an infinite loop where more bugs flow in, more feature requests flow in, and the release balloons into a whale that never ships.

Also, QA effort is a function of about the cube of the number of features. So, as that release grows large, your ability to test it gets away from you exponentially. What works: pick a date, stick with it. Let one or two major features drive that date, fix the problems you can; live with the rest until the next release.

There is always a reason to hold the release.
There is always a reason to hold the release.
Resist that it and get it out.

If you have a faster decision cycle, several things get a lot easier:

• You don’t have to be as smart about the market, because you are going to be in contact with it sooner.
• You don’t have to look six months ahead; you will have a product out there in two.
• You don’t have to forecast customer needs; you are going to be bringing them ideas asking “what do you think?”
• You don’t have to anticipate your customer’s actions next year, because you are going to be inside their reaction cycle.

Audience Question: So, what’s the difference between a faster decision cycle and a slower one?

Historically the on-premises software guys were working on an annual release cycle. I would submit to you that you guys should be looking at least quarterly and better monthly releases. That way you are moving well inside of their decision making cycle. It’s different for chips, different for other kind of companies; but you want to be much faster than your more established peers. And, you want to stay fast as long as you can, because the risk of somebody flying up your tailpipe is much more than somebody stepping on you.

Question for Audience: How many of you are working in a startup that can still fit around one table? Say, a table with eight people, OK?

If you have to have a meeting, everybody in the company can be in the room. The executive staff is the product team is everything else: conversation, fast decisions, everybody is there.

You get bigger, your temptation is to have the executive staff hang on to all of those decisions. But what you really have to worry about is growing the company, you need to delegate to a product team that has a representative mix of folks from the various functions to drive the product.

If you are one of the founders, you have to worry about growing the business; let the product team run the product. You might at some point have two products, or three products.

At Beta: not so many commitments, and actually a lot of the commitments you make don’t matter, because the customer doesn’t buy, you can forget about them. Later on, more people remember.

Early on when it’s ready you can ship it; later on you’ll go dead doing that. Early on what’s that guy need; later on you better be working to a plan: maybe one page, two pages long.

In the beginning you could be customer [deal] driven, but later on you have to be market driven. You can’t just satisfy a handful of folks, and somewhere around nine customers; a customer driven model starts to break down. So, unless nine customers gets you to where you want to go; you’ve got to be thinking about making a transition to a market focus.

What stays the same: fast decisions, stay creative, stay flexible.

Another story: we use WebEx Office, and we use that for our calendaring.

So, we invite our customers to come to meetings with us using WebEx Office, which was originally developed by Intranets.com. It was an intranet application where a manger would use it to send an invite to a subordinate. In that context you can say things like, “you are required to come to this meeting.”

Now, in a consulting context, when I require my clients to come to meetings, they write back and say “I don’t think it works that way, you can invite me to a meeting, but you can’t require me to do a damn thing.”

We call up WebEx and ask can you fix this, can we change that little piece of text you are generating with my name next to it, that’s pissing my customers off?

Roach motel: request goes in, no sound, no picture, who knows. So, knowing a little bit about things, I call the sales guy and say “you know we may quit paying you for this.” Because we pay them every month. So then, we get a meeting with product support, no roadmap, no tracking; and I get a lecture about how hard the product manager’s job is. I go hey I’ve got a hard job too.

If anyone knows a good alternative to WebEx Office I’d actually like to hear it. Don’t be these guys.

Who knows what a whole product? A whole product is everything that’s needed to solve the customer’s problem: documentation, interfaces, useful error messages, etc.. In the beginning you can have a partial product. You can have a product that geeks can love; later on it’s a product your Mom has to be able to use.

Audience question: How does a transition take place from where we are all running around ad hoc to where we are doing these one page plans that make it scalable and repeatable?

Typically there are one or more failures, some people lose their jobs, and then new people come in and things change. Don’t be those guys either.

Audience question: At what point, you know when you have a CEO that’s so hands on in the company, and then things start to specialize and differentiate. I mean is there any point at which CEO starts to delegate? Say for sales department for example?

There are a couple of challenges. The CEO is either sales oriented or development oriented or maybe customer support oriented. He may be trying to get out. The challenge comes above some headcount–say twenty-five–he’s got to learn to manage managers, so that happens pretty fast.

The first bottleneck is if he is the mobile sonic boom who closes business: you miss a quarter, you miss a deal. He has to be able to delegate, and teach other people how to sell. He’s got to be able to let go and other people run the product. But, that occurs pretty fast; I mean you can get to sixty people or eighty people, but at that point the wheels are going to fall off if you’re not able to delegate; so it’s pretty fast.

Another difference between beta and after launch is that normally, in beta, if you don’t have it, they won’t believe you. So, it’s much harder to fool your customers. Later on when you are a bigger company, maybe you’ve got some VC, you can show customers a roadmap and actually decoy them in ways that can do them real damage. So, meeting those commitments later on has to be done, because your customers are more trusting of you than in the beginning.

If it’s three guys in a garage, they are only going to believe what they see. If you tell them you are going to bring out a box, you can show them a picture but they are not going to give you money until they see the box. Later on if you bring out a second box, you might be able to have them pay some money, because you’ve given them the first box. So, commitment tracking becomes even more important after launch, because your customers become more trusting–fewer early adopters more mainstream users.

The other thing that happens is that engineering’s access to the customer gets more and more mediated. You’ve got more marketing guys, you’ve got more support guys, maybe you’ve got a customer advisory board. So, making that work, and learning how to work through intermediaries becomes more important. In the beginning, between somebody bringing the deal and what engineering wants to do, you can pretty much decide what’s going to happen. Later on, you get more input from other folks.

So we help very early stage software companies with strategies for customer and business development. We help them find early customers, early references, and early revenue.

Related Blog Posts

• Chalk Talk on Technology Adoption
• George Gilder: Entrepreneurship is the Launching of Surprises
• a related blog post “What Was Heroic Must Become Routine” applies some of the lessons from this talk to some other startup examples.

Photo Credit: JD Hancock (@JDHancock) “Robby the Robot: Into The Unknown!” Used with attribution under Creative Commons.