Monthly Archives: April 2013

Introduction to the Group Grope

The military is a wonderful experience in life. Where else can you learn that a “Cluster Fuck” is a bunch of people busily working hard at nothing intelligible or productive? It’s a profane, yet colorful description of a business process many of us see every day. (Nice people use the phonetic terms. “Hey, look at that Charlie Foxtrot!”)

Yesterday when doing my startup standup startup blog entry, I used another one of those terms, not heard as much, the group grope.

Ever been to a group grope? If you’ve spent any time in the business community, I’m willing to bet you have.

A group grope is when people, who do not bear responsibility, assemble for purposes of solving a problem which none of them have the information or skills to solve.

So that last time your team got together to talk about source control, when none of you have the power to make a decision about what to do, or even have experience using various tools? You know, where you left feeling pretty good, but with the vague feeling that things were unresolved? That’s a group grope.

Group gropes are fun, yet subtly frustrating. You get to take time off from work, see your friends, talk about some issues of importance, get caught up. That’s all great. The next step, and the key indicator of a good group grope, is when each person asks the other what they know or can do about the problem without getting any positive result. “I don’t know how marketing feels about that, Bob, have you spoken to them?” “Those guys in marketing are doing a great job, and I’ve heard it could be a problem, Frank? Have you met with them lately?”

It’s like a Scooby Do episode where the mystery is never solved. It’s just a bunch of kids wandering around asking questions of each other.

It feels good, there’s a lot of fun people involved, you get to explore areas you normally don’t go into, but at the end of the day you’re left empty and unfulfilled. There’s no long-term benefit.

You can short-circuit a group grope, sometimes, by simply announcing you are in one. “Is there anybody here responsible for X? Also, guys, don’t we need some folks who know Y and guys from over in the Z department? Without them I can’t see us making much progress, can you?”

Be sure to separate a group grope from a brainstorming session. Brainstorming sessions are there to create potential ideas about a problem. The meeting ends, you have a list. You probably also have some assimilation and analysis to do to turn the list into action. Group gropes end with everybody knowing a little more about problem X, mostly trivial stuff, but nothing else of value can be gained from it.

Sometimes when you’re in a group grope you can stop it. Many times you cannot. Many times it’s just best to lie back and think of England. But if you’re the one responsible for setting a meeting up, and somebody calls “group grope” on you, it’s a good time to either kill the meeting and let folks return to work — or figure out what the hell you’re all supposed to be doing that’s going to be useful to the company. Don’t confuse social fun and a sense of learning with accomplishing something valuable.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Startup Standup Startup

standup-iconsI’ve been coworking at a nearby town and a couple of us decided to try to help encourage each of us in our startups.

Being a startup junkie and an Agile Coach, I thought, “Why not a startup standup?” Each week we meet in person. There, each of us announces what they accomplished in the last week, what they’re planning in the next week, and what they’re number one problem is. No classes, no group-gropes, no fluff. Immediately after the ten-minute standup we can each help each other if one of us has an obstacle that we know about. Plus we can help each other position our work mentally in order to focus more on the right stuff and less on the wrong stuff.

So how to describe what we should be talking about?

I pulled down a couple PG essays, a blog on the Lean Startup concept, and some notes Derek Sivers made while reading the Lean Startup book. But heck, it was still too much verbiage. Put together, it was WAY too much to expect noobs without context to plough through. I decided to cut a bit. So here’s an effort to make a crash course in what you should know and talk about during a weekly report of your activities in a startup. I liberally edited for clarity and brevity.

1. What is a startup? (From PG’s 2012 essay)

Not every company is a startup. Millions of companies are started every year in the United States. Only a tiny fraction are startups. Startups are companies that make something people want that have the ability to scale rapidly. They may or may not involve technology.

For a company to grow really big, it must (a) make something lots of people want, and (b) reach and serve all those people. Barbershops are doing fine in the (a) department. Almost everyone needs their hair cut. The problem for a barbershop, as for any retail establishment, is (b). A barbershop serves customers in person, and few will travel far for a haircut. And even if they did the barbershop couldn’t accommodate them.

Writing software is a great way to solve (b), but you can still end up constrained in (a). If you write software to teach Tibetan to Hungarian speakers, you’ll be able to reach most of the people who want it, but there won’t be many of them. If you make software to teach English to Chinese speakers, however, you’re in startup territory.

Most businesses are tightly constrained in (a) or (b). The distinctive feature of successful startups is that they’re not.


2. Do you need a cool idea?

No, you do not.

3. What are you concentrating on and talking about while you are developing your startup? You are creating and testing value and growth hypothesis. A value hypothesis is a concrete way to determine what you are doing has value to your customer. A growth hypothesis is a concrete way to determine how you gain new customers. These are both measurable, and you have to have real results that indicate success or failure for your hypothesis. That means heavy, direct interaction with the people you are supposed to be making things that they want. More Lean Startup goodness from Sivers’ notes:

Startups are human institution designed to create new products and services under conditions of extreme uncertainty.

The stories in the magazines are lies: hard work and perseverance don’t lead to success. It’s the boring stuff that matters the most.

Startups exist to learn how to build a sustainable business. This learning can be validated scientifically by running frequent experiments.

The goal of a startup is to figure out the right thing to build – the thing customers want and will pay for – as quickly as possible.

Too many startup business plans look more like they are planning to launch a rocket ship than drive a car. They prescribe the steps to take and the results to expect in excruciating detail, and as in planning to launch a rocket, they are set up in such a way that even tiny errors in assumptions can lead to catastrophic outcomes.

The customers failed to materialize, the company had committed itself so completely that they could not adapt in time. They had “achieved failure” – successfully, faithfully, and rigorously executing a plan that turned out to have been utterly flawed.

Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop. Through this process of steering, we can learn when and if it’s time to make a sharp turn called a pivot or whether we should persevere along our current path.

Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning.

Learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what customers want can be eliminated. I call this validated learning because it is always demonstrated by positive improvements in the startup’s core metrics. As we’ve seen, it’s easy to kid yourself about what you think customers want. It’s also easy to learn things that are completely irrelevant. Thus, validated learning is backed up by empirical data collected from real customers.

Learn to see every startup in any industry as a grand experiment. The question is not “Can this product be built?” In the modern economy, almost any product that can be imagined can be built. The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?” To answer those questions, we need a method for systematically breaking down a business plan into its component parts and testing each part empirically.

One of the most important lessons of the scientific method: if you cannot fail, you cannot learn.

A true experiment follows the scientific method. It begins with a clear hypothesis that makes predictions about what is supposed to happen. It then tests those predictions empirically. Just as scientific experimentation is informed by theory, startup experimentation is guided by the startup’s vision. The goal of every startup experiment is to discover how to build a sustainable business around that vision.

A minimum viable product (MVP) is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort. The goal of the MVP is to begin the process of learning. Its goal is to test fundamental business hypotheses.

Most entrepreneurs approach a question like this by building the product and then checking to see how customers react to it. I consider this to be exactly backward because it can lead to a lot of waste. First, if it turns out that we’re building something nobody wants, the whole exercise will be an avoidable expense of time and money. If customers won’t sign up for the free trial, they’ll never get to experience the amazing features that await them. Even if they do sign up, there are many other opportunities for waste. For example, how many features do we really need to include to appeal to early adopters? Every extra feature is a form of waste, and if we delay the test for these extra features, it comes with a tremendous potential cost in terms of learning and cycle time. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time. [Which may include actually building anything at all]

(Dropbox:) To avoid the risk of waking up after years of development with a product nobody wanted, Drew did something unexpectedly easy: he made a video. The video is banal, a simple three-minute demonstration of the technology as it is meant to work. It was all he needed at first to test a value hypothesis. Many entrepreneurs refuse to spend any time in development at all until some initial value and growth hypotheses have been tested in the real world and they have real metrics from the tests. (Anecdotes, like “I showed it to twenty people and they liked it” are not real metrics)

MVP can seem like a dangerous branding risk. Easy solution: launch the MVP under a different brand name. Experiment under the radar and then do a public marketing launch once the product has proved itself with real customers.

Prepare for the fact that MVPs often result in bad news.

The solution to this dilemma is a commitment to iteration. You have to commit to a locked-in agreement – ahead of time – that no matter what comes of testing the MVP, you will not give up hope.

A startup’s job is to
(1) rigorously measure where it is right now, confronting the hard truths that assessment reveals, and then
(2) devise experiments to learn how to move the real numbers closer to the ideal reflected in the business plan.

The failure of the “launch it and see what happens” approach should now be evident: you will always succeed – in seeing what happens. Except in rare cases, the early results will be ambiguous, and you won’t know whether to pivot or persevere, whether to change direction or stay the course.

Entrepreneurs need to face their fears and be willing to fail, often in a public way. In fact, entrepreneurs who have a high profile, either because of personal fame or because they are operating as part of a famous brand, face an extreme version of this problem.

I recommend that every startup have a regular “pivot or persevere” meeting.

Remember that the rationale for building low-quality MVPs is that developing any features beyond what early adopters require is a form of waste. However, the logic of this takes you only so far. Once you have found success with early adopters, you want to sell to mainstream customers. Mainstream customers have different requirements and are much more demanding. A pivot is required.

Startups don’t starve; they drown.

Startups have to focus on the big experiments that lead to validated learning. The engines of growth framework helps them stay focused on the metrics that matter.

Companies using the sticky engine of growth track their attrition rate or churn rate very carefully. The churn rate is defined as the fraction of customers in any period who fail to remain engaged with the company’s product. The rules that govern the sticky engine of growth are pretty simple: if the rate of new customer acquisition exceeds the churn rate, the product will grow. The speed of growth is determined by what I call the rate of compounding, which is simply the natural growth rate minus the churn rate.

Focus needs to be on improving customer retention. This goes against the standard intuition in that if a company lacks growth, it should invest more in sales and marketing. This counterintuitive result is hard to infer from standard vanity metrics.

4. So formulating and reporting on hard metrics resulting from direct user contact that prove or disprove our value and growth hypotheses is what we should focus on. Once we do that, what are some common mistakes? (From PG’s 2005 essay)

  • Release Early. get a version 1 out fast, then improve it based on users’ reactions. By “release early” I don’t mean you should release something full of bugs, but that you should release something minimal.
  • Keep Pumping Out Features. I don’t mean, of course, that you should make your application ever more complex. By “feature” I mean one unit of hacking– one quantum of making users’ lives better. [Which should directly come from your hypotheses testing results]
  • Make Users Happy. There are two things you have to do to make people pause. The most important is to explain, as concisely as possible, what the hell your site is about. How often have you visited a site that seemed to assume you already knew what they did? The other thing I repeat is to give people everything you’ve got, right away. If you have something impressive, try to put it on the front page, because that’s the only one most visitors will see. Though indeed there’s a paradox here: the more you push the good stuff toward the front, the more likely visitors are to explore further.
  • Fear the Right Things. Most visible disasters are not so alarming as they seem. Disasters are normal in a startup: a founder quits, you discover a patent that covers what you’re doing, your servers keep crashing, you run into an insoluble technical problem, you have to change your name, a deal falls through– these are all par for the course. They won’t kill you unless you let them.And in any case, competitors are not the biggest threat. Way more startups hose themselves than get crushed by competitors. There are a lot of ways to do it, but the three main ones are internal disputes, inertia, and ignoring users. Each is, by itself, enough to kill you. But if I had to pick the worst, it would be ignoring users. If you want a recipe for a startup that’s going to die, here it is: a couple of founders who have some great idea they know everyone is going to love, and that’s what they’re going to build, no matter what.
  • Commitment Is a Self-Fulfilling Prophecy. I now have enough experience with startups to be able to say what the most important quality is in a startup founder, and it’s not what you might think. The most important quality in a startup founder is determination. Not intelligence– determination. [In fact, intelligence, like funding, can be counter-indicative of success.]Time after time VCs invest in startups founded by eminent professors. This may work in biotech, where a lot of startups simply commercialize existing research, but in software you want to invest in students, not professors. Microsoft, Yahoo, and Google were all founded by people who dropped out of school to do it. What students lack in experience they more than make up in dedication. You can lose quite a lot in the brains department and it won’t kill you. But lose even a little bit in the commitment department, and that will kill you very rapidly.
  • There Is Always Room. So for all practical purposes, there is no limit to the number of startups. Startups make wealth, which means they make things people want, and if there’s a limit on the number of things people want, we are nowhere near it. I still don’t even have a flying car.
  • Don’t Get Your Hopes Up. This is another one I’ve been repeating since long before Y Combinator. It was practically the corporate motto at Viaweb.Startup founders are naturally optimistic. They wouldn’t do it otherwise. But you should treat your optimism the way you’d treat the core of a nuclear reactor: as a source of power that’s also very dangerous. You have to build a shield around it, or it will fry you.The shielding of a reactor is not uniform; the reactor would be useless if it were. It’s pierced in a few places to let pipes in. An optimism shield has to be pierced too. I think the place to draw the line is between what you expect of yourself, and what you expect of other people. It’s ok to be optimistic about what you can do, but assume the worst about machines and other people.This is particularly necessary in a startup, because you tend to be pushing the limits of whatever you’re doing. So things don’t happen in the smooth, predictable way they do in the rest of the world. Things change suddenly, and usually for the worse.

    Shielding your optimism is nowhere more important than with deals. If your startup is doing a deal, just assume it’s not going to happen. The VCs who say they’re going to invest in you aren’t. The company that says they’re going to buy you isn’t. The big customer who wants to use your system in their whole company won’t. Then if things work out you can be pleasantly surprised.

    The reason I warn startups not to get their hopes up is not to save them from being disappointed when things fall through. It’s for a more practical reason: to prevent them from leaning their company against something that’s going to fall over, taking them with it.

  • Speed, not Money. The way I’ve described it, starting a startup sounds pretty stressful. It is. When I talk to the founders of the companies we’ve funded, they all say the same thing: I knew it would be hard, but I didn’t realize it would be this hard.So why do it? It would be worth enduring a lot of pain and stress to do something grand or heroic, but just to make money? Is making money really that important?No, not really. It seems ridiculous to me when people take business too seriously. I regard making money as a boring errand to be got out of the way as soon as possible. There is nothing grand or heroic about starting a startup per se.So no, there’s nothing particularly grand about making money. That’s not what makes startups worth the trouble. What’s important about startups is the speed. By compressing the dull but necessary task of making a living into the smallest possible time, you show respect for life, and there is something grand about that.

I could probably tighten this up a lot further given some more time, but it’s definitely decreased in size from the 50 pages it started out as!


So 1st, definition of a startup:

Here are some notes from the book Lean Startup. Good stuff in here.

Value Hypotheses.

Finally, some common mistakes.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Everything I Knew About Startups Is Wrong

Here’s a short list of the things I thought at one point which aren’t true.

  • Startups are about high technology. False. Startups are about making things that people want that scale. Yes, technology can help you scale, but it’s not required
  • Startups are all about hard work. False. Yes, startups require hard work, but there is also a luck element too (This is the main reason most of the other things I knew to be true weren’t)
  • You have to have a cool idea to make a lot of money in a startup. False. “Business Porn” has been sold to me since I was a teenager. The idea that cool businesses are also are very dramatic — great idea, super-cool founders, overcoming impossible odds, having something special about them that nobody else has. Hollywood and the book industry love this stuff, and it’s ruined millions of people’s ideas of what startups and business is all about. Most all of the time, it’s just work. Sure, it’s work you love, but lose the dramatics and focus on execution. Ideas are useless. It’s all execution.
  • Venture Capitalists accept plans over the net. False. Ask some VCs when the last time they took a bet on something they got over the net. Like never. If anything, they keep these web forms open as a way to figure out who to ignore. if you fill one out, they know that you have no idea how funding works, so they can permanently forget about you.
  • VCs actually know what the hell they are doing. False. Stats show that your company is no more likely to be alive after five years if you take VC money or not. Sure, if you take the money you might grow. You’ll have to grow or die. Most exercises in funding are social in nature. That means you know somebody. Some professor you know refers you to a fund, or you go to Y Combinator and make the rounds. VCs make money based on what all the other VCs are thinking and doing. Raising money is a cross between a beauty and popularity contest.
  • If your friends like the idea it’s pretty good. False. Your friends are your friends because they say nice things to you. This is true whether they’re hackers or not. What you need is customers, not friends. Get as close to the customers as you can. Live with them. Find out what they think.
  • Facebook, Twitter, and Apple can help you grow. True and False. Yes, if you win the lottery (or spend a huge hunk of time learning how to social engineer a great product), these services will let you gain a lot more traction than just being out there on the web. But apps are a sucker’s game: for every one guy posting how he made 100K there’s a thousand guys making nothing. Even if you succeed wildly, you lose. The owner of your walled garden is just going to incorporate your app into their base product.
  • Most startup founders will not tell you how they succeeded. Mixed Bag. The technology startup sector is tremendously more open than any other sector, so it’s false. Startup founders are usually more than willing to go on at length about how they did it. The crazy part is that most all of it is so unique to their particular idea, team, location, and time period. You’ll be lucky to listen to ten hours and pull 2 ideas out. Are there folks who will look at many startups and try to generalize for you? Sure! Several dozen folks. All with books, or podcasts, or seminars, or classes. There’s an entire industry out there based on you wanting to have a startup. It will bleed you dry and you’ll be no closer than when you started. Don’t be the fat guy reading Running World buying 300-dollar sneakers.
  • Most successful  startup founders know how they succeeded. I do not believe this to be a true statement. They know what worked at that particular time. They probably know why it worked. But once again, this is so contextual and people are so prone to overgeneralizing that the signal-to-noise ratio here is massively lower than it appears on the surface.
  • The best way to vet an idea is to ask other successful startup founders. Here’s where we take what we already know — there’s a lot of luck involved, advice is highly contextual, and don’t ask your friends — and add it together. The worst thing you can do with an idea is listen to others. Take the same hour you would ask and receive advice and go ask a potential customer. Find somebody who might want what you’re making. Do they like it? Would they give you money for it? If the answer is “yes”, then it doesn’t matter what all the successful founders in the world tell you. If the answer is “no”, then ask why and get real feedback from the people you’re trying to help. People can stand around the internet water cooler all day long and speculate on what might work or not. But you’re not getting anywhere. Developing a startup is about learning from the marketplace. What are you doing to learn from where it matters?

ADD: You might think that this post is terribly pessimistic. It’s not meant to be. In fact, I think the social nature of hanging out with other founders might drive out huge benefits for the new entrepreneur. I’d just be careful confusing implicit knowledge and social contacts with explicit knowledge and tactics. We focus on the explicit, the tangible, the teachable. I don’t think that’s where the good stuff is.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Transactional Disadvantage

Transaction Guys

I’ve realized something about myself that I’m not proud of: I have a transactional personality.

I’m a hacker, a bit-head, an analytical person. I push a button, something happens. If I push a button and nothing happens, I start debugging until I fix it. I expect to push buttons and have things happen.

Unfortunately this way of thinking does not work very well over the net. People are not buttons.

Let’s be clear: I don’t think I’m selfish. I hope not. I try to help others. And I have values that are more important than myself. When working closely with other people, I try to help them as much as I can. My entire Agile coaching, writing, and speaking career has been devoted to helping developers have better lives and careers. We treat developers like shit, and they need all the help we can provide. I care passionately and deeply about living in a free world and helping developers change the planet for the better.

It’s just the damned internet that’s the problem.

So I’m working along on various projects when I come across something I need that somebody might be able to help me with. Maybe proofread an article, or take a look at a video I’ve created. To me, there’s nothing illogical about just sending off an email with something like “Hey, I need a hand with this” I push a button, something should happen.

The problem is that, when you’re part of a physical office, there’s always a give-and-take going on. The number of people are finite. Somebody asks you for help, you help. You ask others, they help. When you’re not part of a physical office working with people, there’s no finite set of people anymore. It’s no longer a one-to-one relationship. The only interaction these other people might get from you are requests for things you want. This doesn’t make you a very popular person after a while. Also, many times people are busy doing other things. Never forget the infinite amount of apathy the universe has for your life and the things you are doing.

There is no debugging in this situation, and pushing the button again and again just causes worse and worse results.

The answer, of course, is to take interest in things other people want and try to help them with it. But hell, I “know” probably ten thousand people online through various channels. How could I possibly take interest in all of those folks? I try — but it’s like spitting in the wind. If I ask anybody at all for help with anything, I’m always going to be in a position of asking more from people than I can provide.

The nature of the problem here is social isolation. As a sole founder, I work by myself. I don’t have rich interactions with people. My recent coworking experiment has driven this home.

So trying to take a personal interest in a thousand people is not going to work; at least I can’t figure out how. By necessity, then, I’ve come up with a new strategy. I have no idea if it will work or not, but it’s all I’ve got: put my energy into causes I care about and let the rest work itself out.

So I started my libertarian news summary site. I’m continuing my mission to help developers with Tiny Giant Books. I can fully commit to causes that help vast numbers of people. I can look out for articles, find tips, and generally help organize and spread information that will help others, but only in tightly-defined areas. That’s about all I can do. It’ll have to be enough.

Meanwhile I need to stay aware of one of my greatest weaknesses: a transactional personality.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.