Product Discovery is a Team Sport
Discovery is arguably the most important part of modern product management. It’s the secret sauce for how to build great products that your customers will love. It’s also one of the most exciting and rewarding parts of the role. Marty Cagan began championing the concept and its importance over a decade ago. Here are his definition and criteria all the back from 2007:
First, you need to discover whether there are real users out there that want this product. In other words, you need to identify your market and validate the opportunity with your customers. Second, you need to discover a product solution to this problem that is usable, useful, and feasible. In other words, you need to design your product and validate it with your customers and your engineering team. Getting up close and personal with your customers early on as much as possible. Learning about how they use your product (and others) in their own environment is invaluable.
Missionaries Over Mercenaries
I’m not here to teach you about Discovery as a concept. There are countless Twitter threads, Medium posts, and conference talks on best practices. Instead, I want to talk about an anti-pattern and how we can overcome it.
All too often, Product Managers (and maybe a designer or two) go off on their own discovery conquest. After their long journey, they bring their divine user insights back to the team. Developers and QAs then get on with delivering the actual product. There is a common reluctance to involve the whole team. We can’t take technical folks away from their keyboards. What if we fall behind schedule? It’s their job to code! RIGHT?
This type of dual track development is where half the team doesn’t get a chance to take part in product discovery. Product discovery and delivery are separate phases and always at odds. That may seem commonplace, but it actually creates a culture of apathy within teams. Jeff Patton puts it this way,
There’s usually more than enough discovery work to do and lots of ways to involve the whole team in doing it. If you feel pressure to shorten discovery work to “feed the beast,” it usually means you’re making decisions to build software before learning enough to be confident that you should.
Rally your team around a vision and then let them take ownership of discovery. If you do, you can foster a passionate team ultra-focused on building great products.
How to Involve the Whole Team
Last year, my team wrapped up an internal project that was all about delivery. During that phase, we focused on improving our agile processes and making sure our product performed at scale during peak usage. The usability, feasibility, viability, and desirability risks were minimal and straightforward to tackle.
But earlier this year, we got the opportunity to take on a project from scratch. It was ambiguous, big, and needed tons of product discovery done. It was quite the mental shift for the whole team. Here are a few techniques that helped my entire team get engaged in the discovery process.
Evangelize a Clear Product Vision and Strategy
It’s critical that your team buys in on the vision and strategy for your product. This is a prerequisite for getting started on discovery with the whole team. If they don’t know why or what they’re trying to discover, they’ll resent you for wasting their time. The team should have a clear idea on the types of users they’re going after. They have to know the metrics they’re aiming to impact. And they need to understand how it all ties up to company vision. These are table stakes, folks.
Don’t be afraid to spend ample time with the your team on this early and often. Of course, kick-off meetings and slide decks are often effective tools. But nothing solidifies product vision quite like hearing customer problems from real users.
Nobody Watches Your Recordings
To start, you have to actually get your team in front of real-life customers. And here is a sad but true fact, almost nobody will watch your 45-minute recording. Make it dead simple and help your team understand the value of this exercise. I use Slack to make it easy for my team to hop into the front lines during their day.
Sometimes you’ll get pushback from the team. They might not have research skills, see the value, or feel too busy. If you run into this, encourage them to still attend and observe. Even being a fly on the wall during user research will help the light bulb go off and build customer empathy. In the case where they won’t come at all, work to build easy to read summaries of research. Use short-form clips of light bulb moments from the customer and too long; didn’t read summaries.
Video calls are a good start. But the most effective discovery experience is talking to users in their environments. There’s something magical that happens when PMs, designers, engineers, and QAs get in a room with a group of users. Our team had many aha moments in a room of users early on in projects.
Be Together
So you’ve got the team interacting with users. Now you need to make sure they’re actually interacting with each other. Early in product discovery, there’s lots of uncertainty. You’re identifying and validating assumptions at rapid-fire pace. It’s critical to keep a strong shared understanding of the insights you’re collecting. Some product teams don’t even sit on the same floor as their technical counterparts. This gets even worse when designers and PMs only share research every week or two at sprint reviews.
If you’re fortunate enough to be a 100% co-located team, sit together every single day. Use the damn whiteboard walls! Talk through what you’re learning and brainstorming what’s next. If your team is remote, schedule a daily discovery recap call during heavy phases of discovery. Full team discussion and debate after interacting with a user is invaluable.
Leverage the Team’s Skills
One of the biggest objections I hear from technical folks is that they can’t afford the time. Is there enough air cover from leadership to involve the whole team in learning? It depends on your organizational culture. Feature factories often won’t be conducive to this type of team discovery.
But even if you’re in a healthy product org, there can still be anxiety from not delivering production code. There’s always plenty of user research and design to do. But it’s important to leverage your team’s technical skills during this phase. Not only does this help reduce their anxiety, it will have a huge impact on discovery.
Our team has learned the most when we build lightweight proofs of concept or prototypes. These often need developers to whip something up technical. These prototypes will never see the light of day and may create some throwaway code. But I have no doubt the time and resources are always well spent. This has helped our project dash from assumptions to validation over and over.
Try Different Methods & Build Habits
There’s tons of collaborative ways to conduct product discovery these days. Here are a few easy ways to pull your team into the discovery process early and often:
- Run a journey mapping session.
- Conduct a discovery sprint with the whole team.
- Use sketch sessions early and often.
- Utilize tools like Mouseflow or Full Story to easily see users in action as a team.
Product Designers are a critical partner and resource for facilitating these techniques. When you’re at the beginning of a project, it doesn’t hurt to try new things. You’ll be able to figure out what works well for your teams.
And finally, use this time to strengthen your discovery muscles as a squad. Teams should never be in a phase of 100% discovery or 100% delivery. Strive towards continuous discovery even when moving into delivering products to your customers. Taking the time to build these skills as a team early in a project’s lifecycle is crucial. It will make it that much easier to keep up these habits when it feels like there’s no time.
The Value of Team Discovery
I've seen the benefits of doing the hard work of product discovery as a team. We're getting ready to launch a whole suite of features that are going to make our customers' lives better. I can't count how many insights we've gained and pivots we've made as a team during this project. Our whole team buys into the customer problems we're solving and care deeply about the outcomes.
As a Product Manager, it's your job is to help foster engagement from your whole team in discovery phases. You don't have all the answers. You won't hear 100% of the user's problems. You won't connect all the dots. Your team will help fill in the gaps. And together, you'll deliver value to your customers and capture value back to your business.
I'd love to hear from you about your experiences with getting the whole team involved with discovery. What common objections have you heard from the team? What techniques have you utilized? How has getting the whole team involved made a difference for your product? Drop a reply to the article or shoot me a tweet @nichols_austinj.
