I think most people have a fairly specific image that gets conjured up when they hear the word startup. Maybe it’s the “two guys in a garage” made famous by HP, or the idea of Jobs and Wozniack walking barefoot and shaggy through the Homebrew Computer Club. Maybe it’s the more recent wunderkinds like Zuckerberg or Brin and Page. What all of these pictures have in common is a narrative that goes something like this: scrappy outsiders, possessed of a unique genius, took outrageous risks and worked incomprehensible hours to beat the odds.
But this cinematic view of entrepreneurs is flawed in many ways. Let’s start with the most basic. It leads people to mistakenly believe that any time they see two guys in a garage attempting the impossible, that’s a startup. Wrong. It also causes them to miss the numerous other kinds of startups that appear in less-glamorous settings: inside enterprises, non-profits, and even governments. And because both small businesses and startups have a high mortality rate, sometimes these images lead us to believe that any small business is a startup. Wrong again.
So let’s begin with a definition of a startup that captures its essential nature, and tries to leave behind the specific associations of the most famous startups.
A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.
Let’s take each of these pieces in turn. First, I want to emphasize the human institution aspect, because this is completely lost in the “two guys in a garage” story. The word institution connotes bureaucracy, process, even lethargy. How can that be part of a startup? Yet, the real stories of successful startups are full of activities that can rightly be called institution-building: hiring creative employees, coordinating their activities, and creating a company culture that delivers results. Although some startups may approach these activities in radical ways, they are nonetheless key ingredients in their success.
Isn’t the word human redundant in this definition? What other kinds of institutions are there, anyway? And yet, we so often loose sight of the fact that startups are not their products, their technological breakthroughs, or even their data. Even for companies that essentially have only one product, the value the company creates is located not in the product itself but with the people and their organization who built it. To see proof of this, simply observe the results of the large majorities of corporate acquisitions of startups. In most cases, essential aspects of the startup are lost, even when the product, its brand, and even its employment contracts are preserved. A startup is greater than the sum of its parts; it is an acutely human enterprise.
And yet the newness of a startup’s product or service is also a key part of the definition. This is a tricky part of the definition, too. I prefer to take the most expansive possible definition of product, one that encompasses any source of value for a set of people who voluntarily choose to become customers. This is equally true of a packaged good in a grocery store, an ecommerce website, a non-profit social service or a variety of government programs. In every case, the organization is dedicated to uncovering a new source of value for customers, and cares about the actual impact of its work on those customers (by contrast, a monopoly or true bureaucracy generally doesn’t care and only seeks to perpetuate itself).
It’s also important that we’re talking innovation, but this should also be understood broadly. Even the most radical new inventions always build upon previous technology. Many startups don’t innovate at all in the product dimension, but use other kinds of innovation: repurposing an existing technology for a new use, devising a new business model that unlocks value that was previously hidden, or even simply bringing a product or service to a new location or set of customers previously underserved. In all of these cases, innovation is at the heart of the company’s success.
Because innovation is inherently risky, there may be outsized economic returns for startups that are able to harness the risk in a new way – but this is not an essential part of the startup character. The real question is: “what is the degree of innovation that this business proposes to accomplish?”
There is one last important part of this definition: the context in which the innovation happens. Most businesses – large and small alike – are typically excluded by this context. Startups are designed to confront situations of extreme uncertainty. To open up a new business that is an exact clone of an existing business, all the way down to the business model, pricing, target customer, and specific product may, under many circumstances, be an attractive economic investment. But it is not a startup, because its success depends only on decent execution – so much so that this success can be modeled with high accuracy. This is why so many small businesses can be financed with simple bank loans; the level of risk and uncertainty is well enough understood that a reasonably intelligent loan officer can assess its prospects.
Thus, the land of startups is a unique place, where the risks themselves are unknown. Contrast this with other high-risk situations, like buying a high-risk stock. Although the specific payoff of a specific risky stock is not known, investing in many such stocks can be modeled accurately. Thus a decent financial advisor can give you a reasonably accurate long-term expected return for a set of risky stocks. When the “risk premium” is known, we are not in startup land. In fact, when viewed in retrospect, most startups appear like no-brainers. Probably the most famous example today is Google: how did we ever live without it? Building that particular product was not nearly has risky as it seemed at the time; in fact, I think it is a reasonable inference to say that it was almost guaranteed to succeed. It just wasn’t possible for anyone to know that ahead of time.
Startups are designed for the situations that cannot be modeled, are not clear-cut, and where the risk is not necessarily large – it’s just not yet known. I emphasize this point because it is necessary to motivate large amounts of the theory of the lean startup. Fundamentally, the lean startup is a methodology for coping with uncertainty and unknowns with agility, poise, and ruthless efficiency. It is a completely different experience from the equally hard job of executing in a traditional kind of business, and my goal is not to disparage those other practitioners – after all, most startups aspire to become non-startups someday.
Still, these differences matter, because the “best practices” that are learned in other contexts do not transplant well into the startup soil. In fact the most spectacular startup failures result when people were in a startup situation but failed to recognize it, or failed to recognize what it meant for their behavior.
This definition is also important for what it excludes. Notice that it says nothing about the size of the company involved. Big companies often fail because they find themselves in a startup situation but are unable to reorient in time to cope with this situation; this specific pathology is explored in The Innovator’s Dilemma. This kind of crisis can be precipitated by many external factors: macroeconomic changes, trade policy, technological change, or even cultural shifts. But most often, the entrant of a startup into a previously calm market precipitates this kind of crisis. This has significant implications for general managers in enterprise, about which you can read more at HBR: Is Entrepreneurship a Management Science?
Monday, June 21, 2010
Thursday, June 17, 2010
No departments
Big companies have departments. Startups are companies. Startups aspire to become big companies. Therefore, startups should have departments. Right?
Why do companies have departments? There are a lot of reasons: ladder of advancement, sharing of best practices, functional specialization. Each of these benefits also exists in startups, which is why most startups are also organized in departments. But I have come to believe that because of the unique context of startup land, the payoff is a lot smaller than it is for larger companies. Meanwhile the drawbacks of functional departments can cause real and lasting harm.
I once worked at a startup with an exceptional functional department system. The leaders of each department were world-class experts in their respective fields. The team hired only the best and the brightest. Looking back after a few years, it’s evident that many of the people who worked in these departments have gone on to do incredible things in industry. They are leaders, visionaries, founders and managers having tremendous success.
Yet talent organized improperly can lead to failure. I was an engineer on the engineering team. We had to work closely with artists on an art team. We sat in different parts of the building, ate lunch separately, spoke a different specialized jargon, and generally didn’t understand each other. According to the Waterfall methodology in which we worked, this shouldn’t have been a problem. After all, we rarely had to work on the same project at the same time. The art team would often be involved in the specification phase of a new feature, since they were responsible for the look-and-feel of the product. Then we’d build the feature, which would often include tools that were intended for the art team to use to build the parts of the product that they were responsible for (in video game parlance, this is the “art path” that allows artists to get their work into the production product).
Sure, some communication was necessary, especially as artists had to be trained on new tools periodically. But according to the theory, this should have been covered by the various specs and documentation we were rigorous about producing.
If anyone has ever worked in an environment like this, you’ll probably be able to imagine the things that can go wrong. For one, the engineers consider the artists stupid; the artists consider the engineers arrogant. Not a lot of trust builds up that can be used when real disagreements emerge. Instead, there’s a positive feedback loop of bad feelings. And like feedback on a simple microphone sound system, this would occasionally boil over into screeching.
I remember one such meeting vividly. I was the junior guy on a project team; I was called in to do some technical due diligence for reasons that were obscure to me, because the team already had much more senior engineers assigned to it. I was invited to a feature decision meeting, where the team was closing in on a detailed spec. The meeting was tense. The artists on the team had called in the big guns, and VP-level folks were there to explain the importance of certain aspects of the visual design that threatened to be cut. I eventually realized that I was there as part of the same plan – the art team has specifically requested someone technical but unimportant to be able to render opinions that might undermine their more senior opposition. Not to be outdone, the technologists on the team had also brought their big guns, and the meeting was packed with employees of every level – from VP’s all the way down to me.
As the meeting progressed, the temperature kept rising. At first, I couldn’t even follow the recriminations back-and-forth. Eventually, though, I realized what was at issue: the art team was insisting that the UI for this feature have rounded corners. Incredibly, they were willing to bring the company to a standstill to protest that this was an absolutely essential feature. Even more surprisingly, the engineering team was equally vocal about their contention that adding rounded corners would add weeks of development time to the project, which would have pushed it out way past its hard deadline, effectively killing it. On the surface, this was a ludicrous dispute – both sides were willing to kill the project rather than proceed with (or without) a minor UI tweak. Were they just crazy?
I don’t think so. This meeting was just the latest in a series of escalating skirmishes that had taken place over many months. The feedback loop looked something like this. The art team would create a spec for a feature, detailing the UI as best they could. The engineering team would then build that feature, mimicking the UI as close as they could using the current primitives supported by the system. When the art team would review the final product, they were inevitably outraged – it deviated from the spec in ways they considered major. So there would be a lot of scope negotiation at the very end, when it is most expensive. Sometimes, the art team would win the argument, and the engineers would pull a few all-nighters to make them happy, but feeling betrayed at the new additions to the spec. Sometimes the engineering team would win, and the art team would have to accept (and be held responsible) for a feature that didn’t really work the way they wanted, feeling betrayed at the violation of their agreement.
As an isolated incident, this wouldn’t be a big deal. But scope negotiations between departments are an example of an “iterated prisoner’s dilemma” situation, where the same parties repeatedly negotiate, and rely on their previous experience to inform their choices in the current round. Unfortunately, the equilibrium in this particular setup has one overriding outcome: longer and more detailed specs. Here’s why.
The art team feels burned that they didn’t get what they asked for. Last time, the engineers weaseled out of their commitments by point out areas where the spec didn’t specify what was really important to the artists. So this time, they are going to spell out what’s important in even greater detail, to leave less wiggle room.
The engineering team feels burned too, and feels that they were blamed for deficiencies in the spec as if it was their fault that the technology doesn’t really support what the artists want to do. So they react in two ways. First, they actively encourage a more detailed spec, and are more aggressive about pointing out possible inconsistencies. This forces the art team to make concrete decisions about stuff they don’t really care about. Second, the engineering team starts to pad their estimates, knowing that each feature in the spec is not really done when they think it’s done – there’s going to be inevitable scope creep from the art team when they finally see the final result.
What are the consequences of this more detailed spec? For one, it takes a lot longer to create, meaning that the projects themselves get larger in order to rationalize the increased investment in planning. Second, the extra detail obscures the artists’ original intent in specifying the feature, so the engineers are even more likely to miss the big picture and build the wrong things. And lastly, it removes the engineering team’s ability to find breakthrough solutions that might deliver most of the value at a fraction of the cost. They can’t use any discretion for fear of breaking the spec’s contract, even if the changes would probably go unnoticed or even be in the company’s best interests. The lack of trust (and the procedure of the Waterfall methodology) makes it very difficult to ask for clarification or changes in the spec while the implementation is underway.
This feedback is a nasty trap, and it’s just how this room full of otherwise rational adults wound up in a screaming match about rounded corners. It was painful to watch. Now, part of the reason I remember this particular meeting so well is that I wound up doing something considered really radical at the time. I suggested that we change the underlying architecture of our UI system so that the artists would be able to build their own UI pieces themselves and then integrate them into the product without requiring new code every time. It took an incredible amount of politicking and arm-twisted, but I did eventually get the teams to agree to that solution. I’m proud of that contribution, but the reason I tell that part of the story is not to show off, but rather to be able to tell you what happened next. Although both teams got something valuable about the new system, neither was very happy. I had successfully defused the situation, and by reducing the feedback loop between the artists spec and its implementation, I was able to help them realize their goals better. As a technical fix, it was brilliant. As a solution to the underlying problem, it was useless.
Neither side liked me very much for having "fixed" their problem. In particular, the artists felt like I had created a lot more work for them – they were used to having other people grapple with implementation details for them, and now they had to do it themselves. They either had to hire a developer onto the art team itself (unthinkable) or learn those development skills themselves (which was, to be fair, really hard). The engineering team wasn’t happy either. Creating this new architecture was a fair bit of work, and they couldn’t shake the feeling that I had basically sided with the enemy, giving them tools that would require a lot of engineering support but basically deprive the engineering team of any credit for the resulting features.
I’ve now come to believe that this confrontation was a direct result of the partition between the departments in this company, and that rather than seek technical solutions to the disagreement, I would have been better off working to break down those walls.
Let me tell one more story from that same company. I mentioned before the art path, the set of tools the engineering team was required to build and maintain for the art team to be able to create content. Because the art team was considered an internal customer (and “friendly” to boot), we didn’t waste a lot of time making the tools easy to use. Instead, we spent time making sure the exact behavior of the tools were well documented – by engineers, naturally.
This led to some pretty bizarre situations. One time I remember in particular, an engineer fixed a bug that was causing artists’ creations to render in our 3D environment with a skewed rotation. The details aren’t important, but it turned out that under certain relatively common conditions, the objects would come out completely upside-down.
I’m sure this engineer was expecting to be treated as a hero by the art team, since he had just fixed a major bug. But instead he was reviled. Why? The artists had known about this bug for ages, but had just assumed it was a natural part of the system. They had learned that the best way to solve problems is through trial-and-error, doing whatever it takes to get the object to look right. So sometimes the object would come out upside-down, sometimes not. When it did, they’d just invert their original work so that after the upside-down transformation, it looked right. Sure, there was a lot of randomness in whether they would need to take this extra step, but this was nothing unusual. From their point of view, the tools were full of meaningless jargon and bizarre incantations that resulted in nearly random behavior. This bug was not even considered a major one, since at least it had a deterministic fix.
But now you can see what happened when the bug was fixed. A large, but mostly random, sample of objects started rendering upside-down! This required either that we leave the bug in place, or that the art team go back and rework all those thousands of upside-down objects. Neither solution is particularly alluring.
Again, this led to lots of mutual recriminations. Why didn’t the art team come to the engineers and tell them of this bug as soon as it manifested? Why aren’t they smart enough to figure out what the tools actually do? On the other side, why don’t the engineers just deliver tools that work like they’re supposed to? Other more established companies have tools that are intuitive to use, why can’t we?
The solution to this problem is actually really simple. Just create an art path team, composed of some artists and engineers. Force them to live and work in the same physical space, force the engineers to actually do some art production, and force the artists to actually learn what the technical limits of the tools are. As the team gets traction, simply rotate members from both departments through this team, so that the knowledge they gain is eventually diffused through both organizations. And hold the leaders of that team – artists and engineers alike – accountable for a set of clear goals for the tools that are important to the company.
There’s nothing intrinsically difficult about this problem, just as their was nothing intrinsically difficult with the “rounded corners” problem I discussed earlier. The barrier to doing the right thing is the entrenched ideas originating from departments. Who would lead this team? Who would they report to? How would we ensure that the team was faithful to the best practices of both the art team and the engineering team? And plus, do we really want to be cross-training engineers in art and artists in engineering? Isn’t that a waste of time? After all, both teams are already too busy, how can we afford to pull people off and waste time?
This is another variation of the time/quality/money fallacy – the very quality problems that a team like this would address are currently wasting time and causing the team to be “too busy” to invest in the solution. So: enough with functional departments at startups. Let's start holding people accountable solely for their contribution to the only thing that matters: validated learning about customers.
Why do companies have departments? There are a lot of reasons: ladder of advancement, sharing of best practices, functional specialization. Each of these benefits also exists in startups, which is why most startups are also organized in departments. But I have come to believe that because of the unique context of startup land, the payoff is a lot smaller than it is for larger companies. Meanwhile the drawbacks of functional departments can cause real and lasting harm.
I once worked at a startup with an exceptional functional department system. The leaders of each department were world-class experts in their respective fields. The team hired only the best and the brightest. Looking back after a few years, it’s evident that many of the people who worked in these departments have gone on to do incredible things in industry. They are leaders, visionaries, founders and managers having tremendous success.
Yet talent organized improperly can lead to failure. I was an engineer on the engineering team. We had to work closely with artists on an art team. We sat in different parts of the building, ate lunch separately, spoke a different specialized jargon, and generally didn’t understand each other. According to the Waterfall methodology in which we worked, this shouldn’t have been a problem. After all, we rarely had to work on the same project at the same time. The art team would often be involved in the specification phase of a new feature, since they were responsible for the look-and-feel of the product. Then we’d build the feature, which would often include tools that were intended for the art team to use to build the parts of the product that they were responsible for (in video game parlance, this is the “art path” that allows artists to get their work into the production product).
Sure, some communication was necessary, especially as artists had to be trained on new tools periodically. But according to the theory, this should have been covered by the various specs and documentation we were rigorous about producing.
If anyone has ever worked in an environment like this, you’ll probably be able to imagine the things that can go wrong. For one, the engineers consider the artists stupid; the artists consider the engineers arrogant. Not a lot of trust builds up that can be used when real disagreements emerge. Instead, there’s a positive feedback loop of bad feelings. And like feedback on a simple microphone sound system, this would occasionally boil over into screeching.
I remember one such meeting vividly. I was the junior guy on a project team; I was called in to do some technical due diligence for reasons that were obscure to me, because the team already had much more senior engineers assigned to it. I was invited to a feature decision meeting, where the team was closing in on a detailed spec. The meeting was tense. The artists on the team had called in the big guns, and VP-level folks were there to explain the importance of certain aspects of the visual design that threatened to be cut. I eventually realized that I was there as part of the same plan – the art team has specifically requested someone technical but unimportant to be able to render opinions that might undermine their more senior opposition. Not to be outdone, the technologists on the team had also brought their big guns, and the meeting was packed with employees of every level – from VP’s all the way down to me.
As the meeting progressed, the temperature kept rising. At first, I couldn’t even follow the recriminations back-and-forth. Eventually, though, I realized what was at issue: the art team was insisting that the UI for this feature have rounded corners. Incredibly, they were willing to bring the company to a standstill to protest that this was an absolutely essential feature. Even more surprisingly, the engineering team was equally vocal about their contention that adding rounded corners would add weeks of development time to the project, which would have pushed it out way past its hard deadline, effectively killing it. On the surface, this was a ludicrous dispute – both sides were willing to kill the project rather than proceed with (or without) a minor UI tweak. Were they just crazy?
I don’t think so. This meeting was just the latest in a series of escalating skirmishes that had taken place over many months. The feedback loop looked something like this. The art team would create a spec for a feature, detailing the UI as best they could. The engineering team would then build that feature, mimicking the UI as close as they could using the current primitives supported by the system. When the art team would review the final product, they were inevitably outraged – it deviated from the spec in ways they considered major. So there would be a lot of scope negotiation at the very end, when it is most expensive. Sometimes, the art team would win the argument, and the engineers would pull a few all-nighters to make them happy, but feeling betrayed at the new additions to the spec. Sometimes the engineering team would win, and the art team would have to accept (and be held responsible) for a feature that didn’t really work the way they wanted, feeling betrayed at the violation of their agreement.
As an isolated incident, this wouldn’t be a big deal. But scope negotiations between departments are an example of an “iterated prisoner’s dilemma” situation, where the same parties repeatedly negotiate, and rely on their previous experience to inform their choices in the current round. Unfortunately, the equilibrium in this particular setup has one overriding outcome: longer and more detailed specs. Here’s why.
The art team feels burned that they didn’t get what they asked for. Last time, the engineers weaseled out of their commitments by point out areas where the spec didn’t specify what was really important to the artists. So this time, they are going to spell out what’s important in even greater detail, to leave less wiggle room.
The engineering team feels burned too, and feels that they were blamed for deficiencies in the spec as if it was their fault that the technology doesn’t really support what the artists want to do. So they react in two ways. First, they actively encourage a more detailed spec, and are more aggressive about pointing out possible inconsistencies. This forces the art team to make concrete decisions about stuff they don’t really care about. Second, the engineering team starts to pad their estimates, knowing that each feature in the spec is not really done when they think it’s done – there’s going to be inevitable scope creep from the art team when they finally see the final result.
What are the consequences of this more detailed spec? For one, it takes a lot longer to create, meaning that the projects themselves get larger in order to rationalize the increased investment in planning. Second, the extra detail obscures the artists’ original intent in specifying the feature, so the engineers are even more likely to miss the big picture and build the wrong things. And lastly, it removes the engineering team’s ability to find breakthrough solutions that might deliver most of the value at a fraction of the cost. They can’t use any discretion for fear of breaking the spec’s contract, even if the changes would probably go unnoticed or even be in the company’s best interests. The lack of trust (and the procedure of the Waterfall methodology) makes it very difficult to ask for clarification or changes in the spec while the implementation is underway.
This feedback is a nasty trap, and it’s just how this room full of otherwise rational adults wound up in a screaming match about rounded corners. It was painful to watch. Now, part of the reason I remember this particular meeting so well is that I wound up doing something considered really radical at the time. I suggested that we change the underlying architecture of our UI system so that the artists would be able to build their own UI pieces themselves and then integrate them into the product without requiring new code every time. It took an incredible amount of politicking and arm-twisted, but I did eventually get the teams to agree to that solution. I’m proud of that contribution, but the reason I tell that part of the story is not to show off, but rather to be able to tell you what happened next. Although both teams got something valuable about the new system, neither was very happy. I had successfully defused the situation, and by reducing the feedback loop between the artists spec and its implementation, I was able to help them realize their goals better. As a technical fix, it was brilliant. As a solution to the underlying problem, it was useless.
Neither side liked me very much for having "fixed" their problem. In particular, the artists felt like I had created a lot more work for them – they were used to having other people grapple with implementation details for them, and now they had to do it themselves. They either had to hire a developer onto the art team itself (unthinkable) or learn those development skills themselves (which was, to be fair, really hard). The engineering team wasn’t happy either. Creating this new architecture was a fair bit of work, and they couldn’t shake the feeling that I had basically sided with the enemy, giving them tools that would require a lot of engineering support but basically deprive the engineering team of any credit for the resulting features.
I’ve now come to believe that this confrontation was a direct result of the partition between the departments in this company, and that rather than seek technical solutions to the disagreement, I would have been better off working to break down those walls.
Let me tell one more story from that same company. I mentioned before the art path, the set of tools the engineering team was required to build and maintain for the art team to be able to create content. Because the art team was considered an internal customer (and “friendly” to boot), we didn’t waste a lot of time making the tools easy to use. Instead, we spent time making sure the exact behavior of the tools were well documented – by engineers, naturally.
This led to some pretty bizarre situations. One time I remember in particular, an engineer fixed a bug that was causing artists’ creations to render in our 3D environment with a skewed rotation. The details aren’t important, but it turned out that under certain relatively common conditions, the objects would come out completely upside-down.
I’m sure this engineer was expecting to be treated as a hero by the art team, since he had just fixed a major bug. But instead he was reviled. Why? The artists had known about this bug for ages, but had just assumed it was a natural part of the system. They had learned that the best way to solve problems is through trial-and-error, doing whatever it takes to get the object to look right. So sometimes the object would come out upside-down, sometimes not. When it did, they’d just invert their original work so that after the upside-down transformation, it looked right. Sure, there was a lot of randomness in whether they would need to take this extra step, but this was nothing unusual. From their point of view, the tools were full of meaningless jargon and bizarre incantations that resulted in nearly random behavior. This bug was not even considered a major one, since at least it had a deterministic fix.
But now you can see what happened when the bug was fixed. A large, but mostly random, sample of objects started rendering upside-down! This required either that we leave the bug in place, or that the art team go back and rework all those thousands of upside-down objects. Neither solution is particularly alluring.
Again, this led to lots of mutual recriminations. Why didn’t the art team come to the engineers and tell them of this bug as soon as it manifested? Why aren’t they smart enough to figure out what the tools actually do? On the other side, why don’t the engineers just deliver tools that work like they’re supposed to? Other more established companies have tools that are intuitive to use, why can’t we?
The solution to this problem is actually really simple. Just create an art path team, composed of some artists and engineers. Force them to live and work in the same physical space, force the engineers to actually do some art production, and force the artists to actually learn what the technical limits of the tools are. As the team gets traction, simply rotate members from both departments through this team, so that the knowledge they gain is eventually diffused through both organizations. And hold the leaders of that team – artists and engineers alike – accountable for a set of clear goals for the tools that are important to the company.
There’s nothing intrinsically difficult about this problem, just as their was nothing intrinsically difficult with the “rounded corners” problem I discussed earlier. The barrier to doing the right thing is the entrenched ideas originating from departments. Who would lead this team? Who would they report to? How would we ensure that the team was faithful to the best practices of both the art team and the engineering team? And plus, do we really want to be cross-training engineers in art and artists in engineering? Isn’t that a waste of time? After all, both teams are already too busy, how can we afford to pull people off and waste time?
This is another variation of the time/quality/money fallacy – the very quality problems that a team like this would address are currently wasting time and causing the team to be “too busy” to invest in the solution. So: enough with functional departments at startups. Let's start holding people accountable solely for their contribution to the only thing that matters: validated learning about customers.
Wednesday, June 2, 2010
The Five Whys for Startups (for Harvard Business Review)
I continue my series for Harvard Business Review with the Lean Startup technique called Five Whys. Five Whys has its origins in the Toyota Production System. I've written about this before in some detail, but this was an opportunity to try and frame it for a general business audience. After all, Five Whys is the most general, most transferable technique in the toolkit, because it can act as a natural speed regulator for any kind of work. (If you're curious about the theory behind this idea, see Work in small batches.)
You can view previous essays in this series here:
The Five Whys for Start-Ups - The Conversation - Harvard Business ReviewRead the rest of The Five Whys for Start-Ups.
Root cause analysis and preventive maintenance are concepts we expect to see in a factory setting. Start-ups supposedly don't have time for detailed processes and procedures. And yet the key to startup speed is to maintain a disciplined approach to testing and evaluating new products, features, and ideas. As start-ups scale, this agility will be lost unless the founders maintain a consistent investment in that discipline. Techniques from lean manufacturing can be part of a startup's innovation culture.
One such technique is called Five Whys, which has its origins in the Toyota Production System, and posits that behind every supposedly technical problem is actually a human problem. Applied to a start-up, here's how it works....
You can view previous essays in this series here:
Subscribe to:
Posts (Atom)