Steve Blank

A founder’s skill is knowing how to recognize new patterns and to pivot on a dime. At times the pattern is noise, and the vision turns out to be a hallucination. Knowing how to sort between vision and  hallucination can avoid chaos inside your startup.

———

Yuri, one of my ex students started a big-data analytics company last year. He turned his PhD thesis into a killer product, got it funded and now was CEO of a company of 30. It was great to watch him embrace the spirit and practice of customer development. He was constantly in front of customers, listening, selling, installing and learning.

And that’s where the problem was.

I got to spend time inside his company while I was using their software to analyze early-stage ventures. What I saw reminded me of some of the best and worst things I did as a founder.

A Pivot a Week
It seemed like once a week Yuri would come back from a customer meeting brimming with new insights. “We’re building the wrong product!” he’d declare. “We got to pivot now.” Tossing their agile development process and at times their entire business model in the air, the company would go into fire-drill mode and engineering would start working on whatever his latest insight was.

Other weeks Yuri would be buffeted by the realities of his burn rate, declining bank account and depressing comments from customers. This time he’d be back in the building declaring “We’re going to be out of business in 3 months if we don’t get our act together.”  I even heard him say to a customer, “If we don’t get your order we’ll just have to close up in 90 days.”

As a consequence everyone was afraid to make a decision because they couldn’t guess what Yuri wanted to do that week. Some of the engineers figuring if the founder was declaring they were toast in 90 days were updating their resumes. The company already was gaining a reputation as one without a coherent strategy.

I cringed when I saw this – it sounded like me early in my career. I would come back from customer visits convinced that what I just learned was the “real” solution to the company’s future and havoc would reign.

Unfortunately for Yuri’s company, while there were three other founders, Yuri was the CEO and none of them had the stature to tell him that his “insights” were damaging his company.

So when we had a few minutes alone I offered Yuri that he was misusing the word “pivot” and confusing it with “whatever I feel like at the moment.” I said, “You got to realize you’re not just a smart engineer anymore; 30 people are dropping everything they’re doing when you make these pronouncements.”

Pivot as an excuse
I wasn’t surprised when he pushed back, “I’m just getting out of the building and listening to customers. All I’m doing is pivoting based on their feedback.”  By now I’ve heard this more times than I liked. “Yuri, one of the things that you make you a great founder is that you have insight others don’t. But like all great founders some of these insights are simply hallucinations. The problem is you and other founders want immediate action every time you have a new idea.”

“That’s a mistake.”

“A pivot is a substantive change to one or more of components to your business model. You’re using “Pivot” as an excuse to skip the hard stuff – keeping focused on your initial vision and business model and integrating what you’ve heard if and only if you think it’s a substantive improvement to your current business model. There is no possible way you can garner enough information to pivot based on one customers feedback or even 20. You need to make sure it’s a better direction than the one you are already heading in.”

Sit on it for awhile
I said, “Sit on your great insights for 72 hours and see if they still seem good after reflection. Better, during that time brainstorm them with someone you trust.  If not your co-founders, someone outside the company.”

I offered that at Epiphany, my partner Ben’s office was the first place I would go when I thought I had new “insights.” And we’d run them to the ground for days before we’d even let anyone else know. Most of the time after a few days of thought, these insights were really not much better than the current course the company was on. Or by then other customers would tell us something quite different. And the rule was we weren’t changing anything about the product architecture until Ben and I agreed. Which required Ben hearing from the same customers I did.

Change Value Proposition Last
Second, that he needed to recognize that changing the value proposition – the features of the products/services he was offering – was a lot more traumatic for a startup than changing other parts of the business model.

He should make sure that there aren’t other parts of the business model (revenue model, pricing, partners, channel, etc.) that couldn’t change before he declares “we’re building the wrong product.”

In searching for product/market fit (the right match between value proposition and customer segment) the product should be the last part you think of changing – not the first – as the cost of upending your product development organization is high.

And to make sure everyone knew what he was doing, he might want to consider letting the entire company know “don’t worry when I’m talking about changing our business model every week – it’s a natural part of searching – only worry if I ask you to change the value proposition every month.”

Find a Brainstorm Buddy
Finally, I suggested that he find someone he respects on his advisory board, who he was comfortable brainstorming with and would tell him when he has a bad idea.

Yuri sat quietly for awhile. I wasn’t sure he had heard a thing I said, until he said “Wait 72 hours? I can do that.  Now can I call you when I have a hot new idea?

Lessons Learned

• Founders are great at seeing things others don’t – at times it’s a vision, most often it’s a hallucination
• Founders want immediate action – often they call it a pivot
• A Pivot should not be an excuse for a lack of a coherent strategy or a lack of impulse control
• Disconnect your insights from your mouth for 72-hours
• If you can unilaterally overrule your co-founders there are no brakes on you
• Your board members are not your brainstorm buddies-find others you trust

Listen to the post here: Download the Podcast here

Filed under: Customer Development | 29 Comments »

Long before there was the Lean Startup, Business Model Canvas or Customer Development there was a guy in Santa Barbara California who had already figured it out.  Frank Robinson of SyncDev has been helping companies figure out their minimum viable product and pivots since 1984, long before I even knew what it meant. They’ve done it for more than 400 companies ranging in size from 200 hundred starts-ups, one of whom was Citrus Systems that became Citrix, to IBM.

Here’s a guest post from Frank.

———-

I want to tell you a story about how a team pivoted and succeeded by synchronizing product and customer development. Though it’s about a large company, it’s applicable to teams in start-ups. It’s vivid with respect to method and outcome.

Massacre at IBM

Intel was angry at their supplier about a third-generation wafer-inspection system. “How dare you,” the fab manager said. “We shut down production to setup your machine.” He blocked new business for two years.

The supplier’s CEO directed his business unit general managers to take a SyncDev workshop. The inspection- system GM decided to use it for his fourth-generation system, an 18-month program.

Though development was already underway, I kicked-off SyncDev in early November. The core team — a cross-functional team who could make all the business and technical decisions within a set envelop ─ consisted of product manager, hardware-engineering manager, software-engineering manager, applications analyst, and software designer. We would travel throughout the US and Asia to test-sell a validation prototype, listening to each customer as a jury listens to each witness.

The first wave of meetings was with five US customers in mid-November. On Monday, in San Jose, near the factory, we met with UltraTech Stepper, a friendly account. We did a quick overview of the product. That earned us the right to ask questions of fact about their department’s mission, goals, operations, volumes, tools, methods, and success metrics. We asked, “Given all that, what problems are you having?” We followed that with an hour-long design review, including disclosure of product limitations. For 30 minutes we did trial closes: Who would use it, how often, how would you justify it, and where does it rank on a list of purchase and to-do priorities.

The customer asked, “Where’s off-line setup?”  The product manager said, “It’s in the release after this.”

That night we flew to Boise. Tuesday, 17 people at Micron asked the same question. We responded the same way.

We took a red-eye to JFK and a commuter to Burlington, VT for a 9:00 AM Wednesday meeting at IBM. At noon the boss said, “You guys have no credibility. We’ve asked for off-line setup for years. No one listened!”

Leaving the parking lot, the engineering managers in the back row of the van argued. The product manager who was driving whispered, “For years that said no one needs off-line setup. Now they’re arguing about how to do it.”

Wednesday night we flew to Orlando for A&T. Thursday, off line set up was not an issue. The same thing happened on Friday in Austin. Off-line set up had disappeared into the team’s rearview mirror.

Thanksgiving had come early that year. We were on the road again by late November to meet IBM in Fishkill, NY. After a 15-minute overview, they asked about off-line set up. After we responded their boss said, “Gentlemen, this meeting is over. We don’t want to hear about your roadmap. Please leave!”

Humiliated and depressed, our ride to the hotel felt more like one in a hearse than a van. The customer’s wants the next day would be no different. The product manager described the metamorphosis:

We gathered that night at the hotel, but we were changed.  Humility had crumbled the walls between marketing and engineering. We had heard the voice of the customer as a team and they were unhappy.  Thank God the whole team was there so we could decide on the spot.

For appetizers we slashed requirements.  For soup we compressed schedule. For the main course we sliced up the configuration into bite-size pieces. For dessert we integrated customers into our testing. For after-dinner drinks we polished the new presentation and said a short prayer.

The next day was sunny. Breakfast was actually jovial. We looked back at yesterday with humor, not to cover our humiliation but because we had pivoted.

The next meetings went far better.  We took wounds, but none like those at Fishkill. We continued with three more meetings. We returned to the factory and presented our new path.

“Are you nuts?” our product board asked. “You can’t change direction midstream!”

Without missing a beat, Engineering quoted the customer. I explained how we’d manage technical risks. We were a team, convinced by a shared experience, that we knew what to do. Better yet, we had switched the burden of proof from us to our skeptics.

In December and January we met with ten customers in Korea, Japan, and China. Changes were minor. Instead of pivoting we built virtual backlog.

In February, we returned to Fishkill. “Congratulations, gentlemen,” IBM said, “We apologize for November. With the train heading our way, we’ll get on now. We’ll take two more old units (multi-million dollar) now and replace all seven with new ones when it ships.”

In 90 days the team pivoted the product, saved a major account, captured a large order, cut schedule from 18 months to nine months, and developed virtual backlog.

Two years after release, product market share was up by 30% to 70%. Twelve of 17 competitors were gone.  The division was the dominant global player.

The team followed these rules:

Cardinal Rules of Synchronous Customer and Product Development

• Meet Customers as a Core, Cross-Functional Team authorized to act within a defined envelop.
• Report to a “Board,” to explain and defend your strategy and business case
• Meet Customers’ Decision Making Teams not just users
• Meet on Site in the customers’ habitat: Home, office, lab, factory, or playground. See what they do. Meet their colleagues, form relationships, help fix stuff now, and return as required
• Test Sell a Validation Prototype: Renderings, specs, and props. Don’t sell a vision! False positives result.
• Ask questions. Take Notes. Ask question of fact, not opinion and shut up. Take notes. Tag data and quotes.
• Disclose Limitations to surface objections. It enhances your credibility, too.
• Conduct Trial closes. There are thirty good ones starting on slide one.
• Meet in Waves to get bonked over the head by patterns, two customers per day, Tuesday to Thursday.
• Find and Fix Bad News. Bad news early is good news, if you find and fix it early.

Listen to the post here: Download the Podcast here

Filed under: Customer Development | 16 Comments »