Techno-Ethnography Takes You From Process Design To Product Design And Back Again

I recently spent seven weeks—seven weeks!—on the road, with stops ranging from Phoenix to Nashville to New York City. I conducted team and client meetings by phone and videoconference, relied on DropBox to sync each day’s files from the cloud, and maxed out my cell-phone plan.

You may wonder how an entrepreneurial business executive, whose young company is working to build technology for emergency healthcare and incident response, can afford all that time away. But here’s a better question: How can entrepreneurial executives afford not to devote such time (and more!) to understanding the real-world needs of their clients?

Has the prevalence of electronic communication rendered face-to-face encounters obsolete? On the contrary, the sum total of this road-show’s meetings indicate, if nothing else, that customers notice the difference between a personal “touch” and a “phone-in.”

Key To Success

A physician/director of informatics at an integrated health center in the American South suggested that the tendency of tech companies to develop hardware and software in a “vacuum,” as a cadre of geeks who prefer their own cloistered offices to their clients’ workspaces, is at least partially responsible for the current bubble of “apps,” each more questionable in clinical or practical value than the next. This physician wondered, “How many diabetes ‘apps’ does one industry need?”

How many? A couple at most to keep competition alive and quality where it should be.  But countless books are devoted to the subject of why some products succeed and others fail, and yet there is no magic on the shelves. While it is true that the Internet makes the discovery of compliments and complaints easier than ever before, it can be laborious to tease apart the meaningful reviews from those that are either nit-picky to the point of ridiculousness or else disingenuous. (NPR recently ran a story about the burgeoning paid reviews sub-industry.)

The key to designing a successful product ultimately resides in understanding customers’ problems and what they are willing to do or pay to solve them. Nothing beats the face-to-face interview when it comes to answering these questions. A phone or video conference session will suffice in the absence of an alternative. Progress comes when the partner or client is given an opportunity to vent or rave. The client will notice if you’re nodding for effect or taking notes with the intent to deliver results. (For more, see “What’s All This Customer Satisfaction Stuff, Anyhow?”)  

Once a bridge to trust is built, technology designers and engineers are uniquely capable of acting on what they’ve learned—and that’s a critical missing piece of the puzzle. I’ll never forget the time a potential partner-client, during an initial exploratory conversation, railed against her current software provider, saying, “You know what I hate the most? I tell them I have this or that problem, so they knock on the proverbial glass to tell their team, turn around to me and say, ‘We’re working on it.’ But they never actually fix anything.”

Cooperative Design Improves Implementation

When I worked as an MBA intern in the Executive Office of the President of the United States, in the Office of Management and Budget, I was assigned to the team overseeing the strategic relaunch of USAJOBS.gov—the so-called “face of federal hiring.” When I arrived, the project had been stalled for months if not years, with little headway being made toward the necessary consensus.

Politics aside, the reason for the lack of progress was readily apparent. All the conversations were abstract, theoretical, and procedural. Nothing was actually being built, so there was no “agile” development, no demos or drafts being created, iterated, and implemented.

After about a month on site, when I had had time to learn the many issues that needed to be balanced (e.g., existing contracts, compliance requirements, and so on), I grew frustrated with what seemed not like an inability to act, but rather, an unwillingness to do so. I then took part in a “lively” discussion about the hiring portal’s intended functionality and perceived roadblocks.

I asked for one simple piece of information. “Let’s go around the table, and tell me your favorite Web site.” A number of people said, “Google.” I replied, “Good. Give me 10 minutes.” Using Photoshop, existing USAJOBS logos, and a shell of Google components, I drafted a rapid prototype of what relaunched (to enthusiastic response) on January 23, 2010, as the new and improved USAJOBS.gov.

The startup guru Guy Kawasaki blessed this approach when I asked for advice on marketing a cutting-edge product. Did he think engineering elegance or speed-to-market would be more important to business success? He replied (in an example of the Socratic method that I’ll not soon forget), “Bring it to market as soon as you can. See what happens. What if you build a ‘perfect’ product but \\[it\\] turns out that nobody wants it?”

Good point. When I look at the products that my young company has developed, I see more than a collection of features, functions, and interfaces. Our partners, clients, and prospective clients have left fingerprints everywhere:

• During a trip to El Paso, we learned that, without a digital alternative at the ready, firefighters had been using Sharpie markers to write patient and situational information on their latex gloves. This led to our “quick entry” touchscreen design.
• During a focus group in Pittsburgh, we learned from a medic that although he liked our hardware and interfaces, he was afraid that (because his service area included an urban ghetto) he might be mugged for the equipment. He wanted a way to enter patient data digitally while the computer stayed in the truck. This led to our industry-first speech-to-text functionality.
• During an interview with the top information officer of a Midwestern emergency services agency, we learned that even tech-forward organizations have a hard time teasing data out of their ambulance technology “ecosystems” and integrating it with others in the healthcare continuum. We showed an alternative we had built based on earlier conversations with his peers at other agencies. The CIO responded, “I never would have thought to do it that way. Let’s look into the possibility of a pilot.”

Could these features have been developed from our garage offices? Maybe. But technology built without at least the input, if not the explicit commitment, of a buying customer base is a toy. Interestingly, we’ve found that some technology companies have the opposite problem. They don’t necessarily know when they’ve got a winner on their hands and may pull a product too soon.

Michael Dell, an eminent success by any measure, once told me that his company “can’t go after every niche,” when economies of scale are critical to cost-efficiency and consumer pricing. He’s right, of course.

But I look at it this way. If you aggregate a number of underserved niches, it can equal (or even exceed) the large but obvious channel (but with less competition). And due to their specialized nature, products sold into niche markets can be priced higher than they otherwise might be. You just have to know where painful needs exist—and sometimes that means driving cross-country.