5 blockers to effective product discovery and how to solve them
My first deep dive into the topic of Product Discovery happened in September 2019 when I, along with some colleagues, did the Certified [Smart] Scrum Product Owner certification administered by Jeff Patton and Jeff Gothelf.
This workshop’s focus was not on delivery (building the product right). Still, more on discovery (building the right product) and rightfully so as the Agile framework has a ton of literature on delivery. In my opinion, if you have worked in a Product Owner/Product Manager role for at least two years, you are already well versed in product delivery using Agile frameworks. What’s not readily available is any framework to couple discovery with your delivery work. This situation is changing now since the publishing of the book INSPIRED by Marty Cagan. More and more organizations have now started taking this seriously, and you will find ample literature on the principles of product discovery. Just like Agile values and principles, talking about something and implementing it in your day to day work are entirely different ball games.
I am by no means an expert in product discovery. This article focuses on the problems I faced while implementing a discovery process in my team and the workarounds I have implemented. Hopefully, they can help you as well:
1. Getting your Leadership team involved:
Like most things in life, the biggest hurdle you would face in setting up a product discovery process in your organization would be getting people on board. It’s natural for people to think in terms of solutions rather than problems, and spending any more effort in validating the solution that’s already been thought of is perceived as wasted effort.
Most of the “Product Manager Survival Guide” books would tell you that the most important skill you can have as a product manager is being comfortable with saying no, and probably more than one tech recruiter has tried to wiggle this response out of you during the stakeholder management question in a screening call. As important as this skill is, I can assure you that in real-life settings, just saying no to a stakeholder without any context attached to it does not work.
Solution:
What has worked for me is following the approach that Marty Cagan outlined in his book and looking at the product discovery as a compromise; you tell your stakeholders that you appreciate their ideas and request some time to validate them. To further sell this, you can also tell them that they do not need to prepare a hefty business case for their ideas anymore (in all my years of working, I haven’t met a single person who enjoys creating business cases).
I have been very fortunate to be working with a very supportive leadership team in my current role at FlixBus and faced no issues in getting the stakeholders on board.
2. Inability to differentiate between an idea and an opportunity:
I read somewhere that “your best idea may not be your best opportunity,” which I believe is where the product discovery process fails for most organizations. Half of your ideas are not going to work, and you have limited time and capacity to validate all of them. Just like your product backlog, your opportunity backlog can get full fast and overwhelm you. It’s straightforward to see product discovery as useless if it takes forever for your idea to go through the discovery process.
Solution:
Communicate and prioritize! Your business has specific goals, and those probably played a vital role in you defining the product vision and strategy. The product managers need to educate the business stakeholders that any opportunity should contribute to the business goals and, consequently, the product strategy for that particular year/quarter. From my experience, asking the stakeholders to bring the following information for any contribution helps to differentiate an opportunity from an idea;
a. What business objective are we addressing?
b. How will we know if we have succeeded?
c. What problem will this solve for our customers?
d. What type of customer are we focused on?
3. Not choosing the correct format for discovery work
Current literature on product discovery outlines two popular formats;
- Time boxed — for entirely new product ideas
- Continuous — for new features for an existing product.
The problem is that if you are too fixated on following a specific format, the first time your developers will learn about an opportunity would be in a refinement session, which is already too late. In reality, you would end up with a hybrid of both formats, and that’s okay.
Solution:
What has worked out for my stakeholders, and I is a bi-weekly “Opportunity Discovery Workshop.” This session is focused on discussing and prioritizing the opportunities and then time-boxing two weeks to validate the opportunity. Having this workshop six times per quarter gives us enough time to validate opportunities before putting them on the roadmap. We use a straightforward Kanban board to visualize these opportunities and track the progress.
The opportunities, once validated, can then be groomed and broken down into epics and user stories. The best approach here is to keep the process as simple as possible and not invent new ceremonies. If you work in a scrum framework, this can be as simple as taking an additional 5 mins in your daily stand-up to talk about discovery work and announcing upcoming discovery work during your sprint planning and blocking capacity for it. Similarly, you should celebrate the success and failures of discovery work in your sprint review, just like you would for regular work.
4. Not (smartly) involving your developers in the discovery work
The developers need to be involved in the product discovery process from the start. Easier said than done for two main reasons;
- If you have a typical team of 5 developers, involving everyone in discovery would be inefficient and expensive. Plus, we should understand that people have different preferences, and not everyone developer would be interested in participating in user interviews.
- Tech accounting in your company might not be fully on board with the idea. Understand that there is a pretty high cost attributed to each sprint and your technical controller probably keeps track of this for the yearly audit using your sprint velocity. Having developers “working” on something and not being transparent about it in a sprint would cause issues down the line.
Solution:
The lead engineer can be a proxy for the team in the discovery phase, or the interested engineers can participate in the discovery phase on a rotational basis.
To make discovery work visible and keep accounting happy, I would treat discovery work just like a “technical spike.” There is something unknown, and we are time-boxing the effort actually to figure it out. These discovery spikes can be part of your Epics and should be visible on a regular JIRA board.
5. Skipping product discovery for B2B products
There is a common misconception among the Product community that B2B products do not require extensive discovery. Your responsible tech team’s staffing might also reflect this by not having dedicated product designers and researchers. Interestingly, a recent report shows that the majority (77%) of B2C product managers rely on product use recording sessions to collect user feedback whereas, more than 50% of B2B product managers report using some tool for collecting direct user feedback.
From my experience, B2B product discovery is deemed difficult for two primary reasons;
- It’s challenging to recruit users for B2B product discovery (language barrier, tech-savviness)
2. Establishing a direct interface with the customers is difficult as they usually interact with your account managers rather than your research team.
Solution:
What has worked for me, in this case, is asking the business development/customer success team for help in recruiting a group of diverse super users. The customer success team introduces the discovery team to the customer, and then the discovery team takes over.
There might be cases where a direct interface with the customers might not be possible owing to a language barrier. Here, your customer success team can play an active part in the discovery process, and your researchers can train business team members on how to conduct interviews and shadowing sessions.
Of course, you need to offer the customers something in exchange for their time, but you will find out that it’s surprisingly easy to recruit users once you do that.
That’s (not) it
This list of problems and the solutions are not exhaustive by any means. Depending on the structure of your organization, you will likely face different challenges. I would be happy to hear how you overcame your challenges in the comments below :)
