(2009-06-22) Ries Pivot Vision Change

Eric Ries on the "PivOt" as a model for changing your Shared Vision based on Customer Development FeedBack.

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... 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.

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 Product 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... In a customer problem pivot, we try to solve a different problem for the same customer segment... In a feature pivot, we select out a specific feature from our current product and reorient the whole company around that.