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:

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.

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:

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.