NOTE: The following is a guest post by Kellie Jones. If you want to submit your own guest post, click here for more information.
In the early days of my product management career there was a lot of focus on business requirements and how to correctly write them: ”The system shall do xyz”. Today it’s all about user stories, “As Sally the book shopper; I want to do XYZ so I can ABC”.
Writing clear and actionable requirements in any format is important, but what is most critical is capturing the right requirements. I can write clear actionable requirements all day long, development will build it, testing will test it – but if doesn’t solve the business or customer needs…so what?
I wanted to share some techniques that allow me to get to the right requirements.
Ishikawa Diagrams
No need to bless me, this is also known as a fishbone diagram. I learned about these diagrams from a greenbelt training class, and have leveraged them to determine root causes of problems, which in turn helped me in developing clear and focused product requirements.
Have you ever tried to use call data from customer support to figure out what to build to reduce calls? It’s difficult – for this data to be actionable there would need to be large numbers of call categories. I find it easier to talk to Tier I support to find what’s going on and have used fishbone diagrams to do it.
At the head of the diagram is the effect, it’s what you’re trying to determine the root cause for. The diagram starts with 4-5 major categories that are the major causes of the effect. Participants then identify causes within these major categories (the bones). By starting with these top level categories, the participants view the problems from a broader perspective than just the product. It’s looking at the big “P”: the Product and not simply the product. What I mean by that is it’s not just about the software but all parts of the customer experience that may be causing the problems you’re trying to solve for.
Partially Completed Diagram:
(click to enlarge)
As part of this brainstorming process we continue to drill down – Why? Why? Why? You‘re trying to get to the root cause of each item. As you do that you continue to get more bones on the fish. When using this type of diagram to drive a brainstorming session, you will have a comprehensive list of actionable items and an understanding of each. This is much more fun than combing through spreadsheets for days trying to understand root cause!
Art Class
As Product Managers, we’re always offered solutions and have to drill in to find the true problems. I’ve found it can be easier to do this by having customers sketch out the solution of what they want. It allows you to have discussions with customers about why they added a particular button or made the functionality available from an unexpected area of the product. These discussions allow you to get to the true business need and better articulate requirements. Its also useful to share the pictures with the development team – so they can hear from your customers too.
The customer isn’t designing the user experience, but you’re giving them a tool to communicate to you what they might not be able to in words.
Customer Interviews
Customer interviews and on site visits are key to identify higher level unmet market needs. But to do this, you need to be able to ask the right questions. Even during on site visits, watching the customer utilize the product, I use every opportunity to ask additional questions (while we’re walking to get a coffee or waiting for that report to run). Some of my favorites include:
● What is the worst day you’ve had in recent memory?
● What is the best day?
These questions are not limited to while they were using your product, and may have nothing to do with a product at all. It can give you insight into what success or failure what look likes to them.
● What other software/tools do you use in your job?
This will help identify what they’re doing as part of their job that is outside of your solution. A big a-ha moment can come from this type of question. Their answers may surprise you. One time I found a customer using an HTML editor. They were using this to understand HTML so that they could format correctly in my product.
You also might actually see unexpected tools during an onsite visit, e.g. a ruler or an adding machine. If you see tools like these in use, don’t forget to ask them what they are used for.
Other favorite questions include:
● What is your busiest time of week, month, year? Why?
● What are the top 3 things you spend your time on?
● What do you (or your boss) think should be the top 3 things you spend your time on?
What Else?
As with any meeting, the keys to a successful brainstorming session or customer interview is being prepared and having the right attendees. Have an agenda and walk the participants though the process so that they know what to expect and it will be more successful. Remember to share the results with your development team so that they’re vested in the success of the product. And of course, have fun with it!
There are many different techniques to get input. One good book is Innovation Games
—
Kellie Jones lives in Atlanta where she is a Product Manager at Ultimate Software. She’s managed a variety of solutions ranging from client side small business software, the georgia.gov website and now a SaaS solution for mid – enterprise sized businesses. You can follow her on Twitter (@kelliej) or connect her on LinkedIn (http://www.linkedin.com/in/kelliejones)
Tweet this: Guest Post by @kelliej – Sticky Notes and Fish Bones – Finding and Understanding Core Problems http://wp.me/pXBON-2Zi #prodmgmt #innovation