“How many I/O slots do we need to provide, and for which type of I/O cards?” asked my R&D project manager.
In a previous life, I spent many years as a marketing planner for large computer systems. What this really entails is giving guidance to the R&D, manufacturing, support and other teams about what products to build. I was frequently peppered with questions like, “What databases will the users have?” and “How many concurrent users must we support?” The questions were endless and covered a broad range of issues. Now of course, the R&D folks had every reason to ask me those questions—it was my job to understand how customers used our systems and make sure we designed products that met their needs. But how was I supposed to know that level of detail? And if I answered those questions, why would the engineers believe me?
As it turned out, I could answer those very detailed questions. My secret was Contextual Design—I had met Karen and Hugh and they had coached me and my team for a large project. We had gathered customer data and captured that information in various work models, including an affinity and physical model. So when my engineers came asking questions, I’d say, “let’s look at the data we have and see what it tells us.” Suddenly we were getting answers from our users, not from ‘Marketing’. The engineers loved it. They could get details—and engineers love details. The structured capture of information in different work models provided a language that I used to communicate exactly the level of information different groups in my organization required.
I’ve used numerous marketing processes and many development lifecycles during my career but it wasn’t until I encountered Contextual Design that I fell in love. Yes, I’d call it love because once I learned the process, I’ve stuck with it and used it in some fashion ever since we first met in the mid-1990s. For me that’s a long term relationship—okay, that’s a different blog. Colleagues frequently ask me what it is about CD that hooked me. My answer is simple—the real difference between CD and all other processes I’ve used is the capture of detailed data in work models and how those can be used for communicating to the larger organization. Of course going into the field and gathering appropriate data is important—that’s a no-brainer—but the discipline and structure of having that data captured explicitly in various work models filled a gaping hole I had found with other processes.
The first project I did using Contextual Design provided me with an understanding of how our customers used our large computer systems. I used that data for almost 5 years, answering questions and helping different R&D teams better understand how customers installed, configured and managed their large systems. We found the physical model to be of great use to us because it captured specific information about where these systems were located, in relation to storage, printers and other systems, how they were connected, etc.
We were now able to make informed decisions and choose trade-offs with much more confidence. I was no longer trapped in endless meetings as different people argued for their opinion, based on something they read or heard from a customer. I could now talk with confidence and with the work models we built from user data I was able to easily communicate what I and the team had learned with my executives. We spent much more time discussing how to deliver things rather than debating what to deliver.
An interesting thing happened to me after that. I spent much less time worrying about and investigating what competitors were doing. I didn’t need to. With the customer knowledge I had gained accompanied by the visioning we did, I knew exactly where we could and should go with our product roadmap. If we could execute against that roadmap, we would satisfy our customers and differentiate ourselves significantly. Now I worried about our ability to execute. As long as I could deliver what we knew our customers would need, taking advantage of technology advances and making it all easy for our customers, we’d be golden. My biggest fear was always that a competitor would beat us to market. And unfortunately, that did sometimes happen. I’ll share my thoughts about an organization’s ability to execute another time.