It’s baseball season, y’all! And let me tell you, organizing your personas can be as confusing as that legendary Abbot-and-Costello bit about a favorite summer pastime. That’s right, I said “organizing” your personas. Why? Because not all personas carry equal weight in a given effort, as lovely as that thought may sound. As an analyst of the business variety, you are likely some level of a people-pleaser and you naturally want to meet 100% of everyone’s needs. The reality is, you can’t please everyone all the time. Especially when you’re probably talking about a MVP effort. (Bonus points for another sports reference!)
Think about MVP – Minimum Viable Product; that is, the least amount of functionality that can be delivered and still be used for its intended purpose. There are a couple of major questions in that definition that need to be answered, and both involve your personas:
–What is the product’s intended purpose and for whom?
–What is the functionality required and for whom?
That’s where your personas come in. You can (and should) actually isolate MVP using a persona map. And while there are lots and lots of examples of these out there on the interwebs, they can be as simple as Primary, Secondary and Tertiary. Even just Primary and Secondary if you want to really get to MVP.
I like visual representations best, so here’s an example:
With this chart, you can simply take your personas and sort them into their appropriate sections. Before you jump into this exercise, though, it’s important to STOP – COLLABORATE – AND LISTEN (who knew that song would be important in the agile development world): bring the team and agree which personas belong where.
Let’s look at a scenario: A fast-food restaurant is building an application that will allow customers check in at the restaurant when they have arrived to retrieve an order placed online.
You might have the following personas in your library:
- Gene, a retiree who enjoys conversations and a fried fish sandwich on a Friday afternoon
- Taylor, a pharmaceutical sales rep who has little time for lunch, but appreciates a hand-held sandwich in the car between appointments
- Rodney, a high school senior who likes to share fries with his friends after baseball practice
- Tiffany, a heath-and-fitness enthusiast who is always on the lookout for new, fresh, and fast lunch options
Who would you make primary? Well, you’d collaborate with your team first, but I’d bet they’d pick Taylor. She’s someone who doesn’t have time to wait. So the check-in feature should be built primarily with her in mind. Secondarily, the team might pick Rodney who’s probably hungry after a good baseball practice, plus may be part of demographic the company is specifically targeting for their mobile app.
For Gene, a check-in app may not be a priority at all, and Tiffany may not be part of a demographic the company is addressing at this time with this feature – so they may not make the map at all. But let’s not forget that Gene and Tiffany are valuable customers to our company – they are just not the focus for this particular development effort. Spending time on making the check-in feature useful for their purposes may extend timelines and increase costs for not much value in return.
Based on this, you should find that the MVP for the check-in feature of your app meets first Taylor’s needs, then Rodney’s. Deliver on those requirements, and you’ve hit a home run!