By Ellen Gottesdiener
Guest Blog by John Zilch
[This blog first appeared on the Boston Product Management Association “ProductHub” blog. Thanks to John and BPMA for allowing us to post it here!]
Upon embarking on my first stint as a product manager, I happened to run into an experienced product executive one day in passing. I asked him for advice and he obliged. He replied rather succinctly: “Ask questions, and then go add value.” He was never one to ramble on.
Since then, I’ve taken his advice to heart, asking questions early and often. Now, a few years into my career in the product field, I find myself going a level deeper and asking a new question: Am I asking the right questions to all the right people?
I recently had the pleasure of speaking with Ellen Gottesdiener who specializes in the discipline of discovering product value through collaboration (among many other topics). Ellen is an Agile Product Coach and President of EBG Consulting focused on achieving product agility through the convergence of product management, agile/lean principles, and organizational learning. We spoke at length about how to question stakeholders as a key competency in building better products for more satisfied customers. Her perspective was enlightening to say the least.
Who are the stakeholders we should be questioning?
At a high level, Ellen points out that stakeholders – who she refers to as “product partners”- can be categorized into three groups: customer, business and technology. “A customer is most likely looking to solve a particular problem or leverage an opportunity that could be provided by the product. A business partner might be more focused on the market, revenue, or competitive position. Finally, technology partners are usually invested in building around quality, performance or scalability and similar quality attributes.”
This one hit close to home because it’s why I initially got into product management. Product managers can serve as the intersection between the three groups, representing all constituencies equally, or at least without bias. It’s a unique position that not only helps derive product value but helps bridge what could be disparate and siloed business functions. Ellen also points out that “these three groups, at some point, should be in the same room.” Product can assist in ushering these meetings as collaborative, productive sessions.
What process should I follow to know I am asking the right questions?
Once Ellen and I had determined “who” to ask questions to, we focused on the “how”. Ellen suggests the “7 Product Dimensions” framework, which covers seven product aspects that encompass functional and nonfunctional dimensions of any product. They help you generate options and then make value-based decisions on the best options. We talked about the definition of “value” relative to these stakeholder groups. Ellen was quick to point out that “value does not always mean just revenue” despite what could be an inclination to do so. “Value means different things to different stakeholders.” The key is to ask questions that expose what’s valuable to each stakeholder group for each of the seven product dimensions. The 7 dimensions are meant to cover product features holistically and all corners of the value proposition of a new or existing feature. Armed with this framework, product management can assess the worth of the options, and also collaboratively explore and communicate value across teams. The seven dimensions are User, Action, Interface, Data, Control, Environment and Quality Attribute.
Let’s put the framework into place. To use a simple example, let’s pretend we are considering adding a live chat support feature to our web-based product.
Here is a sample guide for the types of questions each product partner might ask, considering the 7 product dimensions:
| Customer | Business | Technology | |
|---|---|---|---|
| User | What types of users might access this chat feature? | How does this chat feature distinguish us from the competition in the mind of the user? | Who are the roles that interact with the chat feature? |
| Interface | What will the interface look like? Are there interfaces to external data files needed? | How important is the user interface design to the success of this chat feature? To be competitive, do we need to interface with any external databases or systems? | What design will satisfy the user experience? What APIs do we need for the actions to communicate with business systems? |
| Action | What type of actions will users take when using this chat feature? | How can these actions push customers to a cart or purchase? | Does the team have the skills and knowledge to implement the chat feature? |
| Data | What data is needed to support those user actions? | What data is most useful for business analysis of the value of this chat feature? | Where do we store the data, protect the data, and expose the data? |
| Control | Are there any constraints on what user can or cannot do in the chat feature or on data they can access? Are there any rules about what data we can store? | Are there any regulations or internal policies that we need to conform to for this chat feature? | How do we ensure that the chat interface is secure? |
| Environment | Will it work on a desktop app or mobile as well? If on a mobile device, which ones? | What are device platforms should we support for the best ROI? Can we quickly move from one chat center to another to reduce costs? | What software and hardware platforms will be use? What application development experience do we need to support all the requested platforms? |
| Quality Attribute | What are customer’s expectations around response time and usability? | How much infrastructure can we afford and how will it translate to response time? | Can the chat quickly scale to meet peak times and still maintain a reasonable response time? How can we ensure the chat is fast enough? |
Each question you ask will continue to uncover options what each group finds most valuable to help refine what an agile team will actually deliver. The last step in the process? “Getting this valuable information out of the product manager’s head and understood by the Scrum team,” says Ellen. “This approach is a great way for product managers to serve as product leaders for the team.”
Want additional practice putting this framework into action? Join us for a Boston Product Management Association event on April 20th in which Ellen will lead us through a “Discovery Dojo” session. Check it out here!
John Zilch is Director of Product Management at Dun & Bradstreet, building data management products for sales and marketing professionals. Throughout his career, John has built world-class software products for world-class companies such as Intuit, Pegasystems and now Dun & Bradstreet. Follow John on Twitter at @JohnZilch and LinkedIn at www.linkedin.com/in/johnzilch. Also, check out his personal blog at www.growthandgrit.com.
