10 common product discovery traps đȘ€
Getting discovery and delivery to play together nicely is hard. Iâve seen them be the best of friends at some organisations, and at others, Iâve seen them at loggerheads. This article describes 10 of the most common challenges Iâve encountered and provides a handful of tips for each that will hopefully help you harness the power of product discovery.
The 10 traps
- Delivery gets in the way of discovery
- Discovery-to-delivery disconnect
- Lack of user research candidates
- No dedicated user researcher
- Discovery is undervalued
- Recommendations arenât feasible
- Discovery tells us to stop
- Too many people are involved
- Cross-team complexity
- Tools and techniques uncertainty
Trap #1: Delivery gets in the way of discovery
Perhaps the most common of all, discovery continually takes a back seat to delivery activities. As product professionals we have it hammered into us to focus on value and âwork from the right of your kanban boardâ, so this is fully understandable.
Symptoms include building things without adequate discovery work, the quality of discovery work slipping, poor attendance or postponement of sessions, and frustrated, burned-out practitioners.
The good news is that there is a lot you can do about this.
Match your delivery cadence
Product teams are great at lining up regular ceremonies to keep things ticking along - think stand-ups, story refinement, sprint planning - but discovery often doesnât get the same representation.
Block out some time in existing sessions to discuss discovery, or drop in additional sessions to help prioritise and progress discovery activities.
Dedicated discovery sprints
A more extreme measure is to block out a longer period of time for some or all of the team to get stuck into the problem space. This can be particularly useful for the more unknown, gnarlier challenges.
The Google Ventures approach is a good starting point.
Adjust your team make-up
This doesnât need to be permanent. It doesnât necessarily need a change of personnel. It could just be a temporary repurposing of one of your engineers to help out on the discovery front. Or it could be âborrowingâ somebody from another team or from a central support role to help out whilst you look to strike the right balance.
Adjust what you deliver
Sometimes itâs possible to be smarter in terms of the type of delivery work you take on at any one time. Could you turn focus temporarily to items that are likely to be lighter on discovery?
Typical candidates would be architectural improvements, tech debt, addressing known defects, well-defined functional improvements, or broader team improvements on things like ways of working.
Establish a delivery buffer
You can go one further than adjusting the balance of your delivery work by consciously seeking to build up a pot of discovery-light work.
This might include looking slightly further ahead at the next few big-ticket items and asking yourself whether there is anything in there that is well-understood that you might be able to get an early start on.
Harness insights from other teamsâ discovery activities
If you have the luxury of working in an organisation with multiple teams and multiple strands of discovery, you may be able to alleviate the burden on your team by utilising the insights of others.
Iâve seen this work well at several organisations, particularly those where there are teams that work on closely related aspects of the same product, and those that are mature and disciplined enough to capture and share the outcomes of their research.
Discovery automation
It sometimes helps to hold a discovery lens up to the art of discovery itself. Are there any laborious elements that could be improved with better tooling and instrumentation?
Two great examples that spring to mind are an automated keyword and sentiment analysis of survey responses and feedback data, and GOV.UK's Prototyping Toolkit - both of which were a huge help in eliciting and distilling discovery insights.
Trap #2: Discovery-to-delivery disconnect
So youâve got the balance right - focused, high-quality, continuous discovery is very much the order of the day - but the things youâre building donât quite seem to align, or worse still you find that you are rarely acting on your discovery insights.
Donât go too far with discovery
One of the finer and more difficult aspects of product discovery is knowing when enough is enough.
A good rule of thumb is for each team to only operate in one, or maybe two problem spaces at a time, and also to timebox discovery - two to four weeks is usually enough for a mature team with good continuous discovery practices in place when looking to bottom out a big-ticket roadmap item.
And the closer the discovery activities are to the associated delivery work, the better. If you know you havenât got the capacity to start a delivery piece for three months, defer the discovery for a month or two. The fresher the insights when you come to do the work, the easier it is for the team to connect the dots.
Encourage participation
As a broad rule, the more members of your team that participate in discovery, the greater the teamâs overall understanding of your products and users, the closer discovery and delivery align, and the more motivated your team will be.
That said, other than during dedicated design sprints at the BBC, I donât think Iâve ever seen a whole team work as one on product discovery. Itâs not realistic nor fair to expect everyone to participate in discovery, so donât be too harsh if some team members are less keen than others.
Capture and share discovery findings
It should be a given but it regularly isnât: your discovery work itself is your documentation. Record your user interviews. Expose your raw data and your workings. My preference is a dedicated Miro board or canvas for each discovery piece.
Why are you doing it? What are you looking to learn or confirm? When did it happen? What did you do? What did you learn? What are your recommendations and next steps? Anyone coming cold to your Miro board should be able to answer all of these questions within five or ten minutes.
And then share it! Put in a playback session and cast the net far and wide. Share the Miro board anywhere it could prove useful. Any insights that you think might help out another team - let them know.
This is one of the best ways to reach those who might not want to be involved in discovery in real-time, as well as those who really want to but just donât have the capacity.
Trap #3: Lack of user research candidates
This has reared its head at some point at most organisations Iâve worked with. It can be a budget constraint, related to tooling, or a challenge finding suitable candidates - particularly for products with a very specific market.
Thankfully it doesnât mean you have to put the brakes on discovery.
Join forces with others
If others in your organisation are also feeling the pinch, reach out. See if you can work together and get the most out of the smaller pool of budget or research candidates.
In doing so, you may also find that you were duplicating some elements of discovery, and youâll also put yourselves in better stead to harness each otherâs insights.
Friends, family, colleagues, forums
Can you short-circuit your constraints? Scraping together five or ten candidates from a pool of friends, family, or colleagues in another area can sometimes be enough to give you some signals.
For more niche products, forums can be a good fishing ground for willing participants.
Guerilla testing
I had always viewed this as a last resort until I worked with Transport for Greater Manchester to help them move to a cloud-native, user-centred website.
The discovery lead at the time was a big advocate of guerilla testing, and we regularly descended on Manchesterâs transport hubs to get rapid feedback on prototypes on an almost daily basis.
This wonât work for all products - you need to have a broad user base really - and youâll need to have thick skin (!), but donât dismiss this as quickly as I used to do.
Get closer to your marketing and account management team
This is critical for a B2B product, and a really useful avenue for getting access to all sorts of discovery gold.
Seeking feedback directly from paying customers brings its own challenges, but the benefits greatly outweigh any drawbacks.
Utilise other discovery sources
It doesnât all have to be about primary user research. Is there anything else you could do to help you validate your assumptions, or inform your decision-making?
An example could be analysing secondary user feedback from contact centre data or third-party reviews such as Trustpilot.
Trap #4: No dedicated user researcher
Iâve known teams dismiss the notion of discovery altogether because they donât have a designated user researcher, as if they're blocked, or nobody is accountable for discovery in their absence.
This is absolutely not the case.
Do it yourself
The team as a whole is accountable for product discovery, and anyone can lead and champion the cause.
Whilst a dedicated user researcher can be a brilliant asset, it is by no means essential.
Stand on the shoulders of others
Working on GOV.UK products really opened my eyes to the benefits of pooling and sharing discovery outputs. Many, many times, my teams utilised the distilled recommendations of others to help aid our decision-making and save us from reinventing the wheel.
Utilise other discovery sources
As per the previous trap, what else could you do here if youâre not confident undertaking primary research?
Could analysing your product usage data help? Might an A/B test enable you to validate the assumption?
Trap #5: Discovery is undervalued
You have all the people you need for good, solid product discovery. You have a healthy balance between discovery and delivery, and the former flows freely into the latter. And yet discovery still doesnât seem to hold the weight in your organisation that it should.
You might have difficulty garnering support to make new hires or improve tooling, or you may find your recommendations are regularly dismissed at exec level.
Over-share
Speak up about your discovery findings. Youâll be amazed to see the conversations that they can spark and the value they can add in contexts that you may not have realised.
This could be posting your discovery board and a TL;DR in certain Slack channels. It could be opening your discovery playbacks to a wider audience. It could be creating a team discovery wall in your office. Maybe even talking at wider industry events.
Redress the balance
There are many channels through which product people give updates on delivery - think weeknotes, show and tells, progress update meetings, roadmap playback sessions - but itâs quite rare that discovery makes an appearance in any of these.
Make a conscious effort to call it out. To give it the same weight as delivery. To shift the scales.
Close the loop
And whenever you do talk about delivery - that feature you just shipped, the impact you just quantified, the thing that youâre building right now - bring it back to discovery. Shine a spotlight on it. Say why youâre doing the thing, and how product discovery kept you on the straight and narrow every step of the way.
Trap #6: Recommendations arenât feasible
This is a more acute version of a disconnect between discovery and delivery - when you begin building something based on the findings of some great discovery work, only to find that it isnât technically possible for one reason or another.
Thankfully there are a few specific treatments for this.
Involve engineers in traditional discovery
An obvious one, but having your tech lead or any of your engineers involved in some or all of the discovery gives you a much greater chance of catching this early.
Pre-discovery feasibility
If itâs not possible to have engineering representation in your discovery efforts, it can help to have a session with one or more technical colleagues before you undertake a significant chunk of discovery.
This gives you the opportunity to talk through the problem space youâll be working in, and the shape of any questions, prototypes, or other discovery devices you may be looking to utilise. In doing so, youâll surface technical challenges earlier and hopefully go into discovery with a more informed view of your constraints.
Dedicated engineering discovery
You can have all the up-front engineering involvement in the world, but you still wonât surface all of your technical constraints until you actually get stuck into building the thing. This is where dedicated engineering discovery comes in - something I wholeheartedly advocate alongside more traditional discovery.
In practice, this could take the shape of a timeboxed investigation of a third-party API, building a proof of concept, or just reading up on a particular piece of tech or problem space.
Trap #7: Discovery tells us to stop
This is one of the most difficult challenges to navigate: when there is an expectation that a specific problem needs to be solved or a feature built, and all the signals from your discovery effort tell you otherwise. Or it could be that there has already been a commitment made to senior stakeholders or even customers that something is imminent.
The pressure can be so intense that the discovery team feel the urge to augment their findings or swallow them altogether rather than risk conflict.
Be honest, transparent, and thorough
Lay all the cards on the table - thatâs really all you can do. Expect to be challenged even more than usual, so make sure youâve done your homework and you have all of your data and insights ready to go in order to support your recommendations.
Know when to hold âem and when to fold âem
Sometimes itâll go your way and sometimes it wonât. Knowing how hard to push is one of the trickiest tightropes youâll have to walk professionally, but in reality there will be occasions when politics will trump research, so donât let this downhearten you.
Deliver iteratively
If you are overruled - and this should really be a given but, again, isnât always - look to build and deliver the thing in increments.
Having an MVP, little-and-often mindset will enable you to get more signals either way - whether it proves that your execs were right all along, or gives you the ammo you might need for a second sortie.
Trap #8: Too many people are involved
Getting definitive insights and recommendations is difficult at the best of times. Some problem spaces exacerbate this by the sheer weight of numbers of people that may have a stake in the outcome - this could be due to a lot of third-parties being involved, complexities that seemingly necessitate many subject matter experts, or the problem domain spanning multiple teams.
Do your homework
A common misconception is that discovery work always has to be done collaboratively with all those somehow invested involved directly. A lot of the time, a smaller subset - often just a very good product designer - can clear up assumptions and fill in gaps to ensure that any broader sessions have the clarity and focus that they need.
Structure your sessions around a straw-man proposal
Doing the work upfront so that you have a first pass of what the problem space is, or what a solution could look like not only breeds confidence amongst participants, it crucially brings structure and order to proceedings and is the most effective approach Iâve seen for surfacing assumptions and forging alignment.
Service blueprints are probably the best tool Iâve used for this - something visual and easily followable that you can talk around, and a readymade canvas for capturing anything that bubbles out of conversations.
Be ruthless about who you invite
Donât feel like you have to invite everybody to everything. More people will thank you for the time back than will complain about being left out.
And donât be afraid to ask yourself if you have to be in every session.
Trap #9: Cross-team complexity
Itâs not uncommon for discoveries to cover the domain of multiple product teams, particularly across larger organisations. Whilst these are not without challenge, they can prove the most impactful and rewarding of opportunities, and are a great way to build relationships and share knowledge between teams.
Set rules of engagement upfront
Have a conversation with the other team(s) early to ensure they have plenty of notice. Some coordination may be required to ensure that all parties can line up the necessary people around the same time. This could be a conversation between the product managers of each team, or may also lean on tech leads or product designers.
Iâve known teams negotiate and compromise around such âsharedâ initiatives. It could be that one team owns the whole of the discovery and they collaborate on the delivery.
Request central coordination support
It can help to have somebody outside of the teams pulling the strings. Iâve worked with organisations that have a central delivery management function that can help to coordinate and unblock and also seen those at tribe level provide support - such as âheads ofâ or principal practitioners.
Short-lived specialist teams
Another pattern that can work is to have a dedicated, usually smaller group lead the discovery (and sometimes even delivery) effort, formed up from the likes of âheads ofâ and principal practitioners, or less commonly seconded from other teams.
This can bring its own challenges, as those outside of teams may not have the necessary context, and you also have to be careful to ensure that discovery findings feed through to the teams that then go on to deliver on them.
Trap #10: Tools and techniques uncertainty
Some teams are reluctant to engage in discovery activities just because theyâre unsure how to and can be concerned that they wouldnât get any value from it as a result.
This can be particularly prevalent in less mature teams and organisations without a strong discovery culture.
Do it anyway
Any discovery is better than none. Even if you only have a couple of tools in the locker, or youâre not feeling confident, donât let it hold you back.
What have you got to lose?
Communities of practice
Iâm a keen supporter of communities of practice and have seen them used to great effect at many organisations.
Join them. Attend meetings. Participate. Not only can you forge great relationships and learn from experts, but you can also pitch your problems and seek advice directly.
And it doesnât have to be just those in your organisation. There are plenty of broader communities across tech, such as Product Tank Manchester.
Read up on discovery
A few books and online resources that will stand you in good stead:
- Continuous Discovery Habits (Teresa Torres)
- Inspired (Marty Cagan)
- Build Better Products (Laura Klein)
- Escaping the Build Trap (Melissa Perri)
- Mind the Product - Product Discovery
- Miroverse - Research & Design
In summary
Dual-track delivery and discovery will never work perfectly.
Thereâll always be room for improvement, and youâll regularly need to tinker away to help you adjust the balance as your priorities and team shape evolves.
Yes, thereâll be bumps in the road, but hopefully, some of the tips and tricks above will provide some reassurance that nothing is insurmountable.
