This is a story about how a team pivoted and succeeded by synchronizing product and customer development. Though it's about a team in a large company, it's equally applicable to a startup teams.
Editor’s note: The case study below focuses on a team that learned the hard way how to pivot and succeed by synchronizing product development with customer requirements. The author, Frank Robinson, co-founder of Product & Market Development Inc., is an early practitioner of a customer-focused strategy that is being widely adopted to increase the chances of success for U.S. technology startups. Robinson’s article originally appeared in lean startup advocate Steve Blank’s blog.
Intel was angry with a supplier about their third-generation wafer inspection system. “How dare you,” the fab manager said. “We have to 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 manager decided to use it to develop his fourth-generation system, an 18-month program.
Though development was already underway, I kicked-off SyncDev training course in early November. The core group — a cross-functional team that would attend all customer meetings and could make all the business and technical decisions within a set envelop - consisted of product manager, hardware and software engineering managers, applications analyst and a software designer. We would travel throughout the U.S. and Asia to test sell a validation prototype, listening to and facing each customer one by one just as a jury does with each witness.
The first wave of meetings was with five US customers. In San Jose, near the factory, we met with engineers from UltraTech Stepper, a friendly account. We provided a quick product overview, which earned us the right to ask questions about their department’s mission, goals, operations, volumes, tools, methods and success metrics.
“What problems are you having?” we asked. An hour-long design review followed in which product limitations were openly disclosed. For 30 minutes we discussed 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?
At the end, the customer asked, “Where’s off-line setup?” The product manager said, “It’s in the release after this.”
We next flew to Boise, Idaho, where 17 people from Micron asked the same question at the end. The product manager responded with the same answer.
That night we took a red-eye to JFK in New York and hoped on a commuter flight to Burlington, Vt., for a 9 a.m. meeting at IBM. At noon, the boss said, “You guys have no credibility. We’ve asked for off-line setup for years but no one’s listened!”
Leaving the parking lot, the two engineering managers sat in the back row of the van and argued. The product manager who was driving whispered to me, “For years they said no one needs off-line setup. Now they’re arguing about how to do it.”
That night we flew to Orlando to meet with AT&T. For them, off-line set up was not an issue. The same thing happened the next day in Austin.
Off-line set up had disappeared into the team’s rear-view mirror.
In late November we were on the road again, this time to meet with IBM in Fishkill, N.Y. After a 15-minute overview, the IBM guys 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. Worse, we knew we’d hear the same thing the next day. Still, a metamorphosis had begun. The product manager described it this way: