Monday, June 22, 2009

Pivot, don't jump to a new vision

In a lean startup, instead of being organized around traditional functional departments, we use a cross-functional problem team and solution team. Each has its own iterative process: customer development and agile development respectively. And the two teams are joined together into a company-wide feedback loop that allows the whole company to be built to learn. This combination allows startups to increase their odds of success by having more major iterations before they run out of resources. It increases the runway without additional cash.

Increasing iterations is a good thing - unless we're going in a circle. The hardest part of entrepreneurship is to develop the judgment to know when it's time to change direction and when it's time to stay the course. That's why so many lean startup practices are focused on learning to tell the difference between progress and wasted effort. One such practice is to pivot from one vision to the next.

Changing the vision is a hard thing to do, and should not be undertaken lightly. Some startups avoid getting customer feedback for precisely this reason: they are afraid that if early reactions are negative, they'll be "forced" to abandon their vision. That's not the goal of a lean startup. We collect feedback for one reason only: to find out whether our vision is compatible with reality or is a delusion. As Steve writes in the Four Steps to the Epiphany, we always seek to find a market for the product as currently specified, not conduct a focus group to tell us what the spec should be. If and only if we can't find any market for our current vision is it appropriate to change it.

So how do you know it's time to change direction? And how do you pick a new direction? These are challenging questions, among the hardest that an early startup team will have to grapple with. Some startups fail because the founders can't have this conversation - they either blow up when they try, or they fail to change because they are afraid of conflict. Both are lethal outcomes.

I want to introduce the concept of the pivot, the idea that successful startups change directions but stay grounded in what they've learned. They keep one foot in the past and place one foot in a new possible future. Over time, this pivoting may lead them far afield from their original vision, but if you look carefully, you'll be able to detect common threads that link each iteration. By contrast, many unsuccessful startups simply jump outright from one vision to something completely different. These jumps are extremely risky, because they don't leverage the validated learning about customers that came before.

I've spoken in some detail about a specific pivot that we went through at IMVU, when we decided to abandon the instant messaging add-on concept, and switch to a standalone instant messaging network. We went through another pivot when we switched again from instant messaging to social networking. Although I wish I could take credit for these pivots, the reality is that they were not caused by my singular insight or that of my other co-founders. Instead, they were made possible by a process-oriented approach that stimulated our thinking and encouraged us to take prudent risks. More than anything, it forced us to take advantage of necessity, the mother of invention. Here's what it looked like.

IMVU had a roughly two-month-long development cycle. Each cycle was punctuated by a meeting of our Business Advisory Board (BAB). At this meeting, we would present our goals for the cycle, all the raw results we'd managed to collect, and our conclusions about what was next. This created a forum for deep thinking and conflict over the direction of the company - a classic problem team activity. It gave the whole company license to go heads-down building product as fast as possible during the development cycle, acting as a solution team should. We knew we'd have the opportunity to think strategically at least once per cycle, so we could stay focused tactically in the meantime.

When it was time to pivot, there were usually certain signs that we'd look to. The most important one actually came from solution team activities. When your fundamental product hypothesis is wrong, the solution team is going to be chronically frustrated. You can try every kind of experiment, add new features, innovate like crazy, optimize the funnel - and get only modest results. One or two cycles of that kind of frustration and you might be able to blame the solution team for insufficient creativity. But eventually, as the company fails to find traction, you start to ask problem team questions: are we really solving an important problem for customers? Are our early adopters really adopting? And does our product really solve the problem we've promised them?

Ironically, although it's the solution team that is the early-warning system ("canary in the coal mine") for pivots, it's actually hard for the solution team to make the decision to pivot. That's why it's so essential to have a co-equal problem team. The more work you've sunk into a product or vision, the harder it is to let it go. As the CTO/VP Engineering, I was the worst offender. It was incredibly hard for me to throw out working code, especially when it was well-factored, unit tested, and generally brilliant (if I did say so myself). I was stuck between a rock and a hard place. Leading up to a pivot, each cycle, despite our best efforts, the metrics weren't good enough. We didn't believe the problem was that we weren't trying hard enough. But we also didn't want to believe that the work we'd expended so far was a waste. It was painful.

The problem team/solution team combined with the concept of the pivot provides a way out. First of all, remember that each team is cross-functional. That means that I (and other engineers) were able to participate in the problem team discussions. Just wearing a different hat made it easier to consider abandoning our work. Such discussions would have been impossible in our execution-oriented engineering team meetings. Context matters. Providing a full view of all the raw data helped, too. It allowed our advisors to help us see patterns we had missed, zooming out the viewpoint from the trees back to the forest. From that angle, it was easier to accept that our micro problems had macro causes.

The pivot helped even more. The hard part about abandoning work is the feeling of wasted effort, that we'd have been just as well-off if we had spent the past few months on vacation instead of working incredibly hard. By pivoting, we honor all the effort by recognizing that learning would have been impossible without the work of the solution team. And rather than just abandoning all that work, we look for ways to take advantage of it in our new direction.

That's the pattern we see in so many successful startups. They did everything they could to take advantage of what they'd built so far. Most engineers naturally think about repurposing the technology platform, and this is a common pattern. But there are a lot of other possibilities. I'd like to call out three in particular: pivot on customer segment, pivot on customer problem, or pivot on a specific feature.

In a segment pivot, we try to take our existing product and use it to solve a similar problem for a different set of customers. This happens commonly when consumer products get unexpectedly adopted in enterprise, as happened to my friends at PBworks. In those cases, the product may stay mostly the same, but the positioning, marketing, and - most importantly - prioritization of features changes dramatically.

In a customer problem pivot, we try to solve a different problem for the same customer segment. This is an exciting kind of change, usually. When doing intense customer development, the problem team can attain a high level of empathy with potential customers. If the results of that exercise is a realization that customers have a problem that our solution doesn't address, and that problem is more promising - it's time to pivot. Starbucks famously did this pivot when they went from selling coffee beans and espresso makers to brewing drinks in-house. They were still serving high-end coffee afficionados, but in a more convenient form. This paved the way for their crossing-the-chasm type breakthrough with mainstream customers.

In a feature pivot, we select out a specific feature from our current product and reorient the whole company around that. A good example is Paypal realizing that their customers were gravitating to the email-payments part of their original solution, and ignoring the complex PDA-based cryptography solution. In order to do this kind of pivot, you need to pay close attention to what customers are really doing, not what you think they should do. It also requires abandoning the extra features that make it hard for new customers to discover what's really valuable about the new, simplified solution.

Without the tools to pivot well, startups get stuck between two extremes: the living dead, still expending energy but not really making progress, always hoping the next new feature will cause traction to magically materialize, and the compulsive jumper, never picking a single direction long enough to find out if there's anything there. Instead of these dead-ends, use the problem and solution team framework and then: pivot, don't jump.


  1. Well put. At a prior company, we'd arrived at the point where it was obvious we were beating a dead horse, so we went back to the drawing board and came up with 3 options--one close to the idea, one in the space but far afield, and one almost unrelated. We took this to the board, and as we suspected, they picked the one close to the idea we had been working on. And to be fair, we included it because we recognized that we'd gained a lot of expertise in the area from our earlier efforts. In the end, that didn't work out either. We're all curious if we'd have succeeded with the jump. The trouble is that you always wonder about the things you didn't do...

  2. Your writing is certainly not lean. I am having hard time understanding.

  3. @Anonymous - what would you like to know?

  4. thanks for the post, i just discovered this blog recently from one of Steven Blank's post. As an engineer thinking of doing a startup applying Steven's approach, your teachings are pure gold!

  5. Eric this is a great validation post for us!
    Our challenge is in the customer retention, and we're in the process of doing segment pivot to validate our hypothesis that the other market segment has longer retention.

    My question to you:
    1. What exactly does the problem team do? what are their deliverables and matrix?
    2. What exactly does the solution team do? what are their deliverables and matrix?

    Can you please elaborate?

  6. I get it. Evolution wins over revolution.

  7. Thank you for your nice posting. I am very happy while reading your blog.

  8. I like this term. Pivotal Labs doesn't carry "Pivot" in its name by accident.

  9. great metaphor. the pivot put me in mind of "the Rhythm of Business" (Jeff Shuman), who uses the dance step metaphor, and describes a very similar process about how companies shift their vision in accordance with reality.

  10. Very good post and well put. A pivot is a classic strategy maneuver for entrepreneurs, chess players, and ballerinas alike!

  11. English is my second language and I though is Pivot is something you would keep constant so that things around that can change.. Therefore, I had a hard time understanding what you say with segment pivot. As you change the customers, you may be changing segment as well. Why don't you call this product pivot. You basically are looking to solve a same or similar problem in other segments/domains.

    In customer pivot, I get it. you keep the customer same but change the problem you are solving. You again center the new solution around where your knowledge is (i.e. in Starbucks example, the knowledge of Coffe)

    In feature pivot, this is a mix of customer/segment. You keep the customer same, even the problem same but you change the way you solve it.

    Anyway, food for thought.. Perhaps I am missing something completely..

    Cheers, Batu

  12. Great post Eric. Just bumped into it through Lincoln Murphy's post. Excellent analysis of "evolution vs. re-volution" and differentiation of team roles. Thank you so much for this insight.

  13. I'm glad there's a 'name' for this part of the process Eric. I think i must have read this article a few times since you first posted it - mainly as a theoretical excercise.

    But now we're practicising the theory and we're experencing some positive rewards along with it.

  14. This is an old post from 2009. Why do you promote it in twitter? Because you are pushing your damn conference all the time. I am so sick of your tweets it's advertising 24/7.

  15. Thanks, Old post, but essential to newbie like me. There's nothing wrong with promoting post like this, which explains insight of #leanstartup topic. Don't take anything that annoy-nymous said.