Tech Life Most start-ups fail

1.0

Max was a mess. We were on our third mojito at The Basin in Saratoga when it just came pouring out of him. The last 72 hours involved:

  • Two days in Los Angeles babysitting a customer’s data center
  • Four hours of sleep
  • Two huge arguments with his wife on the cell phone
  • A marathon conference call with his boss, which resulted in a new trip to Chicago in two days

The mojitos might’ve been talking, but it sounded like Max was sure that his wife was going to leave him; his company was about to crumble; and he was 12 hours and one plane flight from a nervous breakdown.

He said, “Shipping a 1.0 product isn’t going to kill you, but it will try”.

Understanding 1.0

In your career as a software developer, you’re going to be screwed at some point. I’ve got you covered there. Start here, keep thinking, don’t yell, treat those you work with decently, and you’ll be fine. It’s valuable experience, but it’s nothing compared to 1.0.

1.0 is developing the first version of a new product. It’s what all those start-ups are busily doing right now. They’re working on some 1.0 idea that’s good enough that a handful of bright people will forgo their lives in support of the chance of being right… SEE, we had a great idea… We’re bazillionaires and we were right.

Most of those start-ups fail.

Before Fucked Company, failing was a quiet, somber thing. The dot-com explosion made colossal flame-outs front page news and everyone discovered what most of us already knew.

Really. Most start-ups fail.

Why?

To understand the difficulty of 1.0, I need to give you a model for understanding how a 1.0 software product actually shows up. I’ve designed just such a model by heavily borrowing for a theory known as Maslow’s Hierarchy of Needs, which is worth talking about all by its lonesome.

Maslow’s theory contends that as humans meet their basic needs, they seek to satisfy successively higher needs that occupy a set hierarchy that looks like this:

maslow

At the bottom of the pyramid is the biggest area of need: physiological needs. These are the basics: food, drink, air, sleep, etc. The idea is that you won’t be able to focus on anything else in the hierarchy if these needs aren’t met. Think of it like this: who cares about falling in love if you can’t breathe?

Moving up the hierarchy, you have safety needs, love/belonging, esteem, and, finally, the oddly named self-actualization tip of the pyramid, which is our instinctual need to make the most of our unique abilities. Translation: writers write, singers sing.

There’s a fine entry in Wikipedia regarding Maslow’s Hierarchy if I’ve piqued your interest. Personally, as a manager of humans, I stare at the hierarchy when dealing with folks on the edge. The Hierarchy gives me insight into where exactly a person is stressing out. Are they in need of career advice? (Easy) Or do they need marriage advice? (Harder)

Rands 1.0 Hierarchy

In thinking about the difficulties of 1.0, I realized that Maslow’s model fundamentally applied to shipping the first version of a product. There’s a hierarchy that defines what you need to build in order to ship 1.0 and it sort’f looks like this.

rands hierarchy

Sidebar regarding Charts’n’Graphs: Phillippe Kahn, the founder of Borland, told a great story about statistics that I think equally applies to Charts’n’Graphs. The story is, “Did you know it’s a statistical fact that people with larger feet tend to be better spellers? [insert awe] It’s because people with bigger feet are older.”

Charts’n’Graphs paint the world in a clean, linear fashion that serves one purpose: support the message of the author. Do not trust Charts’n’Graphs, but don’t let that lack of trust blind you to the intent of the story.

Pitch

At the top of the hierarchy, there’s Your Great Idea. I’m calling it pitch because I’ve got this alliteration thing going on. You can’t get anywhere in building a product or a company without a phenomenal pitch. It doesn’t matter if you’re Mr. Charisma; you’ve got to have the idea because it defines the structure and constraints of everything below it. If you don’t have the idea, you don’t know who to hire, which is the second layer — people.

Before we talk about this second layer, let me first congratulate you. I’m tripping over myself happy that you’ve discovered the Next Big Thing, but there are some basic facts to pay attention to. The first is:

Fact #1: You’re in a hurry

You’re a fool if you think you have exclusive rights to your pitch. There are too many bright people staring at exactly the same infinite pile of evolving information to assume your innovation is original. The only thing that gives you this right is delivering 1.0 and first, you’re going to need some people.

People

With your pitch in hand, you’re going to find the people to build your idea. These are your founders. These are the folks who will not only build your 1.0, but, more importantly, your engineering culture. Their arrival presents a challenge and a twist to the pyramid.

Your first few hires walk into a blank slate. Sure, they’ve got you, the keeper of the Great Idea, with your pitch and endless enthusiasm, but they don’t know where to find the bathroom. More importantly, they’ve got to digest the pitch and start to build your 1.0.

The moment one of your founding engineers starts writing code he/she is making a decision about the eventual product. It the first of innumerable decisions which will be made and as the Keeper of the pitch, you’re probably going to try to stay involved, but simply can’t be there for every decision. What you should be focusing on is the pitch. Your job is to listen to people and continually refine the idea so much that it can guide when you’re not there to clarify. This leads us to our twist. The Rands 1.0 Hierarchy is much scarier than Maslow’s because it looks like this:

inverted rands hierarchy

There’s a good reason why folks don’t build their pyramids like this — they fall over. The only way to keep them from falling over is to constantly push one side or the other. This is your start-up. This impractical concept with your pitch sitting at the bottom… defining everything above it. What will kill you about 1.0 will be how much time you’re going to trying to keep this pyramid balanced, which brings us back to the topic at hand, people.

Fact #1: No one is indispensable

Now, I’m a people person. This entire weblog is devoted to figuring out how to make sure folks get along and get stuff done, but we’re not talking about an established company here, we’re talking about 1.0 and the rules are different because you are an unknown quantity and everyone is expecting you to fail.

Ever built a fire? What do you need? A match, some paper, and some kindling wood that catches fire easily. Your first three hires are your kindling. Their job is not to define the product roadmap, their job is to get things moving, and if things aren’t moving, you need to get some more wood.

At my start-up, I was brought in as the first engineering manager. The Founders had brought on two Free Electrons with totally different temperaments. One was burning the midnight oil on getting a working prototype done. He was fully aware we’d throw the whole thing away, but he knew that the ability to see the idea in code would change everyone’s opinion of what we were doing. It would make the pitch real.

The other Electron also loved the pitch, but he was working on infrastructure for future products. HE WAS WHAT? Yes, we had no product and one of our key hires was already investing in the future. When is investing in the future a bad idea? How about when the now is not defined? The Free Electron was working under the assumption that 1.0 would be successful and while I appreciated his enthusiasm, let’s remember Fact #0: Start-ups almost always fail.

I spent some time with the Free Electron and, as it often goes with very bright people on a mission, it was clear he wasn’t going to be swayed, so I let him go. That day. One quick meeting with our VP and it was done.

If you’ve read my article about Free Electrons, you’ll know that you don’t run into these types of stunning engineers very often. Firing a Free Electron is pretty stupid for most companies because they have so much potential, but here’s the deal: you aren’t a company until 1.0 is done. A great way to topple your fledging pyramid is to hire folks who are not getting the product done with a sense of urgency. Get 1.0 done and then worry what’s next.

Process

There is no word that irks engineers more than process. Try it right now. Get everyone in your office and say something like, “I’ve defined a new process to assist our bug triage”. Watch their faces sag. They hear “busy work”. They think “management is trying to justify itself”.

This is not the word that defines the third level of the Hierarchy.

Fact #2: Process defines communication

Process is the means by which your team communicates. Whether this is via a wiki, email, or the hallway, any team larger than one needs to define a means to share information. This is not an argument for specifications, documentation, or a whiteboard filled with do’s and don’ts. You just need to agree how you’re going to share information.

When your second engineer decides, “Yes, I’m going to capture my design decisions in a wiki”. That’s process. When your third engineer starts tracking bugs on that huge whiteboard in the meeting room, that’s process. It doesn’t have to be good, it doesn’t even have to be universally agreed upon on, it just has to be stuck in a place where every can see it.

SourceSafe was the repository of choice when I landed at my first start-up. Stop laughing. It did a fine job of with a team of six engineers who had zero time to worry about source control. Sure, it was slow as a hell and lost a days work here and there because of various hiccups, but we were working on 1.0 and who had time to think about something more reliable?

Roland did.

Roland was a junior engineer and he was a Perforce fan. Roland did what any good employee of a start-up would do. Over the course of a weekend, he set up a Perforce server, rewrote all of our build tools, and scheduled a 10am meeting on the following Monday, promising Krispy Kreme donuts. His message: “This is the way it is. Everything works better. Thank you and have a donut.”

In a weekend, Roland fixed a major flaw in our process (crappy tools) and also demonstrated another fact of the hierarchy.

Fact #3: Each layer shapes and moves those near it

A sure sign of a healthy pyramid is that one layer invades another. Think of each change to people, process, and pitch as a shove in one direction. This movement requires compensation in the other layers otherwise the whole thing falls over. Roland’s decision to change the engineering process pissed off some folks. We lost some time to some source management edge cases that Roland hadn’t thought of, but, within a week, we’d adjusted. Even the most vocal opponent of the change ended up in Roland’s office arguing about how we could make it better.

If, in your organization, your pyramid is not constantly adjusting to keep itself upright. Something’s wrong. If the new folks aren’t testing the pitch, they either don’t buy it or they don’t get it. If your engineers aren’t arguing about the way they develop software ALL THE TIME, they’re becoming stagnant and that trickles down to your pitch and trickles up to your product.

A great stagnation warning sign during 1.0 is when someone decides to create an organization chart defining “This is who does what”. Now, investors and outside parties need this org chart to get a sense of whether you’re real or not, but your 1.0 team does not. The whiteboard in the corner of the room, which lists who is doing what, is your org chart. The definition and hierarchy an org chart portrays is the first step in creating a culture of secrecy in your org. That might work for Apple, but you’re not Apple, yet. You’re hope and hard work.

Product

At some point, you’re going to need to fake being done. You’re going to need to release something which barely looks like your pitch because you don’t have product until a neutral party stares at something.

Fact #4: You don’t have a company until you have a product

Product is not pitch. Pitch is the three sentence idea which gave you the credibility to hire the people. The people argued about the pitch, they created process to refine and develop the pitch, and that changed it. The pyramid wobbled hither and fro during all of this… maybe it fell completely over and you scrambled to stack those layers up again. Good job, there. You still don’t have product.

The neutral parties, your customers, need to see what you’ve been building because all your people are completely insane. All that healthy shifting of the pyramid has been taxing them. Each shove forced them to adjust their perspective of the pitch, their relation to it, and adapting to change is fucking exhausting. Folks who say, “I like change” are not currently working at a start-up. Folks at a start-up don’t say much because they’re busy adapting to the latest pyramid shift.

This state of constant change is the leading cause of start-up burnout and it’s also the reason you’ve got to get that product out. The perspective of the neutral party is essential validation because you’re nuts. Your pitch has been dissected and redefined so many times that it may no longer be something that is useful. A neutral party doesn’t care about the pitch, your people, or any of the pyramid shoving you’ve been up to; they just care whether the product is useful.

Using the Pyramid

At no point will you ever draw this hierarchy on a whiteboard during an organizational crisis and say, “FOLKS, PAY ATTENTION TO THE PYRAMID — SO SAYS THE RANDS”. The idea is to give you a tool that reminds you, “Hey, it’s all connected!” The pitch guides the people. The people refine the pitch. People and pitch create process and product, and, yeah, it’s all a big mess and that’s why start-ups fail.

The pyramid gives you a hazy map to think about the problems your company might face. People will yell in the hallway and it might sound like they’re arguing about product, but keep listening, maybe it’s process. Even worse (better?), maybe it’s pitch. Your one job as Keeper of the Pitch is to figuring out which layer of the pyramid is being tested and then figure out which way to shove the pyramid. This leads us to our last fact:

Fact #5: The lower the failure, the higher the cost

A year into my start-up, the Founders were at a crossroads. We were doing an enterprise web application that was built for onsite deployment. Problem was, everyone was going loopy about hosted services. The pitch there was: “Look how much time and energy I’ll save you by hosting this application in my data center, not yours”. This idea flew in the face of years of Oracle, PeopleSoft, and IBM domination of that huge pile of business software and hardware sitting in your data center, but it was the Internet… and the Internet was going to save the world.

The Founders changed their pitch. “We’ll just create copies of the software in our data center! We’ll save money keeping our bits close to home!” No huge difference there? Wrong. This adjustment to our pitch changed the engineering with the addition of a data center component and, more importantly, it fundamentally changed the architecture of the product. Rather than have hundreds of customized versions of our software sitting in various data centers, we had to have one copy of our software which was configurable to each of our customers needs and that wasn’t the product we designed.

It wasn’t an instant disaster. We had piles of money to throw at this transformation, but the transition cost became so great that we stopped working on anything except getting the hosted application working and, right about then, the bubble burst.

Let’s call failure a really bad decision. It’s when you choose to change something and that change percolates up through the pyramid. If you make a bad decision regarding version control, well, you can probably adjust to that. You can fire a Free Electron and probably find another bright person who can channel the pitch better, but you’re probably going to rattle more than you think. A failure of pitch is a structural failure that affects your entire company. Everything in your company depends on the vision that you’ve presented and screwing that up can be fatal.

Building Culture

If you’ve actually got a pitch ready to go, again, that’s terrific. This totally conceptual model I’ve thrown together doesn’t cover some major topics that you need to understand. How are you going to fund this thing? Where do you find VCs? Where do you find great people? Your life will become an endless list of questions and decisions and you’ll probably forget everything I just wrote in your frenetic sprint to keep your pitch alive, so I’ll simplify. The hierarchy I describe is not a model for how to build a great product; it’s a picture that describes the culture of your company. That’s what you’re really building in 1.0. A lasting, interesting culture which, if you’re lucky, continues to produces great products.

Think of your five favorite companies and think about what made them successful. Yes, they probably had a great 1.0. Think Apple ][. Think of the first time you saw Netscape. Those products are the end result of people killing themselves to get the damned thing out the door, but they weren’t just creating that product. Their work defined the culture of the company and that is what modeled their future success.

9 Responses

  1. Alex Montgomery 10 years ago

    I think you’ve swapped the top layers of the Rands Pyramid…

    Or was that the secondary point of the article? you’re building a process that lasts beyond the 1.0?

    I probably shouldn’t read these articles right after I wake up.

  2. Nope, you’re right. It’s swapped. (And fixed)

    Maybe I should finish articles after midnight. Thanks..

  3. anontexan 10 years ago

    This has been out on the internets for quite some time, so it may well have already been read by anyone reading this comment, but jwz’s account of the push for 1.0 of Netscape is pretty interesting reading that describes what it’s like to be an engineer on that 1.0 push.

  4. Brilliant, as usual. So much hitting so close to home. 🙂

  5. Bryan 10 years ago

    Great article, I actually did the same “weekend conversion to Perforce” at my startup and it worked wonders even though there were a lot of objections initially.

  6. surfingmarmot 10 years ago

    As I read your essay, i thought of an interesting analogy: biological life. IN the fundamental early years of higher organisms, they need the appropriate nutrients and encvironment to build a sound foundation (body) with which to live the rest of their lives. If that body is warped or imparied, say through nutritional deficiencies, their lives will be limited. thus it is with startups and you Free electorns and first fundametal employees: they build the skeletal frame on whcih the muscles and sinews of the company will grow. Get is wrong and it will never run a race at Olympic speeds–its just isn’t in its capability. Maybe genes and DNA your ideas and your first employees are really like RNA?

  7. … reiterate the comment above: So much hitting so close to home. Worked for a start-up whose pyramid just toppled over… over and over again.

  8. As I read your text and think about the various projects I worked on over the past fifteen years, I realize that there is another important reason: a 1.0 is as much about learning as it is about building. Many things making up 1.0 will have to be replaced with a better solution even if, from the outside, nothing changes. It simply means that working from 1.0 onward needs to take into account fixing/improving to get the product better suited for future enhancements.

    Rule #1: Even if you don’t look for alternatives and just go on with business as usual you still are making a choice. Just an uninformed one.

    The problem however, is that not many people understand what exactly made their product a success in the first place. People, involved from different departments, will all see their contribution as the key element. They might be so confident as to get involved in their own start-up and they will probably fail. They didn’t learn from a succesfull 1.0 and assume that repeating prior a contribution [because it was the key contribution] will automatically result in similar success.

    I dare say that many who today run a succesfull business would, putting back the circumstances to the original situation, just as likely fail if there would be just a small fluctuation in environment. For them, a 1.0 could even be a second product, but there is no guarantee it will be a success. As a company they might survive because of earlier success.

    Rule #2: Statistically, if enough attempts are started, some will succeed. That doesn’t mean that success was a direct result from the efforts put into the attempt. (In psychology, there are some fascinating experiments and how people react with regard to this rule)

    Equaly bad is someone in charge who read some book and chose a methodology, but is otherwise new in a field. There is no substitute for experience, but that means that you need a person who has looked back after each milestone to check whether what was planned to happen did indeed happen. Some managers see looking back as a negative thing, but they are simply denying themselves vital information for future projects. Each involvement in a 1.0 attempt will add to the experience to make future attempts more likely to succeed.

    Rule #3: A methodology is like Polaris, the star hovering the North Pole: ideal for getting your bearings, but the goal is never to actually go there. (This also goes for Rands upsidedown piramide)

    Since my very first project have I always tried to get back to the origin: where did the specs come from? Who was the first customer? Who designed/build the various part and what was the motivation behind those choices? If possible, what do customers say? Asking questions will results in anekdotes and long walks down Memory Lane, but to understand where a product is and where it came from, it is essential. (Plus, listening makes more friends then talking.)

    Important is that the reason that something got started might not be reason enough to continue (see rule #1)

    From very early on have I been a designer/key-developer/projectleader and I have tracked many projects that I wasn’t even involved in directly. Those who were involved might not have seen it as important information, but I did.

    I say this as much to whoever reads this as to myself. Currently I am in the process of defining a product for a start-up that I will be creating with two partners. I will be in charge of the technical aspects and, although I’ve done projects many times before and I am an independent software developer at the moment, it is the first time that I am this closely involved in building a company.

    I am confident that we will succeed or I would not be involved, but I will take a lot of effort. Being human (or at least closely resemble one enough to fool even myself), I am prone to the same over-confidence that repeating prior contributions will lead to success. However, my businesscard reads (my own choice ): programmer, because basically, I create programs.

  9. I’m in a similar position with Eddie.

    Due to my fanatical efforts we have 30% of our product as a 1.0 (ie. a client using this part). Another 70% needs preparing. We have made practically 0 investment in money until now – thats why I say “fanatic efforts” 😛 . If we continue this way (zero investment), some competitor will shurely arize and drive over us with a competitive product.

    In my business card it reads “business partner”. Most of the work I do is programming, but in a startup the free electrons mostly have to do whatever is nessecary – program, administer, manage, sell, plan … . Thats why I don’t restrain myself to being a “programmer”.