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.
(Image source: cashtactics.com)
