Enabling Product Managers to manage

In my last post, Product Manager, or Product Experience Manager, I described the disparate features and experiences that got broken in SiteZ and made the case that product management team should be responsible for overall product experience. In the final post of this series, I will present my views on how product management team should manage experience so that such issues can be minimized or avoided. Note that I am not talking about creating initial product experience or its next version, which is a topic of itself. I will focus only on managing the product as it goes through incremental changes.

There are 3 questions that must be answered by product management team at all times (and should be asked periodically):

1. Are we seeing all the activities we should be seeing?
2. Are we processing all the activities we see?
3. Are we making good decisions based on our processing outcomes?

Product Experience Contour

To answer first question, it is important to understand the boundaries of the product experience that you wish to provide, what I call Product Experience Contour. If you define this too narrowly, you will miss out on lots of user and system activities that you should pay attention to. If you define it too broadly, you will be inundated with activities that are not useful and you will be stretched thin. There are 3 approaches to draw this contour:

1. Persona-driven: If you have created personas (a realistic and detailed description of a fictitious user who represents a category of target audience for the product), they are good starting point to define these contours. Any activity in your organization that impacts or is impacted by a persona is usually a candidate for being on your radar. For example, if I am a persona for SiteZ (someone interested in learning from experienced people, but not interested in changing jobs), the product management team needs to ensure they are plugged into what the other group is promising and offering me. Note that in this case, I may not be a persona SiteZ cares about, which is a marketing and positioning strategy.
2. Use case driven: If you have created use cases (UML, flowcharts, long documents, whatever) to describe how user roles interact with your system, that also is a good starting point though it may not be comprehensive. You can start by looking at the alternate and adjacent flows the particular user roles can go through on your system and see if those need to be on your radar. Use cases are more constrained because they describe your understanding at the time of product creation, while persona allows for more contemporary interpretation.
3. Data-driven: While this may be hard (depending on how evolved your data analytics team is), this can be a very useful way to draw the contour. If you are able to analyze the data available for your system for past user interactions, you should be able to enumerate user activities (along with frequency of use) that you are interested in. The problem in this approach is that if some flows can’t be completed successfully by the user, or your data capture is not comprehensive, you may not get to know about some flows.

If possible, you should use more than one approaches above to draw the contours. Usually, persona-driven is a great way to draw initial contours, validate it with the data from your analytics, and then use data-driven approach to detect new user activities that might be important to include in the contour. In my case, it is entirely possible that none of my activities were ever tagged as useful activities to track, since these are not primary use cases (except the first one – trying to register to join the chat with the guest).

Information Sources and Management Systems

To answer second question, it is very important to look at 2 aspects:

1. Information Source: As a user interacts with the organization, information is generated at many different places. It is very important for product management to be well-connected to these sources and make sure they are getting the information frequently. A few of the sources are:
   1. Data Analytics: As mentioned above, data analytics is a great source for information and must be harnessed properly.
   2. Direct User connect: There are many ways to connect directly with a sample set of users and keep learning about their experiences from them – product blogs, twitter, facebook and other social media channels are very effective if users can stay engaged.
   3. Be the user: It is surprising to see how little product managers use their own products on a regular basis. While being your own user may not be the greatest way to design a new product, it is a great way to keep tab on how things are going. Depending on the product, product managers can enlist their family and friends to be regular users and give feedback.
   4. Other departments in the org: Many departments interact with the users Product Managers want to know about, so it is very important to have a good flow of information from these departments. Typically, Marketing, Sales, Support, and Training teams can have good information about the user that should be captured.
2. Information Management Systems: How information is captured, stored, and disseminated is very important for effective processing. Most activities can’t be processed in real time. Processing can mean many different things – I mean it in the sense of understanding, clarifying, analyzing, ranking and other handling of data. Product management teams need to procure, and use a management system that serves the purpose, and avoid leaving information in emails, chat boxes, whiteboards, or in their minds.

Good Decision-Making Process

To answer 3rd question, we need to make sure we have a good decision-making process in place which is used all the time. A good decision is a collaborative effort, and it is a process rather than a moment. It requires lots of data (which your information sources and management systems can provide), and it requires following a rational decision-making process. Such a decision-making process has following characteristics:

1. Right stakeholders in the decision-making are identified.
2. Participants are contributors and idea-providers, not spectators.
3. Decision-making criteria (how will different options be ranked and prioritized) is defined before solution options are figured out.
4. Personal responsible for the decision (and its consequences) is clearly identified (and it must be a person, and not a group).
5. Once the decision is made, it is communicated, along with the rationale for making this particular decision.

In this context, since we are talking about incremental changes to product, the decision-making criteria should be known upfront and should be applied consistently. Impact of a change needs to be validated against all the known implications to the personas we care for, and this should be a key data in the decision-making process.

Evangelizing Product Management role

Even when you have great answers to the questions above, it is important to enlist the support of rest of the organization in keeping product experience awesome for the user. To do this, product managers need to be product evangelists who go out and talk about the product and their role as the guardian of product experience, to whoever cares to listen, and whichever platform they find. Once enough people in the organization realize that they should talk to you whenever they think about tinkering with the product experience, you will have created the strongest source of information about user activities and your product will thrive.

One final time, let me go through the list of issues, and show how they could be caught if above is done well:

To be fair to SiteZ, it is hard to do all this because these are elements of organization culture and everything can’t be written down as a process and followed. Also, it is entirely possible, that they are indeed doing all this (though I highly doubt this!) and still I became a victim. Such caveats aside, I think this is a good discussion about product experience and hopefully companies will focus more on product experience than what they do today.

This concludes my series on Product Experience Management. I look forward to your comments and thoughts on the topic.