Yesterday I heard that the head of product I hired didn't last the year. Product innovation was one of the hardest things for me to scale. One of the purposes of this blog is to clarify my mistakes so I can avoid them next time, so I thought I'd tackle this topic. Besides, I just read Eric Ries' "The Lean Startup," which also reminded me of how hard this is, and suggested an answer.
To continue the setup, I met an old friend who just closed his startup. They spent one year, solved many technical hurdles building a cool app, but never got any real market traction. The entrepreneur's decision pleased his VC, as most companies linger for much longer. The developers who built intensely all year, pleased not so much.
To continue the setup, I met an old friend who just closed his startup. They spent one year, solved many technical hurdles building a cool app, but never got any real market traction. The entrepreneur's decision pleased his VC, as most companies linger for much longer. The developers who built intensely all year, pleased not so much.
| And then I had lunch with a WIBO graduate that spent two years building a service that converts your business card collection into electronic contact data magically. She now knows her costs to the penny and has paying customers validating her price. But she doesn't yet know how to sell or market, so she doesn't yet know how to cost-effectively distribute yet. Should she raise capital? The Lean Start-up is one of the hottest business books now. Distinctions like "Minimum Viable Product" are infused in Silicon Valley's air. Ries is a disciple and successful practitioner of Steve Blank's Customer Development philosophy, and I also recommend (as does he) Blank's "The Four Steps to the Epiphany". It reminded me of the path my product organization, and these entrepreneurs, kept wandering from. Here's my summary: |  |
- Model. Your first job as an entrepreneur is to build a business model, not a business. Most people spend way to much on prototypes or technical solutions before validating that they can affordably attract customers.
- Minimum Viable Product. The mission is to get to the model as cheaply and quickly as possible. So get over your perfectionism and ship a "minimally viable product." Then, learn. This approach is fueling a new wave of very scrappy startups. We blew this at M5/SHOR and often took ... years (ahem, cough, cough) to ship stuff. We packed new apps and features with requirements, many related to integrating to other department functions like billing, or around scale & reliability, and then never launched. The Zappos guys had told my team first-hand about how their first orders were fulfilled by running to Nordstrom's! We didn't get it.
- "Get out of the building." Meaning go see customers and listen, listen, listen. Toby Hecht used to talk about designing offers to take into account all the background and historical conversations that are going on in a customer's head, workplace, and culture. You need to ask deep, penetrating questions and don't shy away from "what price would you pay?" And listen, listen, listen. Our attempts to automate this with portals like ideas.salesforce.com never flew - you've got to do this yourself.
- Metrics. Focus on a few key metrics that matter. Ries recounts the Facebook legend: it took less than a month for 3/4 of Harvard students to adopt Facebook, and more than half of the users came back every single day. Most of our product discussions were not even data-driven. Avoid "vanity metrics."
- Validated Learning. Protect the time to iterate until you see real evidence. I remember ShoreTel's product organization going out and talking to customers and coming back with a few quotes about how people liked one idea or another - which was viewed as enough evidence to invest millions. Ooof. We almost never budgeted for second versions of stuff, we were all shagged out by the time we shipped anything. Structural pressures - deadlines, market launches, screaming customers, bosses, Boards, and especially my own promises make this very difficult to do. I feel like every time someone suggested that we needed more data it was easily squashed as an anti-entrepreneurial and bureaucratic request.
For me, it all boils down to STFU and listen. Value learning and reward mistakes. Remove institutional pressures that work against you.
I can't be all negative. M5 did this well in a few areas in particular:
- Positioning. Our biggest insights in developing our phone system came when we remembered that no one wants a phone system. Our customers didn't really even want phones, or phone calls. They want sales, and happy customers. Or more time out of the office. How could M5/ShoreTel take care of these needs? That thinking helped us create unique positioning against these real customer problems, and begin to tailor our product for them. When I was trying to figure out what a Chief Strategy Officer did, Angela Tucci, who held that job for Symantec, said that her entire role turned on the question, "What problems will we solve for customers?" I wrote another blog about this, Holes and Drills.
- Sales. Most Salespeople think they are paid to talk about their products. Good ones have lots of knowledge to share. So they do. STFU! We spent AGES trying to train ourselves to listen to prospects more. Questions are so much more powerful than slides. I recommend Sandler as one of many approaches to training this. By the way, the same thing often happens when a talented guitar or keyboard player rarely jams -- less is so much more! STFU and groove!
- Software Development. Embarrassingly late in my tenure we adopted agile development, which embodies much of what Ries is talking about. Constant short sprints, constant feedback. I highly recommend Agile Product Management with Scrum, a book that unlocked agile for our management team. It describes the difference between a classic product manager and an agile product owner. It is specific and actionable. It clearly explains all the basics of agile. When our team read this, it catalyzed our transformation. We went all the way on a multi-year journey, with the help of Brent Hurley of www.girasolutions.com, who I highly recommend too.
But STFU is hard. Ries' book is the classic offer of Passive information - you will nod in agreement with most of it, then not do it. I was making some calls to find good candidates for the new Brooklyn EO chapter this week and I caught myself spewing. STFU! Listen! I know that the prospects won't remember what I said, and I missed many chances to really dig to see if they were a good fit. And we had a long way to go with Agile -- It was hard to interrupt working developers and make them to listen to input from users. Larry Babbio, who built Verizon Wireless and spent a year on M5's Board, told me the only way he ever got this to work well was to physically sit developers next to their business clients so they had to listen to them all day long. As I said in the opening, I never found a product leader who could really make this happen. But I know the next one will! I've recently had lots of opportunities to practice this approach in conversations with entrepreneurs about their businesses, and I plan to work to get better at it.
To sum up, I'm connecting the #1 sales mistake with the #1 product development mistake with the mistake I saw two entrepreneurs make and the one Eric Ries wrote a book about. Boiled down: STFU and listen harder. And with that, I shall take my own advice, and
RSS Feed