Sep 26 2017

How to Successfully Kick Off Your Product Discovery Process

At MojoTech, we’ve had many internal discussions about the line between project and product management in a client-services product management model. But there is a product practice area that we use for almost all of our clients: Discovery facilitation also known as, how to communicate with people and get what you need from them.

At some point, many product managers even those who align with a single product or feature will be in a position to facilitate a face-to-face Discovery session. There is magic in a well-scoped, well-run Discovery that easily delivers a shared understanding of the task at hand. Here are some guidelines we've found helpful in this process.

Set the stage

Preparation plays an important role in getting the right people to give you the right information and requires careful attention to detail, but can usually be summed up by two major questions:

1) What do you need?

what-do-you-need-300px

Decide what the objective of the Discovery is ahead of time so that when you invite people to your meeting, everyone is on the same page about the meeting’s objective before they attend. This helps other people feel that you value their time and shortens the distance you need to travel toward a shared understanding.

It is also important to know what answers you want to receive by the conclusion of the Discovery. This involves doing your homework, conducting background research, talking one-on-one with people close to the effort any avenues that can provide you with enough information and context to ask smart questions.

Document your questions beforehand. When you know what you need, you can then decide how much time you need and schedule accordingly.

2) Who do you need?

who-do-you-need-300px

Typically, fewer voices in the conversation yield better discussion and better Discovery. Aim for the lowest-level people who can answer your questions effectively so you can spare more in-demand people from yet another time commitment. The exception is the executive stakeholder who is accountable for the effort, who should be available anytime a critical business decision is being made or should send a delegate.

Facilitate the conversation

humans-are-bad-at-multitasking-300px

Humans are bad at multitasking.

Don’t do other things while you try to listen. Try these strategies to reduce the urge to multitask:

  • Re-read the first section of this post. Come prepared.
  • Consider bringing a scribe with you. Ironically, you’ll find that if your sole focus is listening, you'll rely less on those notes anyway.
  • Consider recording your meetings if you do feel you'll need to go back to refer to topics that were discussed. This is an excellent alternative to having a note-taker.
  • Keep the meeting focused and set to a reasonable scope for the amount of time you have. It’s okay to zoom in and out of detail to get a better understanding, but don’t wander. Don’t be afraid to guide the meeting back on track if you need to, with six magical words: “Let’s put a pin in that.”
  • Time-box the topics you prepare beforehand (e.g. spend two minutes discussing the problem statement, spend 10 minutes sketching high-level user personas). Time-boxing is an effective way to keep the meeting focused. Remember to reserve a certain amount of time to revisit “pinned” items at the end of the meeting.

Get on the same wavelength.

get-on-the-same-wavelength-300px

Ask to hear about the stakeholder’s vision and high-level objectives, in their own words. Ask them to visualize where they think the work you are discussing will get them and why that matters. Ask them:

  • What do you want to do? (Not, "What do you want to build?")
  • Why do you want to do this?
  • Who are you doing this for?
  • What need will this satisfy?
  • Why is now the right time?

Practice active listening.

practice-active-listening-300px

This technique not only helps you understand but makes the speaker feel understood.

  • Concentrate on the person speaking and listen to what the person is saying without preparing a response internally.
  • Provide acknowledgments (“I see,” or “Right”), so they know you are still focused on them.
  • Paraphrase what you heard and repeat it in your own words. (“What I am hearing is XYZ…”)
  • Confirm your understanding. (“Is that right?”)
  • Draw a line back to the context of the conversation the stakeholder goals, etc. (“So what that means is that X is a high priority because it will enable you to do Y, right?”)
  • Withhold response until you’re certain you’ve understood.

Discussion should flow naturally, like water.

cloud-native-discussion-600x400

A stream changes direction and pace, flowing around obstructions with ease, but none of its motions are random. Let your discussion be nimble. Address different concerns. Focus on detail or broaden as needed, but only change enough to get a strong enough understanding of the objective to continue moving forward.

If you are listening but don’t feel you have enough information to connect what was said to the larger context, probe for more detail. “Can you tell me more about why that’s important for the product?”

Stop wading through the details when they become impertinent to the high-level goals. You’re not trying to make every product decision you’re just getting enough context to feel empowered to make good decisions later.

Don’t reinvent the wheel

In an initial consultation with any industry, there are typically some standard questions that can help isolate scope and cost. For a house painter, those questions might include ones like, "how many rooms do you have?" or, "Will you be including trim, railings, and doors?" The same goes for digital products there are standard questions to fall back on that go a long way in helping you understand the task at hand.

Stay tuned for my next post where I’ll share a few of the go-to questions that I use to help tease out important aspects of the product we’re building and empower engineers to make more informed estimates around the work.

Shaughnessy Conley Speirs

Share: