At the 1996 Microsoft Professional Developer Conference (PDC) I stood up in front of 8,000 customers and announced what I’d been working on for the previous two years: the Distributed Component Object Model (DCOM). On stage, in front of all those people, we wrote and demoed code running on one Windows 95 PC talking over the network to code on other PCs. This was back in the day when being able to write programs that worked across a network was a very fancy idea™. Every attendee at the conference got a CD-ROM with a beta version of DCOM to try once they got home. This was back in the day when the only way to get software on a PC was to insert a little plastic disc into an actual computer that sat on a desk.
A few weeks later, one of those 8,000 customers (yes, only one) called Microsoft Support to point out that the most critical file (ole2.h) required to make DCOM work was missing from the CD-ROM.
You read this right. A team of highly-paid, smart, and passionate engineers spent two years (actually more, because I joined the effort late) pouring our hearts & souls into building this AMAZING TECHNOLOGY and when we literally GAVE IT AWAY to 8,000 developers ONLY ONE noticed it didn’t work AT ALL.
I joined Microsoft right out of college. I was just a kid who wanted to build technologies that lots of people would use. I had no idea what I was doing, so I found people at MS who looked like they knew what they were doing, latched on, and followed their lead. When in Rome, do as the Romans, right?
Before the PDC, six years into my career, I was feeling pretty awesome about inventing this new-fangled technology. After the PDC, when I realized we had built something that NONE of our customers cared about, it was a total punch in the gut. I was devastated.
I vowed then and there to never again build something without starting with the customer. Never again would I start with a technology and THEN look for ways customers might use it. Never again would I “build it, and hope they come.” I finally understood what it meant to be a principled leader; to have a set of rules that dictate how an organization operates. I decided one of MY principles (or tenet; the words are synonyms) would be “always start with the customer, not technology.” 24 years later I’m proud of how I’ve lived that principle.
In 1999 I had my first real chance to lead brand-new product development when I helped found the MS Connected Home Business Unit (CHBU) which ended up building Windows Media Center. I invented my own version of “working backwards” where I asked the team create mockups of the “back of the box” (this was when all products, including software came in cardboard boxes) as a first step in product ideation. We also wrote the review article we’d want our favorite PC Magazine reviewer to write, long before technology was selected. The commercial success of the resulting products proved to me focusing on the customer-centric outcome, before discussing technology (or even business) was right-minded. At Amazon I found everyone, from top to bottom, held this same strong belief and that consistency is a critical success factor for Amazon’s growth and profitability.
We use our own forms of “working backwards” at my current company (SnapAV) and it’s gratifying to see team members embrace them. We are all still learning how to do it effectively, and we’ll all continue to learn and adapt, to make it work for us.
Don’t be shy about commenting on this blog post, if you have questions or ideas on working backwards from the customer.
RSS - Posts
Great story and it resonates with me as I ended up being a “customer” for DCOM (and for Windows Media Center and for Windows Home Server and Windows Phone :-)).
When you talk about Media Center, you cite “the team” as your customer and you got them to mock up the back of the box and write reviews but you don’t mention real end customers – i.e. the people who wanted a smart box to put under their TV.
Were those real end users part of building a product like Media Center?
Mike, thanks for commenting. What I meant is I had “the team” mock up the back of the box/write reviews and use real customer data/anectodes to ensure whatever was written would resonate with customers.
Thanks for the post. I agree that working backwards from the customer is one of the most critical principles in product development, and I too appreciated it being applied at Amazon.
My only question is this.. Back in the day when being able to write programs that worked across a network was a very fancy idea™, did you purposely leave that file off of the CDs, to see whether customers would use it?
There is a quote attributed to Henry Ford that says if he asked his customer what they wanted, they would have said a faster horse. This is probably the opposite of working backwards from the customer.
Do you think Ford’s observation was flawed, or are there some products where the customer doesn’t yet imagine it could exist and they need it?
If the latter, is there alternative ways to work backwards from the customer?
No, I don’t think Ford’s observation is flawed.
There are tons of ways to work backwards from the customer. Often, the way to do it is to define as many details of the customer experience as possible, early. Define those details using a myriad of inputs (customer analytics, customer complaints, customer interviews, support data, intuition, competition, etc…). Ensure all aspects of the customer experience are defined (everything from how the customer might learn about the product to packaging to usage to retirement. Write all of these details down in a form that others can grok. I call this a working backwards artifact; it often takes the form of mock press release.
THEN work backwards from that to determine what to actually build and how to build it.
This is what working backwards means. It does not mean just asking customers what they want and blinding doing just that.
I love the ‘back of the box’ idea, widely applicable to different contexts and simple enough for teams that are not ready to adopt a full PR/FAQ approach.
What would you use as a modern example? A marketing site product page? A review from The Verge?
Thanks for this post! I’m still shocked by your experience with DCOM. We as engineers are so focus on the internals of the little things we are building and sometimes forget the WHY part of the game: WHY we are building this? Is this a real need?