July 30th, 2008
This phrase is attributed to Sergey Gorshkov, the commander in chief of the Soviet Navy from 1956 to 1985, who managed it’s dramatic expansion during the Cold War. Perfectionists get this wrong, siding with “Better.” Entrepreneurs who prosper, for the most part, side with “Good Enough” and keep improving.
I was reminded of this quote when I read a recent blog post “Vaporware” by Chris Crawford, who is working on new start-up called Storytron in the interactive storytelling space. I have a lot of respect for Chris Crawford, who is an innovator in the computer gaming field. I subscribed to his “Journal of Computer Game Design” and took away a number of useful insights.
In particular his 1992 article “Lessons from Patton Strikes Backl” outlines several useful concepts that most early stage and niche software companies should keep firmly in mind, what follows is a lightly edited summary of his five lessons:
- Start with a clear mission statement. The essence of game design is decision-making; a designer makes thousands of decisions during the course of a project. Your choice is always between options with different merits. This is one advantage of the clear mission statement: it simplifies the decision-making process. Instead of asking, “Which option is better?” you need instead ask only, “Which option better fits my mission statement?” This latter question is more precise, more specific, and therefore easier to answer. More important, it is faster to answer. The bulk of a game designer’s important work is making decisions about what to include and what to pass up; anything that makes this difficult process faster and more reliable is worthwhile.
- Plan then code at a program level, code then plan at a feature level. Hacked code is so brittle that, over the long run, it takes more time to debug and maintain than properly structured code. [Planned, well structured code] can be easily modified and corrected after it has been written. The early stages of a game project have us writing code that we know will change considerably later on. However, there is another time scale to consider: the short-term time scale in which we write up a single feature. Most game programming is in some way experimental; any feature that is fully understood is probably obsolete in our fast-moving industry. You can’t plan such code in advance; you just have to wade in and hack until you figure it out. The conclusion I came to is this: hack first, then recode it right.
- Don’t be seduced by the cleverness of your own ideas. This was the single biggest mistake I made. I came up with a truly clever idea…and I was justifiably proud of it. But it caused too many problems. [It] turned out to be clumsy to use. Most players eschewed it. I should have had the courage to dump a clever idea that, in the final analysis, created more problems than it solved. I didn’t, and the game suffered for it.
- Bake the cake first, then add the icing. Publishers sell games in the same way that bakers sell cake. The customer doesn’t taste the cake until he gets it home; all he sees in the store is the icing. So bakers don’t sell cake; they sell icing. In the same way, most publishers don’t give a damn about gameplay (cake); all they care about are the graphics and sound (icing). With Patton Strikes Back, I baked the cake before I even showed it to any publisher. I designed and developed the game first. I finished all the basic game structures, wrote and tuned the artificial intelligence, even got much of the play balance worked out. Only then did I show it to publishers. Guess what they wanted? More icing! At that point, it was easy. Having finished the cake, it was easy to pile the icing on.
- Make sure there is a market for your product before you develop it. Patton Strikes Back was a “wargame for the rest of us.” It received excellent reviews. Unfortunately, it has not sold well. It would seem that “the rest of us” aren’t buying computer wargames. The aficionados certainly hated it. Without their support, the game withered…I will never make a significant income from the game. Lesson #5 is, I think, the most important lesson to learn from Patton Strikes Back.
Real candor and some valuable lessons. Two I take to heart are to stay clear on the mission and to guard against being seduced by my own “clever ideas.”
I am of two minds about Chris Crawford’s Storytron effort. It’s possible that they will make a huge breakthrough, certainly he has done several very innovative interactive games to date. His 1982 book “The Art of Computer Design” is out of print but still worth reading on-line for it’s insights into how to create engaging interactive environments, appropriate for anyone developing advanced analytics or social software. But it increasingly looks like an effort that’s suffering from “mission creep.” What follows are some selections from his “Vaporware” post, highlighting the team’s issues with traction and “making things better” (bold text in original):
Perhaps you have noticed that Storytron seems to be suffering from a bad case of the vapors. Our very first business plan called for us to publicly launch everything on January 1st, 2008. That didn’t happen. We pushed the launch date back to March 15th…and we pushed back the launch date to May 15th…once again I went back to the drawing board and came up with major changes… despite the fact that our official launch date has been pushed back repeatedly, our progress has been relentless.
It’s easy to stand on the outside and criticize, so let me just make what I hope is a constructive observation. If you have slipped four times you need to start to radically shrink the mission and focus for your first version.
The website. The Storytron website has quite a few special capabilities that require some custom programming. There’s nothing earth-shattering, to be sure, but it is not a collection of HTML pages. There’s a lot more going on underneath the hood. Louis has been doing lots of coding to make all this work properly, and Pati and Laura have been deeply involved in organizing the overall effort.
If a simple collection of HTML pages would make a “good enough” impression I would consider pushing out a dynamic website to a later version of the product/company. A basic demo has to be central to the mission, but they may be aiming much too high for their initial release.
The reference material and tutorials. This pile is huge. Worse, the technology it explains has been constantly changing. We made changes in April and May that required Pati to completely rewrite large portions of the tutorials. All in all, the content of the materials on the website adds up to about the size of a book — which Pati and Laura have generated in a matter of months.
It’s not clear what the changes were, but it doesn’t sound from the context they are keeping their focus on a simple app and demo for their first release. Again, hindsight is easier but if you find yourself re-writing the manual significantly before the product is in customers’ hands you should consider sharpening your focus and deferring features.
So how much longer will Storytron remain in vapor? How much longer will we give you promises that we later break?
If you find yourself worrying that prospects no longer believe you–and therefore no longer trust you–you need to change methods. Trust is hard to earn and too easily lost. I would think that they could sort their early users by risk tolerance and relevant technical skill levels and release the current “deficient” version to those it’s unlikely to turn off.
The board of directors discussed this matter at length at its recent meeting, and we hammered out the details of how we’re going to handle the launch. This time, though, we really want to be sure about our promises.
Again, you always want to be sure about your promises. One of Gerald Weinberg’s key observations for consultants and other change agents–and make no mistake about it, Chris and the Storytron team are trying to trigger a revolution in interactive entertainment–is that “people don’t tell you when they stop trusting you.” And once you’ve lost their trust, there is little basis for the kind of relationship that’s needed to convince early adopters to work with you.
Therefore, all we are saying at this time that the launch will NOT occur before August 18th. We are HOPEFUL that it will occur by September 1st. And that’s the best we can say at this time.
It’s better to give a “blood date” (vs. one written in pen, pencil, or crayon) and then work to beat it. It doesn’t sound like the team has a date that they are committed to hitting. This can be the death of many of promising start-up.
Please do not conclude that we couldn’t meet a deadline to save our lives. In every case, we have deferred the launch in order to improve the quality of our products. We could in fact have launched on January 1st, 2008, as originally planned — and the product we had ready at that time was better than what was originally planned.
This may be a slow death by good intentions. No development team ever slips a product to make it worse (in their own mind).
However, we deemed it to be unacceptable, so we pushed the deadline back.
As a rule of thumb the second time this happens you have to start to reduce the scope of your efforts and the mission you are trying to accomplish. In particular, bootstrappers have to sell what they have. Gordon Bell writes about the “Schedule Fantasy Factor” which he defines as the ratio of the time allocated to a particular task divided by the time it actually took. His belief is that a ratio above 1.2 puts a project in trouble: if it’s above 2 he believes that you are doing research, not product development.
The same thing happened in mid-March; Swat and Storyteller were better than we had expected back in January — but they still weren’t good enough. The changes we have been making have dramatically improved our technology. Yes, it’s frustrating to have to wait. You think you’re frustrated? However much you’re frustrated, I’m frustrated a lot more. But we only get one chance to show off to the venture capitalists, and we want to make this our best shot.
Normally the venture capitalist’s question is not “can you make this work?” but who wants to buy it, how much will they pay, and how many of them are there? Remember lesson 5, the real risk is not that you can’t ultimately do what you have set out to do, but that once you have a working technology you will discover that the market you anticipated for it does not exist. It’s a risk that many innovative start-ups face.
April 1st, 2008
Adapted from a presentation on “Now What? Your Post Launch Growth Plan”
at the KASE Entrepreneur Seminar on October 16, 2007.
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:
- 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.
- 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 we 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.
Iin 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 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, WebEx Office was originally developed by Intranets.com, which was an intranet application where typically a manger is sending 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 scam them amount of 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.