Vision versus Hallucination – Founders and Pivots

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

The Lean LaunchPad Class Online

When Microsoft Threatened to Sue Us Over the Letter “E”

By 1997 E.piphany was a fast growing startup with customers, revenue and something approaching a repeatable business model. Somewhere that year we decided to professionalize our logo (you should have seen the first one.) With a massive leap of creativity we decided that it should it should have our company name and the letter “E” with a swoop over it.

1997 was also that year that Microsoft was in the middle of the browser wars with Netscape. Microsoft had just released Internet Explorer 3 which for the first time was a credible contender.  With the browser came a Microsoft logo.  And with that same massive leap of creativity Microsoft decided that their logo would have their product name and the letter “E’ with a swoop over it.

One of E.piphany’s product innovations was that we used this new fangled invention called the browser and we ran on both Netscape and Microsoft’s. We didn’t think twice about.

That is until the day we got a letter from Microsoft’s legal department claiming similarity and potential confusion between our two logos.

They demanded we change ours.

I wish I still had their letter. I’m sure it was both impressive and amusing.

I had forgotten all about incident this until this week when Doug Camplejohn, E.piphany’s then VP of Marketing somehow had saved what he claims was my response to Microsoft’s legal threat and sent it me.  It read:

Response Letter to Bill Gates

Dear Bill,

We are in receipt of your lawyer’s letter claiming Microsoft’s
ownership of the look and feel of the letter “e”.  While I understand
Microsoft’s proprietary interest in protecting its software, I did not
realize (until the receipt of your ominous legal missive) that one of
the 26 letters in the English language was now the trademarked
property of Microsoft.

Given the name of your company, claiming the letter “e” is an unusual
place to start. I can understand Microsoft wanting exclusive rights to
the letter “M” or “W”, but “e”?  I can even imagine a close family
member starting your alphabet collection by buying you the letters “B”
or “G” as a birthday present.  Even the letters “F” “T” or “C” must be
more appealing right now then starting with “e”.

In fact, considering Microsoft’s financial health and legal prowess
you may want to consider buying a symbol rather than a letter.
Imagine the value of charging royalties on the use of the dollar “$”
sign.

I understand the legal complaint refers to the similarities of our use
of “e” in the Epiphany corporate logo to the “e” in the Internet
Explorer logo.  Given that the name of my company and the name of your
product both start with the same letter, it doesn’t take much
imagination to figure out why we both used the letter in our logos,
but I guess it has escaped your lawyers.

As to confusion between the two products, it is hard for me to
understand why someone would confuse a $250,000 enterprise software
package (with which we require a customer to buy $50,000 of Microsoft
software; NT, SQL Server and IIS), with the free and ever present
Internet Explorer.

Given that Microsoft sets the standard for most things in the computer
industry, I hope we don’t open the mail next week and find Netscape
suing us for using the letter “N”, quickly followed by Sun’s claim on
J”.  Perhaps we can submit all 26 letters to some sort of standards
committee for arbitration.

Come to think of it, starting with “e” is another brilliant Microsoft
strategy.  It is the most common letter in the English language.

Steve Blank

Epilogue
Given later that year Microsoft ended up being a large multi-million dollar E.piphany customer all I can assume is that cooler heads prevailed (more than likely our new CEO,) and this letter was never sent and the threatened lawsuit never materialized.

Ironically, since the turn of the century Microsoft has done great things for entrepreneurs. Their BizSpark and DreamSpark programs have become the best corporate model of how a large company can successfully partner with startups and students worldwide.

But I am glad we helped keep the letter E in the public domain.

At times not losing is as important as winning

At times not losing is as important as winning.

Customer Validation
E.piphany was an 11-month-old startup with 31 people and on fire. We had closed four $100,000 deals for our customer relationship management software.

Joe Dinucci, our VP of Sales, was hot on the trail of our next big order. He had just demo’d our product to his friend, the CFO of Autodesk. After seeing the demo, the CFO walked Joe over to the office of Autodesk’s VP of sales, and said to her, “I think this product might solve your sales reporting problem.”

After a demo she agreed it would.

Joe came back to our company excited. If we won the Autodesk account it could be worth half a million dollars or more.

They Have A Problem and Know It
At the time Autodesk’s sales organization was frustrated with their IT department. It took weeks or months for Sales to get financial, sales results and customer reports from IT. Autodesk’s VP of Sales fit the profile of a earlyvangelist: she understood she had a pressing problem (couldn’t get timely data needed to forecast sales), she was searching for a solution (beating up the Autodesk CIO on a weekly basis to solve her problem), she had a timetable for a solution (now) and her company had committed budget dollars to solve this problem (they spend anything to stop missing forecasts.)

A Match Made in Heaven
For the next several weeks, the entire E.piphany engineering department worked with Autodesk’s sales operation team to build a prototype using real Autodesk data. Joe made a compelling ROI (Return On Investment) presentation to the VP of Sales and the CFO. E.piphany and Autodesk seemed like a match made in heaven and it looked like we had a $500,000 deal that could close in weeks.

Not quite.

The CIO
The CFO casually mentioned that as IT would install and maintain the system, they would have to recommend and sign off on an E.piphany purchase. As the CIO worked for the CFO, Joe paid what he thought was a courtesy call on Autodesk’s CIO.

The CIO didn’t say much in the presentation (warning, warning) and he passed Joe on to his manager of data warehouse development. What Joe didn’t know was that months ago, this IT group has been tasked to solve Sales’ reporting problems and was struggling with the complexity and difficulty of extracting data from SAP.

Joe was aware of the tense history between Autodesk sales and its IT department, but given how happy the VP of Sales was with E.piphany’s prototypes plus Joe’s personal relationship with the CFO, he didn’t see this as a serious obstacle. Joe believed the IT organization had nothing but technical piece parts to compete with E.piphany’s complete solution. Given E.piphany had a vastly superior solution, Joe believed there was no logical way they could recommend to the CIO to deploy anything else but E.piphany.

Wrong.

The IT Revolt
Unbeknownst to Joe a revolt was brewing in Autodesk’s IT organization. “Sales keeps asking for all these reports and now they are telling us what application to buy?  If we deploy E.piphany’s entire solution, we’ll all be out of jobs. But if we recommend software tools from another startup, we could say we’re solving the needs of the Sales VP and still keep our jobs.“

Late in the afternoon, Joe got a call from a friend in Autodesk’s IT department warning that they were give the order to another startup. And the CIO would approve the recommendation and pass this to his boss, the CFO, the next day.

We’re Going to Lose
Joe arrived in my office, his face making it clear he brought bad news. E.piphany was now about to lose a half million-dollar Autodesk sale. Joe looked at his shoes while he muttered his frustrations with internal Autodesk politics.

We had a long discussion about the consequences if we lost. It was one thing for a startup to lose to a large company like Oracle or IBM. But to lose the sale to another startup with an inferior product would have been psychologically devastating to our little startup. E.piphany’s product development team had spent weeks inside the account, and they believed the deal was all but won. The competitor would trumpet the sales win far and wide and use the momentum to get more sales.

We couldn’t afford to lose this sale. What could we do?

The Third Way
It struck me that there might be more than two outcomes.Sales had defined the problem as a win or lose situation. But what if we added a third choice?  What if we formally, publicly and noisily withdrew from the account? The worst case was that we could tell our engineering team that we should have won but the game was rigged. While we certainly wouldn’t win the business, withdrawing would solve the more emotionally explosive issue of losing. (And In the back of my mind, I believed this third way had a chance of giving us the winning hand.)

At first Joe hated the idea. Like every great sales guy, he was eternally optimistic about the outcome. However, I wasn’t in the mood to put the company’s future at risk on the testosterone levels of our sales guy. Withdrawing by claiming that Autodesk’s IT staff had already decided that it was “any solution but ours” was making the best of a deteriorating sales situation.

Joe called his friend the CFO, waiting until after 5pm, when he was sure he wasn’t in his office, and left him a message: “Thanks for introducing us to the VP of Sales and your technical staff. We really appreciate the opportunity to work with you. Unfortunately it looks like this deal isn’t going to happen. You have a bunch of smart guys working for you, but they are determined to make sure that the status quo won’t change. We have limited resources and can’t continue to give demos and hold meetings when the outcome is predetermined. My guess is we’ll be back in six to nine months when the VP of Sales is still unhappy. I’m going to call her and let her know that we can’t put in the system that she wanted, but I thought I’d check-in with you first. Thanks again for the opportunity.”

The “Take Away” Gambit
This is known as the “take-away” gambit. I believed that by pulling the deal away, there was at least a 50% chance the CFO would do what I knew he didn’t want to – go to his CIO and help him make the “right” decision. I understood that a potential downside consequence of this maneuver was an uncooperative IT organization when we tried to install the product, but by then their check would be in the bank, and I had a plan to win them over.

Joe was concerned that we had just lost the account, but he made the call and left the message.

Two hours later Joe got a call back from the CFO who said,, “Wait, wait! Don’t pull out. Why don’t you come up and meet with me tomorrow morning. I’ve chatted with my staff and we’re now ready for a contract proposal.”

Autodesk became our third paying customer. Over the next year they paid us over $1million for our software.

After a full-court charm offensive, the IT person who wanted anyone but us became our biggest advocate. She keynoted our first user conference.

Lessons Learned

  • In complex B-to-B sales, multiple “Yes” votes are required to get an order.
  • A single “No” can kill the deal.
  • Understanding the saboteurs in a complex sale is as important as understanding the recommenders and influencers
  • We needed a selling strategy that took all of this into account.
  • In a startup not losing is sometimes more important than winning.

Listen to the post here: or download the podcast here

Massacre at IBM

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

Follow

Get every new post delivered to your Inbox.

Join 151,772 other followers