User Cloud Access
Maybe you have read my post from a few weeks ago on a system of record for product management, and agree that not only does product management need one but there are no tools that provide one. What should you do? Can you “cobble together” an interim system of record solution, and should you?
A central system of record for product management provides three main benefits:
- There’s a single source of truth instead of multiple copies of the truth, of which most do not agree
- The information is an enterprise asset by virtue of being centrally accessible
- It reduces duplication of work since people can now find desired information in the repository rather than searching for it, or worse, recreating it.>
Let’s start with the first goal—everything in its place; no duplication. How might we do that for all the artifacts that product managers create, such as interview notes, feature specifications, release descriptions and value propositions? You’ll need a database that supports documents and attachments as this becomes the well-known location for everything that product management produces. It’s very much like a wiki.
What about the other big piece of the system of record—the relationships between these items? For example, which customer needs drove which features. Luckily, a wiki can support this too, via linking.
Here’s my suggestion: a wiki with (initially) four main areas:
- Customers (including themes and other market drivers, if desired)
- Product and release information (schedules, rationale, plus roadmaps)
- Solution information (features, epics—development tasks go elsewhere, in a tool like Jira)
- Marketing information (value proposition, market segments and qualification questions)>
This gives us a well-known place for all the main artifacts we create as product managers. There are details to determine regarding change management, the specific information that goes into each of these sections, and so on, but for now let’s assume we’ve addressed all that.
Now what?
The real benefits arise when link all the pieces of data. For example, let’s work through turning insights from customer interviews into solutions to customer problems. This example is simplified, but illustrative.
- A PM visits a customer and gleans a lot of good information about their workflow, frustrations, problems, the types of errors that occur in their current process, and so on.
- The PM returns from the visit and enters notes from the interview into the wiki, associated with that customer.
- The PM reviews the notes and highlights key snippets of the conversation, such as where frustrations are occurring and so on.
- The snippets are entered into a special area of the wiki (we haven’t defined this precisely yet), where they are linked back to the customer and the specific interview.
- Later, all the PMs get together for their regular “problem-finding” exercise, where they work with all the snippets they have gathered and work with them—using affinity mapping and other techniques—to determine key customer problems that they might be able to solve with their products.
- As the team discovers problems during this process, they create a new page for each problem and link them (via the links in the snippets) to the customers experiencing that problem. If the team simply discovers new evidence about existing problems, they link those new snippets—and the associated customers—to the existing problems.
- This process creates a list of new problems that are urgent and pervasive amongst the customers.
- This list of problems—the new and old—are now ready for market validation to determine if they are indeed urgent and pervasive for the customers, and if the problems are urgent enough that they would buy a solution.
Most of this is the “normal” process for a product management organization. (If you’re not conducting customer interviews and mining the responses for data about problems, you have other issues.) What’s novel about this process is how the activity is supported by a system of record.
Now that you have a system of record like this, you can:
- For each problem, and eventually the solution, you can point to the exact customers who informed you about the problem. One big benefit of this is that when you deliver the solution, you can directly communicate with that customer about how you are solving their specific problem. This is a powerful marketing capability!
- Older snippets, that in the days before the system of record would simply be lost to time, continue to be valuable as sources of intelligence about the market. It might be that two years ago, only one customer had been mature enough to recognize a particular problem, so you didn’t prioritize it highly. However, in the latest rounds of interviews you find that more customers are experiencing it, so it looks more worthwhile to create a solution, and in fact, it might give you a competitive advantage because you have the early signal of its importance.
- A new PM entering the team can immediately see customer problems and their origin (via the snippets), and see what customers are saying.
- As the PM team specifies features (or even new products) to address these problems, the specifications are linked back to the problems and the particular customers, so that the developers can understand why they are building. This is one of the most motivating things you can do for a developer—let him or her understand how their work directly impacts the customer.With a system of record, your team can do things they couldn’t do before. Your customer interview results are evergreen, continuing to provide value over time. Your sales and marketing teams get the benefits of customer-specific references. And your development team is motivated like never before, because they are solving problems for real people whose words they can read.
How have you implemented or used a system of record? Leave a comment and let us know.
