Product Pillars: The What and the Why

"Product pillars" is a concept that I was introduced to years ago by Shannon Loftis, one of the smartest production executives I know. The pillars are a short list of the key requirements of your project. But product pillars are more than that... they are the touchstones you can use to evaluate design decisions throughout production. They are what matters most to your customers and to your business. On one of my most recent mobile game projects, these were our product pillars: 1. Deep strategic gameplay, but easy to learn and play 2. A fireworks show of amazing visuals 3. Incredibly fast, snappy gameplay 4. Under 50 meg initial download size That's fairly straightforward, right? So let's look at how these pillars impacted the production. First pillar: "Deep strategic gameplay, but easy to learn and play". I knew we had great strategic gameplay (courtesy of our superb lead designer G. Kelly Toyama), but I wanted to make sure we were also "easy to learn and play". Early in the project, this meant usability testing to verify that the UI and especially the iconography were as easily understandable, basically the moment I had anything available I could use in testing. Later in the project, this would mean extensive user testing of the tutorial and overall game experience. Second pillar: "A fireworks show of amazing visuals". For me, this meant arguing... and winning the argument... that I needed exceptional artists on the project. That this was an area where we needed to invest time and talent. Third pillar: "Incredibly fast, snappy gameplay". This translated to very fast initial load time, no wait time between scenes, and fast gameplay overall... which can be a real problem for mobile games built with the Unity engine. One particular result of this pillar is that we had to exert "Constant Vigilance!" on our game load times. Fourth pillar: "Under 50 meg initial download size". For iOS mobile games, this means creating a game that can be downloaded via a wireless network on iPhones, which is currently limited to a maximum download size of 50 megs. If players can download your game without WiFi, that can have a huge impact on your total downloads. This concept isn't unique to my projects... it was mentioned by Patrick Wylie, VP of Big Fish, in our presentations earlier this month at the EMP Museum. And other mobile game publishers also believe strongly in it. The entire team kept these four product pillars in mind as we worked on our game. Because the most valuable aspect of product pillars is when a new design or implementation idea and the product pillars intersect. Here's an example... at one point on this project, we talked about adding a whole new section of 3D graphics to the game. The big question was: how would this hold up against the pillars? The answer was that it would really work well under pillar #2 (fantastic visuals), but could pose serious problems for pillars #3 (fast gameplay) and #4 (download size), because additional 3D art could easily substantially increase the initial and scene load times, and also the initial download. So we had to plan accordingly. In designing and implementing this new feature, the team knew they had to work with the goal of succeeding at all of our pillars, not just one pillar at the expense of the other pillars. When I mentioned product pillars at my most recent DigiPen guest lecture (which was really all about Kickstarter, but I managed to digress into product pillars), the students asked some great questions... "How many pillars should you have?" My preference is for four to six. You want a limited set of pillars. If you have too many pillars, it can damage their value. What you're looking for is defining and maintaining a tight focus on your key product requirements. And fewer pillars will also be easier to remember! "How do you limit the total number of product pillars?" Prioritization! For a product pillar, you're really looking for the requirements that matter the most. "Are product pillars going to be common across all games?" Definitely not. While there are pillars that can matter for all games, again, you're looking for the requirements that matter the most =for this specific game=. For example, I'm working now on a new game design, and have already written up a list of product pillars. They are very different from the ones for my previous mobile game... 1. Incredibly fast, snappy gameplay (okay, so that's a repeat, but it's allowed!) 2. "Drop in, drop out" gameplay (players can join or leave at any time) 3. No learning curve (a simple game mechanic the player can learn instantly) 4. Playing a complete game takes 60 seconds or less 5. Big visual rewards when you win! Product pillars are a great method for a team to keep their project on target. Keep your pillars brief and clear, and make sure your team knows them well... and then you'll see how pillars are a terrific way of making sure that you achieve your most essential product requirements! They will help you confront the difficult decisions early in your project, and help you avoid potentially fatal mistakes. In my next post on this topic, I'll talk more about how I defined my pillars for this new game design, and a methodical approach you can use determine the best product pillars for your game.