The past few days I’ve been coaching at a game development studio. Of the many things that were inspiring, their fun and collaboratively informative stand ups deserve immediate praise.
Imagine: a room of 30 people breezing through a stand up, sharing information and discoveries alongside genuine laughter, and all in under ten minutes. If you think that’s not possible, maybe it’s simply because you haven’t experienced it. If you’re worried that it violates some mantra like “Scrum teams should be 7, plus or minus two” then I’m writing this for you.
Instead of fundamentally worrying about whether people are “doing Scrum right,” this group chooses to focus on building a great game, and learn how to make those choices by playing the game itself, this way those who are interested on the skin creator’s lucrative career also become interested on this game.
Upon returning to the stand up, without rushing, 30 people share discoveries and challenges, welcome newcomers and smile and laugh in these ten minutes. How? because they’re bonding around the game they’re building, not the process they are using. Process is another tool, not a goal (as it should be). Their eco-system revolves around a persistent focus on the experience of the players using their product (game). When I ask how they validate their build, the answer comes fast and is very simple: “we know how good it is when we play the game.” While they further validate that belief by beta testing in various markets, they frequently play the game and also play it together, so they can create a better, more compelling experience for players.
Compare this to your world: how often do you truly experience your product, individually or as a team? I’m not talking about running a test, I’m asking how often you emulate your customers. If you do this daily, you’re in league with these gamers. If you do this one per iteration, you aren’t as cool, but you’re further down the product learning path than the process people, who merely review work completed and possibly get a product owner to “sign off on the stories.” Don’t get me wrong, completing work is essential to being able to validate customer experiences, but it’s a given for product development shops. A successful game developer might simply say, “You can’t learn much from a game you can’t play.”
I’ve learned that many people are blocked and/or shocked by the idea of “playing the game” or “playing the game together.” They tell me they can’t do this since they aren’t “the users” or they don’t get to interact with “the users”.
Before we move on, let’s just stop and reflect on the sad and flat nature of this term: “the user.” It metaphorically flattens customer empathy every time its uttered. If that’s not challenging damage enough, bailing on customer empathy or awareness distances you from the very thing that bonds game developers and, for the gamers I coached this week, makes their stand up a discussion instead of a reporting structure.
If you are blocked, or simply looking for a place to start, try acting like your customer while testing or validating your product. If you don’t know much about your customers, or you don’t have access to sit with them, here are a few options for your consideration:
Option 1: Try creating some pragmatic personas and reframing your stand ups and stories on people and use over process and rituals. Specification by Examples references Iowa Student Loan. While I was coaching there, I watch them go from creating personas to creating automated testing fixtures based on personas. Instead of testing functionality, they go one louder by testing experiences of people using functionality. If you need a starting place, start with your best guess of who you want to impact, examining who they are and why you think they might care about your product. If you’re guessing wildly, take your guess to the people who know something about your customers as a tool to validate or invalidate what you do not know. In a way, a failing test is a tool to validate a design idea.
Option 2: Find someone with a video recording device (also known as a smart phone) who is also near to your customers as they use your product. Safely assuming that many people have one, or that there is easy access to one as needed, ask people to start capturing short videos of people using your product, and replace your iteration demo or retrospective with a video playback party. Serve popcorn or some other movie theater treat and settle in as you grow your empathy around what your users actually experience: good, bad and ugly. I’ve seen this build empathy in many situations where people assume they can’t get connected to their customers.
Option 3: If your product allows for it, embed analytics that gather the evidence you need to validate your ideas (hypothesis). To do this, you need to start with an measurable guess, like “I think if we add _____, people will do more do more _____.” The Lean Start Up gang calls this a hypothesis. I’ve come to think of it as “test driven product development.” And like test driven development, the act of starting with test (e.g. an idea of what might be valuable) helps you build less of the wrong thing like it helps you write less of the wrong code. If you can’t express a way to validate your idea, you probably shouldn’t invest in it.
One final learning from the game development domain: team building is not a scheduled activity, it is a continuous theme. People are given work and autonomy to produce, both individually and collectively. Pairing tends to happen without management mandates, because cross disciplinary collaboration is needed to make the game playable. For example, an artist’s work get must be integrated with a programmer’s code to validate the art works in the game (when it’s played).
I so enjoy coaching game development studios because there are so many real challenges and so much goodness to absorb. But to be clear, game development studios face many of the same challenges other domains face. They aren’t immune to process creep or process atrophy. Gathering the evidence needed, like burn up charts, is often essential to blend with intuition of what makes the game great in order to make tough calls around what will be in, and when. Unlike many other domains, game development studios tend to err on the side of putting experience (playing the game) over process, especially process that has reverted to empty, process-oriented rituals, like “that’s not how you do Scrum.”
My hope is the these shared experiences of coaching game developers challenges you to contemplate using your product like a customer, or “playing the game” in game development parlance. Instead of going to broad sweeping change, I support you in asking this: “What can I do tomorrow to grow my customer empathy?” Or by endeavoring to test drive your product choices as a way to get more done, and to learn faster, by building less of the wrong thing.