• Hand picked resources

    Each week get a set of five curated resources that provide a wide variety of perspectives about topics pertinent to product people working inside organizations

  • Product Ownership in the Wild

    An ebook that looks at the different models that organizations use to practice product ownership

  • Learn how to apply key techniques for product people

    Each month be the first to find out about in depth coverage of key techniques for product people

Get weekly hand picked resources for product people

Your data will be handled according to our Privacy Policy.

Sample Issue

Techniques to use in a Discovery Session

Requests to start work on a project that results in an internal product (or updates or replaces an existing one) often comes in the form of a solution. In other words, the request isn’t “we face this problem, can you help us solve it?”

The request comes in the form of “build this thing.”

One of the purposes of discovery sessions is to unpack that ask for a specific solution in order to understand the problem that lays at the root of the request.

Your discovery session should also help you determine if the problem is worth solving, and what constraints you have on the solution. I’ve found it helpful to have a set of discussions with various combinations of key stakeholders in order to get a clear understanding of the problem, assumptions, risks, and constraints.

Here are the techniques I use when starting work on an internal product. They help you walk the delicate balance between understanding the current state and staying focused on solving a problem, not just delivering the requested solution.


Resources

Use the problem statement to identify your desired outcome.

In order to find out the real reason why you’re working on an internal product, do the problem statement exercise with your team. It will ensure you have clarity on your desired outcomes, and it will help your team get a shared understanding of those desired outcomes.

Establish criteria to help you make decisions

As part of your discussion about outcomes, use the result of the problem statement exercise to determine a small number of decision filters. These are questions, usually expressed as “will this help us do x?” you use when you’re discussing possible options to decide which you will do, and which you won’t. If you ever find yourself in a discussion about whether to do something or not you can refer to these decision filters.

Explore the interfaces you currently have and would like to have

Any product that’s worth building most likely interfaces with at least a few other products, and at the very least is used by multiple people or departments in your organization. Use a context diagram to identify potential interactions. You can also use the context diagrams to identify the key stakeholder groups you’ll need to talk to in order to get a better understanding of what information your product needs to provide.

Explore the processes that the product supports

Internal products exist to support one if not more business processes. When you explore those business processes, there’s the way it is supposed to happen, and the way it actually happens. You want to understand the latter because that’s going to clue you in on how the product should actually operate. Using collaborative modeling to create a process model is the best way to get to that understanding.

Play the risk management game

Use the risk management game to identify, categorize, and determine how to address the key risks you face. And make sure you actually use the results of this exercise to guide your prioritization decisions. You’ll be glad you did.

Map out your crappy first draft

Regardless what some overzealous agile coach tells you, DO NOT jump immediately to brainstorming backlog items without first doing the activities mentioned above. Without the understanding those discussions bring, any effort at backlog creation is merely sticky note theater. When you do have the insights from those exercises, you’ll have a good overview of the problem and possible solution so you can start synthesizing what you have learned and think about how you may go about breaking the work up into backlog items. Story mapping can help you plot things out and think about how to group your backlog items in a meaningful way. It will at least help guide the conversation.


Please Share

Thanks again for subscribing to Inside Product.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.

Talk to you next week,

Kent J. McDonald
Founder | KBP.Media