This is a guest post by Christopher Grant, UX & Product Director at King Games.
Christopher has led multidisciplinary product teams for over a decade. Today at King, the makers of Candy Crush, his team is building the network-level experience for hundreds of millions of players using everything from native and web features to social media and push messaging. Previously, he led key strategic projects at innovative startups like Tuenti, Sclipo and Emagister.
Confession: I’m not a “methodology guy” by nature. Maybe it’s the chronic autodidact in me, the one who’s got enough gray in his beard to remember a time before you could get a Masters in UX or people spent their time discussing the V in MVP. Whatever the reason, I’m almost always skeptical of doing anything by the book.
Lately, however, people keep asking me about the “methodology” I use with my teams, the process we use to go all the way from ideation to a prioritized backlog. And, despite my process skepticism, I found myself wondering “do I have a process?”
After lots of soul searching during my long flights up North, it turns out the answer is “yes”: even this old skeptic has a set of steps he likes to use. Sure, the order may vary and, like my personal experience, it’s a strange combination of ideas taken from different sources and woven together over the years, each feature launched adding a stitch. Although I can’t guarantee this process will work for you or your product, I can tell you that it was developed the hard way, through trial and error, and that it works (most of the time) for me.
Step 1: A vision
The road to release begins with a single step and it just happens to be the easiest to take but the hardest to get right: to being your journey you must to have a clear vision for the product (or feature set) you’d like to build. This vision must state:
- Who your product is for
- Which of this user’s problems it will solve
- How it will solve them
Having a single, relatable vision for a product sounds easy but is the bane of many startups. Like good writing, the trick here is to carve away the fat, reduce and edit and boil down until you have a shiny idea that fits into a single, elevator-pitch sized sentence. It must be written in the first person, from the user’s point of view as if it were product’s origin story, the theme for all of the user stories you’ll write later on in the process: 
Nowadays, so many methodologies emphasize experimentation and the need to embrace and deal with the uncertainty when building a product. They are right, you can’t know the appeal of your product until you launch. Usage is the final word, but the existence of a “final word” doesn’t save you from having a “first word”, a vision that will guide your experiments, will be the points you pivot away from and will someday, most likely, be proven wrong. The vision will not only guide your product from here on out, if it’s developed with the product team (PM, tech and design) it will guide your team as well. It will focus their motivation and creativity towards a common goal, unlocking the power of a smart multi-disciplinary team and ensuring that everyone works with the use’rs needs in mind.
Step 2: Break it down
Once you have your vision, you’ll need to break it down. The format you should use depends on the kind of product you plan to build:
- List of sub-problems to solve
- Use cases to support
- Product and user lifecycle
Again, the team is a crucial player in this step for all of the motivational reasons mentioned earlier and because many brains are better than one. Here at King, one of my PMs recently led the team using Indi Young’s Mental Model exercise. It was awesome to see the team engage with each other, all focused on the user’s needs and and tasks. The results were an exhaustive picture of what the user would need and what our team would need to build. This breakdown will reveal feature sets and areas in which to build. It will not, however, give you a list of features or a backlog. We’re simply unpacking all of the meaning from the vision into manageable units the team can work with. 
Step 3: An unprioritized backlog
Your breakdown will most likely lead to multiple focus areas for the team and not all areas have the same level of urgency. You may find it makes sense to leave some aside (customer support for young products is a classic example) in this step with plans to come back to them when the product is more mature. Once you’ve decided on which area(s) are the highest priority, it’s time to create a detailed backlog. Once again, we’re breaking down the deliverable from the previous step into even smaller, more actionable units, in this case feature ideas. And, again, we’re going to involve the entire team (sensing a theme yet). This time, we’re going to use the tried and true brainstorm (insert your favorite format) but with a twist! To avoid wasted brain power, before the meeting Product and Design are going to do the following:
- Perform a competitive benchmark
- Do desk research on available technology, user psychology, legal requirements, …
- Try to compile user data
- Any design insights based on the above
Armed with this info, product and design will present their work to the team before starting the imagination orgy. This prep work will help steer the conversation by avoiding major tangents or dreams of the impossible. The team will focus its creativity and will produce more, better ideas faster. 
Step 4: Grooming
It’s time for Design, Product and at least one person from tech (Lead Developer, Tech Lead, …) to review the list and take a first shot at prioritization. Lots of folks have lots of theories on how to prioritize. Personally, I like approaching it from a multi-disciplinary angle (shock!) by using a prioritization matrix to provide a modicum of objectivity and avoid the sneaky power of persuasion or the bandwagon effect. A simple matrix I’ve used allows each of the disciplines to assign a score of 0-2 per idea based on the following criteria:
- Product
- Utility (how valuable will this be to users, how much will it solve their problems)
- Business value (how much value will this be to the company’s goals)
- Design
- Design complexity (how difficult will it be to design the right experience and interaction without sacrificing simplicity and intuitively)
- Desirability (will it go beyond utility and create a genuine thrill when used)
- Tech
- Tech complexity (how difficult will it be to built the right experience and how long will it take)
Once you have all of individual scores for each idea, add them using this formula: 
Now, you’ll take these ideas and order them by “priority” score, the higher the better. The result should be a first version of your feature backlog, created and owned by the team but prioritized based not only on value for the business and/or user, but based on complexity and cost as well.
Step 5: Product makes the final call
Now that you have your backlog, you’re ready to hand over to your team, get the designers designing and the coders coding, right? Not quite. Yes, you should do a quick reality check with the team to make sure that the scores, especially in terms of complexity make sense in the real world. But then, dear Product Manager, you must make the final call about your team’s backlog. You’ve built it from the top down, you’ve involved your design and dev team every step of the way, but you are still the prioritizer-in-chief. Don’t count on a score to replace your instincts:
- You may want to mix some of the low-cost, low-value items with the higher-cost, strategic work
- Maybe you see a feature that you know would be perfect for one of your developers, the one who loves to tackle new, bleeding-edge tech into the late hours of the night
- Or maybe you know that you need to mix in two tasks to keep your stakeholders happy, even if they aren’t technically the highest priority.
In the end, it’s up to you to use the numbers as a guide but to use the kind of judgement, creativity and common sense that your brain and experience can provide. 
Step 6: You can go your own way
Is this the methodology you should use to create your backlog? Probably not. Could it be the basis for developing your own process, one that takes into account the strengths, weaknesses and idiosyncrasies of your team, your organization, your product and yourself? I hope so. When it comes to something as important as your product and your users, don’t accept off-the-rack solutions, create your own, tailor-made one. Use the same level of creativity and insight you invest in your product to create a system that works for you. Trust me, it’s worth it.
