Ask your development team to perform the “work” of the system that they are building. If they’re creating a new masking tape for painters, ask them to work with real painters, using the masking tape in the field. If they’re creating a new professional oven, ask them to cook meals with a professional chef—not in a classroom, but in a real restaurant, where they have to experience the actual challenges of creating meals. If they’re building workflow management software for furniture delivery people, have them deliver furniture. They will gain direct knowledge of the problems customers face and empathy for how hard it may be to solve them.

Warning! Play this game with some common sense! This game is not recommended for such things as Formula One race car driving, neurosurgery, or high-explosives research. Click here to understand other characteristics of the game.

Product designers who empathize with their customers create better solutions. For some people, this empathy comes naturally. For others, it is harder. The Apprentice providesmembers of your product team with the opportunity to create the empathy that they need to create innovative products and services. As a bonus, it also provides them with a wealth of concrete, direct experience that they can use during the product development process.

Whereas most of the games can be played in a few hours, this one usually takes longer. Two or three days is common, but don’t be alarmed if this technique takes as long as a week of customer interaction spread out over one to two weeks of calendar time. Part of the reason for this is that you’ll want to leverage the concepts behind Start Your Day and try doing your customer’s job at different times of the day. You’ll also need a little extra time to move behind just the bare basics of a job. It doesn’t take too long to replace the brake pads on a mountain bike. It takes quite a bit longer to replace the brake assembly. It takes even longer to replace the brake assembly on a mountain bike, a street bike, and a racing bike. Let your market experience guide how long you’ll need to be an apprentice to gain an appreciation for the tasks they are trying to accomplish. Use this feedback to help you justify to your superiors the amount of time you’ll need to play the game.

When selecting customers for this game, make certain that you let them know that they will be working with novices, and that these novices will be asking lots of questions about how they do their jobs. Ultimately, if possible, the apprentices will actually be performing their jobs.

Start by confirming that your apprentices are appropriately physically and mentally prepared for the task.

Remind your apprentices to ask lots of questions during the game. It is the best way for them to learn from their experiences.

Encourage your apprentices to maintain a notebook or diary of their experiences. During the game, meet daily for 20 to 30 minutes to review their most important discoveries and capture how their understanding of the product that they need to create is changing based on their experiences. When finished, review each day’s insights and consolidate them into a larger document. Note that you’ll often discard earlier observations in favor of later observations, when your team has a more genuine understanding of the task. Consider inviting your customers to attend these review meetings, so that they can further work with your team to clarify any misconceptions about the job.

As you prepare to process your findings, keep in mind that playing The Apprentice game doesn’t always turn up the need for new features or changes to your product; sometimes you will find your product is just fine the way it is. With that as a preamble, here is a means for processing the results from this game.

Schedule a meeting of everyone who played the game. Ask people who are coming to the meeting to review their experience notebook and bring their most important observations and learnings to the meeting. Then, using a process similar to that described in Me and My Shadow, give each person a stack of 5"38" note cards and ask them to transcribe their observations onto these cards, one per card. When finished, ask them to tape each card to the wall. Review each observation, grouping them into meaningful patterns. Discuss the patterns, capturing any meta-observations (observations about the patterns and/or the observations) as new observations.

After the meeting, do the following:

1. Transcribe all observations into a spreadsheet, with one observation in each row.

2. Assess each observation along the following dimensions:

   • Performance gap—The degree to which the observation indicates a performance gap between desired and actual performance. Large gaps mean large problems.

   • New opportunity—The degree to which the observation indicates a new opportunity for solving a customer problem.

   • Product Is Fine But...—The degree to which the observation indicates a problem in another component of your total solution. Be vigilant for observations that indicate problems with training materials, configuration of the system, and so forth.

   • Solution—It is inevitable that some of the observations will actually be solutions to problems encountered in the team. That's okay, just record them as such.

As dictated by the job you and/or your team is performing.

This game is especially effective when you suspect that the product team doesn’t care enough about the people using the product. To illustrate, many years ago I was asked to lead a group of software developers who were charged with creating a new data entry system. Unfortunately, this particular group of developers exhibited some of the most blatant negative stereotypes we associate with “geeks”—insensitive, surly, and downright rude to the data entry personnel who they felt were “beneath them.” To reset their thinking, I asked them to play this game by performing the jobs of the data entry operators (the developers would probably tell you I forced them to play the game).

During the first few days, the bulk of their complaints were muttered profanities referencing my draconian management practices. After a few more days, the bulk of their complaints were directed toward the genuinely poorly designed existing system. After a few more days, when the bulk of their complaints became grumblings for me to allow them to “fix the terrible problems that aren’t letting those poor data entry operators do a good job,” I knew that they had finally developed some genuine empathy for the customer and were ready to begin working on the new system.

I’ve since learned that great product managers just about always use their products—no matter what industry they work in.

Dogfooding means that a company uses the products it makes. This is a great idea, for a number of reasons (see the entry in Wikipedia for the details). However, The Apprentice is not Dogfooding. One reason is that there are many times when the product team can’t Dogfood, such as when they’re making a component that is a part of another product or creating products for a business or professional context that does not match their own. An even more important reason, and the key point of differentiation between The Apprentice and Dogfooding, is that when you’re Dogfooding you’re doing your job using your product. In The Apprentice, you’re putting yourself into your customers’ environment, doing their job, in their context, with your product and any other related products. The end result is a deeper and more empathetic understanding of the challenges your customer faces and how your product helps—or hinders—their work.