Product Discovery Done Right

How to balance product discovery and product delivery.

When you’re busy, good product discovery is the first thing to fall by the wayside. You might have heard me say before that a product manager stretched too thin becomes a project manager. That’s not to say project management is any less than product management. Instead, it’s to point out that there’s a balance between Delivery and Discovery.

When responsible for too many projects, the natural response is to reduce the time spent doing Discovery work. In particular, a founder-led startup can easily defer to founder-prescribed solutions and optimize only for efficient Delivery.

The temptation to under-allocate time to Discovery is so strong that it’s the very first step in adequately allocating your time as a Strategic Product Manager.

I recommend that an IC product manager spend half their time on Discovery activities. Spend half of your week on activities like interviews, research, prototyping, and experimentation (both qualitative and quantitative). At the highest level, it’s about spending your time thinking about and deciding what to do — versus actually doing it.

Intercom, a canonical example of a thriving product-led company, has its product managers strive to spend 60% of their time on Discovery, as outlined on the Inside Intercom blog. They target splitting Discovery time equally between prioritizing problems, defining problems, and designing solutions.

Similarly, long-established Product Management thought leader Marty Cagan recommends spending half your time on Discovery in his latest book, Inspired (highly recommended).

Keep in mind that you should be investing your Discovery time wisely. Don’t do Discovery work just for the sake of it or to meet an arbitrary quota.

There are things we don’t know and things we can’t know; de-risk the former and test the second.

In Discovery, we encounter many types of risks. They will fall into two essential categories that decide how we manage them.

When you identify a risk, ask yourself: “can we figure this out in advance?”

If you can, then your Discovery should focus on mitigating that “can know” risk. A well-designed experiment is your best tool for a “can’t know” risk.

For a “can know” risk, your next question is: “Should you figure it out in advance?” While you won’t know precisely how hard it will be to figure out in advance, get a rough sizing and compare it to the risk’s potential negative impact. If the potential fallout from your risk is minor and your effort to mitigate the risk is high, it might not be worth the extra effort. You’ll also want to think about probability. If it’s possible but improbable, you’ll want to weigh your decision accordingly.

Suppose you’ve got a risk that you can’t uncover in advance (often related to user behavior). In that case, you’ll want to ask yourself a similar question — “is it worth validating with an experiment?”.

Your risk experiment will either focus on mitigating and learning or just on learning. A mitigate & learn experiment will reduce the surface area of risk, e.g., rolling out a test feature to 1% of users. A learning-only experiment will focus on gaining insight and will usually be a typical A/B split test.

If your “can’t know” risk has a low impact (or a low impact when weighted by probability), consider not running the experiment or opting for a learning-only experiment.

Making the most of Discovery Time

When it comes to Discovery, the first milestone is undoubtedly making the time to actually do it. From there, you have to ensure you’re not just going through the motions.

When it comes to customer research, ensure you’re going in with a goal in mind and a plan for capturing and disseminating learnings and insights. Decide whether you’re conducting a problem, solution, or usability interview — and structure accordingly. I’d recommend avoiding focus groups as there are several gotchas (especially groupthink) that can leave you with misleading conclusions. After all, facilitating focus groups is a full-time career in and of itself.

I’d recommend a combination of one-on-one interviews, surveys, and quantitative analysis. It’s very common in a startup environment to not have enough data to conduct meaningful quantitative analysis based on customer behavior, product usage, etc. In those cases, just increase your use of other forms of research.

I recommend a two-phased approach to your customer research. First, start with interviews to get a strong insight into the problem or solution space. Generally, 6–8 interviews are sufficient. You’ll know you’ve done enough when you feel like you’re mostly hearing the same things. From there, design a survey that you can distribute more broadly that asks qualitative and quantitative questions. These questions should validate and provide further insight into your conclusions from the interview phase of your research.

One challenge with customer interviews is demonstrating the value and takeaways to stakeholders. I’d suggest two things here. Firstly, record the session and get it transcribed (for searchability). Secondly, ask participants to provide a 1–10 rating as a conclusion to the interview. This is particularly effective for solution interviews since you can also have them evaluate the existing solution.

Action Steps

Start your weekly time allocation by blocking out 2–3 hours a day for Discovery. I’d recommend keeping it as an uninterrupted block so you can focus and reduce your switching costs.

In an ideal world, you’d allocate this at the start or end of the day according to your personal productivity rhythm — assigning your Discovery time to the part of the day where you’re most productive and creative. But, often, that’s a choice between the morning and later afternoon.

In practice, though, when you can make time for Discovery time may be outside your control. For example, I’m more of an early evening person, but being on the East Coast of the US and having many team members on the West Coast, I have to position my Discovery time at the start of my workday.

I suggest having recurring calendar blocks for Discovery that you can rename to specific discovery projects and tasks as part of your personal weekly planning ritual.

Originally published on Bryce York — Startup Product Leader