Working through a Product Discovery
is been no means easy.
Teams have to overcome a lot of uncertainty
while staying on top of all the pieces of
evidence they collect along the way.
So how can you bring structure to this chaos?
My name is Tim Herbig and I work
as a product management coach
 of companies all over Europe.
In this video, I will share with you what it takes
to bring structure and clarity to your
next Product Discovery.
Before we get into discussing
how to structure a Product Discovery,
I want to spend a minute on defining
what a Product Discovery actually is.
Some attributes of a Product
Discovery are the same
no matter whether you're a startup or a
corporate or whether you're a B2B or a B2C.
Let's take a look the definition which has worked
well for me over the last couple of years
working with a lot of companies
across the range.
At the very core,
a Product Discovery is an iterative process
which aims to reduce the uncertainty
around a problem space or idea
so a product team can make sure
that they are building the right product
for the right audience.
The most important part you need to pay
 attention to in this definition
is where the Product Discovery is primarily
about reducing uncertainty.
Contrary to the belief in many companies,
 it's not just about finetuning an existing UI
or chasing a predefined idea from the C-level.
Instead, you want to stay focused on the
 problem space of a mission
for as long as possible.
Your goal should be to really
understand the problem space
and to get a sense for whether
that actually exists
and what you can do to overcome it.
So when it's time to structure your
next Product Discovery,
you don't want to start with the specific tactics
you might have want to put into your calender
or the ones of your team members.
Instead, you want to get a sense of the various
levels of Product Discovery activities
and work your way through that.
At the highest level,
 it's about the general product areas
of a Product Discovery.
We're gonna talk about those in
more detail in a second.
After that, it's time to look at
the specific activities
you could work your way through
in other to achieve your goal
of reducing uncertainty
and finding answers along the problem space.
And last but not least,
you can then select tactics from your existing
Product Discovery toolbox
to decide which ones you actually want to
pursue and put in your calendar.
Most teams love to discuss shiny new feature
ideas they have come across
or which have been presented and
shared by their bosses.
What they don't realise though is that this leads
them straight into the solution space.
And while there's always time and space for
discussing the details of specific solutions,
the beginning of a Product Discovery
really is this time and place.
Instead, as I already mentioned, you want
to start with the problem space.
And even more important,
when looking at your total time budget
available to invest in Product Discovery,
you want to make sure that the
majority of your activities
is centered around the problem space
instead of chasing feature solutions.
From high-level perspective,
a Product Discovery is typically set up
around those six areas.
You have alignment, research, ideation,
prototoype creation, validation
and refinement.
The most important thing you need to keep
in mind tho is that even though
those areas and those activities pile up on
each other and are somehow related,
it doesn't necessarily mean that you have to
work your way through them in a linear way.
More importantly,
 you want to think of them when you work
through a Product Discovery mission.
After identifying which of those Product
Discovery activities
might be relevant for your specific mission,
it's time to look at the exact tactics
you want to use
to work your way through the discovery mission.
And this of course somehow involves the idea of
how long should this discovery run?
And while I'm not a big fan of working
with specific deadlines
for product discovery activities,
I believe in the power of time boxing
Product Discovery activities.
Time boxing can act as a very helpful constraint
for the creativity you want to focus on
during the discovery.
As a starting point, let's just set a 6-week
time-box for a Product Discovery
and let's look at how those activities
and specific tactics
might line up during such a fictional schedule.
But why it might make sense to limit your
discovery activities to 6 weeks.
Now, here are a couple of reasons why I believe
this is a very good place to start
your discovery schedule.
First, lots of companies work on
a quarterly basis.
And whether you use OKR for your
goal prioritization process
or some other techniques,
moving through on a quarterly basis
 is very common.
Imagine that you start off your goal setting
process on the 1st of January
even if you have to start it on the right
discovery priority to pursue,
you might need some want time to
actually get going
whick kills a couple of weeks from this
12-week window of your discovery
process during Q1.
Afterall, you're probably doing discovery
for execution in Q2 and Q3
and following in the following quarters.
Meaning, you now only have 11 or 10
weeks left before you arrive
before you should arrive at an ideally validated
solution to pursue in the next quarters.
With those six weeks in mind,
you then arrive at a point just during
the midst of the quarter
where you are much smarter about the potential,
the hurdles and the struggles of
pursuing this problem space
of this discovery mission you're relying on.
This is why 6-weeks is a good starting point
and I'm not saying discovery processes has to
be completed within those 6-weeks,
but I believe they are a great starting point
for team to schedule their specific activities
and to iteratively decide whether it makes
sense to invest more time
in this Product Discovery,
or whether you've actually arrived at a feasible
solution which is worth pursuing.
But of course even 6-weeks is a fairly
short period of time,
I wouldn't recommend scheduling all
the discovery activities
you might have to work through for
those whole 6-weeks.
Because, even though the first couple
of steps might be clear,
it's pretty hard to imagine
what exactly you need to do in the 6 week
of your Product Discovery.
You maybe have to return to
the alignment step
because you realise that you're
pursuing the wrong mission
or you have to work through a lot
 of research sessions
in order to truly uncover customer
problems worth solving.
What you should keep in mind when
scheduling activities though is
dependencies to other teams
and the necessary lead time it might take
to get those things going.
A couple of examples.
When you want to create cross-functional
alignment not just with your team
but also with other businesses units or
maybe even the C-level,
this probably takes some time to get
a meeting into the diaries.
Meaning you want to schedule an alignment
 session where you can work
through a collaborative alignment framework
as quickly as possible
because that shoots off as the starting point
for your discovery efforts.
So, stop with those activities which have the
 longest lead time to actually get going.
Well we just talked about alignment and
delignment meetings,
as one example of that,
 there are a couple of other examples
you want to keep in mind.
Even in the most mature companies,
 you have to deal with a lead time of 1-2 weeks
in order to recruit users for
qualitative interviews on-site.
Meaning, you want to get those research
sessions as quickly scheduled as possible
to avoid having unnecessary lead time
in-between sessions
to test all the iterations.
So as soon as the problem space is
roughly defined and aligned,
reach out to your user-research department
and discuss with them how you can make
a series of interview sessions happen.
After all, you'll probably find use for every
interview session you have scheduled
but you will have a hard time
bridging those unnecessary lead times if you
forgot to schedule a session in advance.
Another example are ideation sessios.
I'm a big fan of running cross-functional ideation
not just within the product team which
owns the discovery space,
but also with other departments which
might have a stake
or at least some helpful advice for this
product you're working on.
Meaning, it also takes some more lead time
to get a session where other parts of
the company can come together
and contribute to the ideation session.
You want to make sure you schedule those
things as early as possible as well.
But make sure you have actional
evidence in place
 in order to frame those ideation sessions.
So don't get ahead of yourself
and schedule ideation session for the
first week of the discovery
because this way you'll transition
straight into the solution space
without maybe even having collected
first pieces of evidence
which make the case for which problem
you're searching solutions for.
While the tactics I just mentioned have a
long lead time no matter
how exactly you're going to setup the
interview session or the ideation,
there are a couple of other tactics
during Product Discovery
whose lead time is significantly impacted
by your choice.
Let's look at another example.
Let's imagine you have found an idea
which is worth validating
and you want to look at the holistic
aspect of not just looking at it
from a qualitative perspective,
but validating it from a quantitative perspective.
Examples for that might be an A/B test
or a fake door test.
Now, the beauty of quantitative experiments is
that you get pretty much scientific answers
whether an idea is worth pursuing or not.
The downside of course is that
this comes at a cost.
You'll just simply need a certain threshold
or amount of traffic in order
to produce significant results.
So, as soon as you realise that you
want to run quantitative results,
revisit your Product Discovery schedule
and try to accomodate how long this
experiment probably needs to run
before you have significant results.
And incorporate that into your decision making
 process and stakeholder update
during the Product Discovery.
Just because you're on a 6-week time box
doesn't mean that you only have to update
and communicate your insights
at the beginning and the very end of
your Product Discovery.
Instead, you want to make sure that there
is a continuous process happening
in terms of updating stakeholders, sharing
your pieces of evidence with
corresponding departments,
and making sure everybody is aligned
with the decisions you want or
need to make along the way.
Only through a continuous decison making
and stakeholder-checking process
you can make sure that the decision of
whether the discovery mission has
successfully being "completed", or
needs to be continued
is made along the way.
You don't just want to stop with the
Product Discovery after 6 weeks
surprising everyone with the fact that
you probably need another quarter
to truly understand this problem
space and develop solutions.
You want to be clear about the insights
and the decisions you want to make
as soon as possible in the continuous spaces.
This is why adding something I'd like
to call discovery checkins
to a discovery schedule is extremely vital.
A discovery checkin is something you
need to accomodate in advance
when putting it into the schedule.
Because most likely,
 this involves some stakeholders in C-level
management to make decisions.
And you probably don't want a part of this to get
So you want to schedule those discovery
checkins probably on a weekly
or at least bi-weekly basis
getting together for 30 minutes simply
sharing the rough outline
and the pieces of evidence you have
collected during the last
Discovery Sprint you work through
and ask the questions you need in order
to make decisions moving forward
incase there is any uncertainty.
Keeping all that in mind
should give you a pretty good starting point for setting up your individual Product Discovery
structure and schedule.
The most important thing for the
schedule to remember is
that you and your stakeholders shouldn't
treat it as a promise plan.
Then neither as a linear instruction of how this
product discovery will exactly play out.
Treat it as what it is,
a prediction for the next couple of steps
you think you have to take
in order to explore the problem space
and the solution space.
When setting up your Product
Discovery schedule,
you want to keep three main things in mind.
First, don't start with the specific tactics.
Instead, make sure that you
plan for enough time
to work through the problem space.
Second, schedule those activities with
the biggest lead time in advance
and try to accomodate which
ones you really need
in order to make progress during
your Product Discovery.
And third, make sure to always communicate
your progress as clear as possible
by making use of Product Discovery checkins
to run update to team members,
stakeholders and management alike.
Here's one thing to keep in mind whenever
you feel uncertain or maybe even afraid
of approaching your next Product Discovery.
Think of something which is
called hindsight bias.
Meaning, looking back,
every set of actions looks
 like a perfectly structured plan.
And this will probably be the
same when you look back
at a Product Discovery you have
concluded or maybe even had to abort
and look back at the schedule
you worked through.
It will never be that clear or structured when
you look at it from the beginning.
Instead, you will see a lot of blank space
which needs to be filled.
And that's okay.
Take your time and trust in the process
in order to approach this discovery
mission step by step
but make use of something like a
discovery schedule
to give yourself and your team members
the confidence you need to move forward.
Cheers.
If you found this video useful,
make sure to leave a comment below
and subscribe to the channel
to not miss out on future videos.
Make sure to tell me about your
Product Discovery experiences
and even share your own discovery
schedules, if you like to.
If you're looking for more actionable content
on how to deal with the challenges of
being a product manager,
make sure to follow me on Social Media
and subscribe to my weekly newsletter.
