Let me set the scene. You’ve joined a company that has expressed a desire to move to Agile. Or perhaps, they’ve already started the journey, but aren’t yet at full adoption. You assess the situation and find: the design/UX team is running around like chickens with their heads cut off, developers are releasing code that no one else is aware of, and executives are completely in the dark.
Welcome to Scrummerfall.
Scrummerfall is the unholy love child born of scrum advocates and diehard waterfall fans. As the Product Manager, you are stuck raising said love child. You have to answer to your development team that is anxiously awaiting direction, and executives who are used to fully scoped projects. If you do not give developers direction, they will infer from previous knowledge and develop what they think you need. If you do not get executive buy-in, you risk not having a budget.
I do not envy you, my friend. I have been there and know the path in front of you. I’m sure I don’t need to point out that Scrummerfall is the worst of both Agile and Waterfall worlds. Plus, you’re already painfully aware of the chaos. But let me let you in on a little secret. All that chaos is actually good. The biggest hurdle of getting the company to agree to Agile/Scrum is already cleared. And as the person in the middle of that maelstrom, YOU actually have a large hand in shaping its future. Consider it your dues, paid in advance.
I love figuring out what makes people tick. It’s a beautiful complement to being a Product Manager, and is something I do with every UX exercise I undertake. I like watching people interact with the people and things in their lives and seeing if I can divine why the interaction is pleasing: is it efficient? does it remind them of something pleasant? do they immediately understand what they are supposed to do?
Which is why I love personas so much. If you’ve never used them, personas briefly describe your typical users. They put on paper imagined scenarios between users and your product. You take a few key customer types (say, new customer and existing customer) and give them a backstory. Figure out what makes them tick, what their previous experiences were like, why they like what they like. Then you use this information to infer what they would want from your product. If your target market is the elderly, then frequent references to technology may turn them away from your product, whereas references to common household items, for example, would work well.
Once you have your personas created, print them out and post them prominently. Make sure the group gets to know New User Nancy and Exisitng Customer Edward. Once they feel familiar, you’ll find the team begins to advocate for them. You’ll know you’ve hit the mark when someone says, “…but if we do X, Nancy won’t know how to do Y any longer.”
As for the persona template, there are tons of them out there. I’ve used many, created many, and abandoned more than a few. The one thing I do find helpful across the board is a template with a photo; it helps make the persona more real. As I type, I’m looking at Nicole, Anthony, and Isaac–my current batch of personas–and even though they have photos culled from the web, I feel like I know them. They are the reason I create software.
I have long maintained that the two most powerful words in a Product Manager’s arsenal are “no” and “why” — which also happen to be the two favorite words of most 3-year-olds. Before you dismiss them as overly simplistic, hear me out.
A Product Manager needs to be able to hold the line on strategy. Oftentimes an executive will request an item that wildly diverges from the current path, and he/she wants it immediately. When presented with this scenario, you have three options:
A. Ignore the request. After all, you have a backlog for a reason!
B. Fulfill the request. The exec may be the one signing your checks, and you like money, right?
C. Find a way to incorporate the request with the roadmap. It may take time, but it shows you’re listening.
Both A and C are variations on no. (You could argue that option B is a no for your integrity, but that’s another discussion for another day.) If you went with option C, then give yourself a hand. You have found a way to say no without jeopardizing your integrity or job.
Given the above scenario, you need to determine the reason the exec made the request in the first place. It could be you’re working with someone whose brain works overtime, and is always generating ideas. It could be the result of an article/discussion/brainstorm that sparked a want/need. It makes no difference. Your job is to figure out why this item makes sense. How does it support your strategy? What is the impact on budget? If you do this, will it help or harm you in the marketplace? At their root, they all map back to why.
So go ahead. Embrace your inner 3-year-old and ask “why?” repeatedly. At the end of your whys, feel free to choose your version of no, but be prepared to support your reasons and integrity.