Pitfalls of Continuous Product Discovery - Product Thoughts #134

For more hands-on insights on how to set up your own Product Discovery process, make sure to sign up for the launch of my upcoming Product Discovery Online Masterclass.

Treating Product Discovery as an ongoing/continuous/recurring "thing" instead of a one-off effort at the beginning of the year is important to establish the habit of acting customer-centric as a Product Team. However, the act of continuously digging through data for "new" insights, trying to get in touch with users every week and running experiments at a too frequent rate (in relation to your traffic/capacities). Here's a summary of my personal experiences (aka mistakes) and observations of continuous Product Discovery efforts:

First, regular (e.g., weekly) customer interactions are great for shaping the team and company culture of thinking user-first. However, talking to users in a cadence which doesn't match the ambition level of the impact you want and needs to make can lead to iterative and small step thinking. Incremental improvements of a well-established product or feature have their time, but when you want and need to think big(ger), investing time upfront is important. Try to resist the fear of missing out (FOMO) of hearing "new insights" when you leave out one or two opportunities to talk to customers to instead focus on setting the stage.

Second, getting distracted from every new bit of insight can lead to a lack of making decisions and focussing on shipping what has already been validated. Especially in environments where stakeholders have a volatile opinion, it can be distracting to reject new suggestions. I'd argue that if you a) don't have a pressing research question you need to get answered right now or b) don't have the operational capacity to act (concept, validate or build) on new insights within the foreseeable future (4 weeks max.) running user research poses a threat to your execution (mainly if the insight is based on n=1).

Third, discovering without clear guidance. If you're not clear about how discovery efforts fit into the overall strategy of your product or company, you're wasting your time. When you feel like it's time to jump on the next Product Discovery S-curve, rather invest time in clarifying the overall strategic fit of an initiative before stabbing around in the dark.

Fourth, know your capabilities for experimentation. N=1 is rarely a viable foundation for deriving conclusions and making product decisions. It also doesn't make sense to chase quantitative experiments if you don't have the numbers. An a/b test with an audience of 100 will never give you statistically significant results. Don't run past the point at which the most effective validation would mean to build the product/feature. Experimentation is an essential activity in a Product Discovery as it helps you to collect evidence for making decisions. But be honest and transparent with yourself (and the team) about how compelling some insights are. Of course, you can only make decisions based on the evidence you have. But you also have to frame it in a way that everybody *still* stands behind it when having the full context.

Which Product Discovery pitfalls have you experienced or observed?

Have a great week and take care,

Tim

What I've been reading

Product managers should not build the roadmap. The product team should.

Roadmaps are a prioritized to-do list that, when done well, create alignment around what is most important to build. If finding the most impactful items to work on, and getting the team to agree on those things is what’s most important, it follows that the responsibility for building a roadmap lies not on the Product Manager alone, but on the wider product team too.

“Scrum wears us down, we don’t get any respite”

There’s a balance here. A Scrum Team seeks to improve effectiveness. But it should also be an enjoyable working environment. Enjoyable: this single word in the Scrum Guide that makes all the difference. The development process should be enjoyable!

How to Keep Employees Connected to Customers

One of the problems with the traditional, outsourced model is that it’s slow and often time constrained. And it requires funding, procurement, contracting, project management, and a number of other resources. This often makes it a discrete, occasional activity. But when employees at all levels of the company are charged with generating regular insights over time, they can act constantly as sensors and uncover data, findings and insights in a more continuous flow.

Design sprints need iteration

An iteration sprint is a simplified version of the first design sprint week where we take all the feedback and insights from the user tests and make small (or big) changes to the idea. This gives us the time and framework to rework the solution and bring it closer to something that the target user would love to use. The outcomes were overwhelmingly positive—so now, these are a crucial part of our design sprint process.

Coaching – Owner vs. Employee

A strong PM is not just competent in terms of knowledge and skills, she also has an effective product mindset and consistently demonstrates good judgment in her decisions and her interactions. In this article, I’d like to discuss an important mindset for a product manager, which is the difference between thinking like an owner, versus thinking like an employee.

Engineering to Product - Learnings and Observations

This thing applies both to you and your team - it’s ok to be idle. Make sure that team understands that and comfortable with that. If you don’t know what to work on - let the team know. Do not try to keep the team busy. Let people work on whatever they want to work on, take time to learn something new, refactor that annoying piece of tech debt from the past or just rest and re-charge.

Post-mortems: The Secret To Better Performing Products (And Teams)

Marie explains what they are, why you should be doing them, what you can hope to learn and much more. You'll leave this episode (and your first post-mortem) with tangible takeaways you can use to improve your processes. And hey, they're not just for product people. Post-mortems apply to everyone and everything.

Make Great Products by Mastering Conflict and Communication

Start the difficult conversations. Be candid with your stakeholders. Call an early end to meetings when they have already fulfilled their purpose. Cancel meetings altogether when they long since stopped fulfilling any purpose at all.

Product Thoughts is a weekly newsletter/digest I send out to over a thousand leaders in product, UX, and business every week. To learn more about previous editions and sign up for it, go to herbig.co/newsletter.