Intro to Part 1
My name is Joey Gibbs and I work as a Development Manager on the game Research & Development team at Riot Games. Today, I’m here to talk about development strategy. In this two-part article series, you’ll learn how to help your product teams make the most of their time by changing how they define and prioritize their work. Part one will cover goal setting and work definition, or how to set your team’s sights on a problem and start breaking it down. Part two will provide heuristics for work prioritization, helping you chart the most effective course from the start of your project to the finish. While my focus will be on game development teams, the project management strategies we’ll be discussing today are broadly applicable across many different software development contexts.
For now let’s start at the very beginning: Once you’ve decided to build a team around solving a problem or realizing an opportunity for players, how do you get everyone rowing in the same direction?
Vision & Mission
The first step is defining a compelling long-term goal for the team to strive towards. At Riot, that true North comes in the form of the team’s vision and mission statements.
When it comes to team vision and mission statements, I like to use Tesla’s as an example because it’s as bold and clear as any company out there: “To accelerate the advent of sustainable transport by bringing compelling mass market electric cars to the market as soon as possible.” Let’s break that down and look at the pieces.
The vision component describes a valuable future state of the world: in Tesla’s words, “the advent of sustainable transport.” By contrast the mission describes the path Tesla has chosen in order to get there: “by bringing compelling mass market electric cars to market.” This distinction between vision and mission might seem subtle, but it’s important. A different mission that could in theory realize the same vision might be “by bringing compelling mass market electric boats to the market as soon as possible” or maybe “by creating cheap, recyclable batteries for electric consumer vehicles.” Selecting the path that you think is the most likely to yield the realization of the vision is hugely important, but it’s also the subject of a future article =)
So let’s say for now that, like Tesla, your project has a clear articulation of vision and mission. Your team is excited and ready to change the world, or maybe just build that next genre-defining game. Where do you go from there? The next step is breaking that mission down into more manageable component bits and getting to work!
Backlogs
In agile development environments, project managers often use a planning tool called a “backlog” to track all the steps their teams need to take in order to realize the vision. In its simplest form, a backlog is just a special term for a prioritized to-do list. It can be as simple as the five items you need to pick up from the grocery store or as complex as all the hundreds and hundreds of design, artwork, coding, and testing tasks that a hundred-person development team needs to complete in order to ship a game. Whether you’re a solo indie dev or a big AAA studio, the same restrictions apply: You have a lot of stuff to do and a limited amount of time and resources to get it all done. You’re more likely to be successful in your efforts if you take some time to think about what you’re going to do and how you’re going to do it.
Continuing on with our Tesla example, a simple breakdown of the work involved in realizing the vision might look something like this:
Vision: Accelerate the advent of sustainable transport.
Mission: Bring compelling mass-market electric cars to market.
As you can see, changing the world isn’t quite as simple as “just doing it” - each of the items on our faux Tesla backlog took the company years to develop. And they’re not done yet - Tesla’s vision of a world with sustainable transport is far from realized. But by being deliberate about what they do and how they do it, Tesla can increase their chances of being successful. Now let’s talk about how all of this applies at Riot Games.
Product Leadership
At Riot, a team’s backlog is built and curated by a team member designated as the “Product Lead.” The Product Lead’s primary job is to drive conversations between team members and their customers, helping both sides align on the problems the team will set out to solve. Then, once the goals are understood by both parties, the product lead works with their team to brainstorm solutions to those problems. From there they help the team choose a solution that they feel will result in the most value generated for that team’s customers. Finally, they work with the team to chart the most effective path through all of the team’s defined work from start to finish. It’s important to keep in mind that while the Product Lead is ultimately accountable for the state of the backlog, building the backlog and maintaining it is the responsibility of every developer on the team.
Defining Work
Rioters obsess about the player experience and we know that there’s a difference between doing work and creating player value. That is, you could code the smoothest build and deploy pipeline in the games industry but if you’re only shipping updates every few months your time might be better spent on something that creates more value for players. We’ve adopted a conceptual framework to help developers recognize this distinction and keep the players’ needs front and center while planning: output, outcome, and impact.
An output is something that an individual or team builds. It can be code, artwork, a press release… anything really. We distinguish that from an outcome, which is a behavioral change that players exhibit when interacting with an output. An output that drives the desired change in player behavior is said to have impact toward realizing a team’s broader goals. Like, say… making progress towards the team’s overall mission.
As an example, let’s say you’re the product lead on a team called the “Competitive Play” team. Competitive Play has a near-term vision of improving players’ opinions of the competitive experience. You’ll notice that this is a very measureable goal: By leveraging business analytics, the Competitive Play team can define what good looks like via something like average player survey response data. Then, as they release new features and updates, they can compare survey responses before and after in order to tell whether or not the work they’ve done has been successful.
So in order to improve players’ opinions of your game’s competitive experience, the Competitive Play team has decided that their current mission is to improve the quality and availability of the matchmaking service. Because you’ve done the work to rally the team around those high level goals and KPIs, the Competitive Play engineers come forward and recommend creating a load test harness for the matchmaking service. After a quick conversation you add:
- Create a load test for the matchmaking service
…as a product backlog item (PBI) to the Competitive Play team’s backlog. Looks a little bit like an output though, doesn’t it? Recognizing this, you dig in a little deeper, asking them “what’s the problem you’re trying to solve for players?” Your engineers (patiently) explain that in order to ensure that the matchmaking service is available when players need it, the engineers themselves need to know how much load the service can handle in terms of concurrent users and connection requests. Since the overall vision is a world in which players have a better opinion of the competitive experience overall, you might ask the engineers if there’s anything else the team can do to make sure that goal is realized. After another conversation or two, you end up with the following backlog items:
Much better. By asking a simple question and re-framing the problem in the context of the desired impactful outcome, the team has identified a broader of body of work that they’ll need to take on in order to be confident that they’re building the right experience for players. In agile speak, we’ve created a macro user story that is broken down into four discrete tasks that can then be distributed to individual team members for development. You’ll notice that I’ve framed the tasks using both “builder perspective” (from the engineers’ point of view) and “audience perspective” (from the perspective of players) at the same time for additional goal-setting clarity.
As you can imagine, creating output is fairly easy. To some extent, creating outputs that change player behavior is too. The really tricky part is creating outputs that have impact, calling your shots and driving the player behavior that your organization really wants. That’s why creating measureable goals up front is so important: Without clear definitions of done and and KPIs, you can’t really be confident that your teams have solved the problem. Let’s say the Competitive Play team does all the work outlined above to make the matchmaking service more reliable. Has that work changed players’ opinions about the competitive experience as a whole? You won’t really know unless you measure.
Conclusion to Part I
In this article we talked about a few high-level strategies for team alignment and planning:
- Leverage vision and mission to set high-level goals for your team
- Break the mission down into a backlog of smaller to-do items
- Designate a team member as the owner of the backlog (at Riot, typically the “Product Lead”)
- Align all work in support of the team’s vision and mission
- Make sure high-level goals are measureable
- Define product backlog items in terms of outcomes rather than outputs
- As the team delivers, check results against pre-defined KPIs
Alright. We spent some time defining a high-level vision and mission for the project. Then we broke that mission down into outcome-focused list of product backlog items. The team has a goal and it has a to-do list. Now what? Next time let’s dig into deliberately setting the order in which teams take on product backlog items as a way to mitigate risks and increase the project’s chances of success.
