I’m a huge fan of product discovery and dual track development, Jeff Patton originally brought me there the first time in 2013 in his CSPO training. Thankful since this day, I’m trying to establish dual track development on team level, as I’m convinced, that this is the way to build great products. As I worked with multiple teams over the years, I was able to collect some experiences of what works and what’s not.
Last week I read a very good post Discovery Hand-Offs Kill Momentum: Here’s What to Do Instead by Teresa Torres where she explained in detail how to work together and what principles to follow. This post triggered me to write about this topic too, as this is an important concept to understand and praised by several thought leaders in this area. I highly recommend to read the post and think some time about it, what you’re able to adapt ideally starting next week.
Why is product discovery so important?
The following statement has been made in similar ways from various thought leaders. It stands by itself.
To set expectations, strong product teams normally test many product ideas per week – on the order of 10 to 20 or more per week.
Marty Cagan
Three product dimensions to cover
My main key takeaways I’d like to confirm is the dimensions of a product trio. To build the best outcome, uxdesign, tech and business concerns are necessary:
Therefore I really don’t like the terminology of a Product Trio, never did, as it is calling out three people or more from each dimensions or an explicit team doing product discovery. I had this conversations multiple times.
The Product Trio concept is not limited to three people or a specific team. Product discovery needs to be done by each and every team. Each team needs to cover all three areas or dimensions to build something useful and solve customer problems.
Tweet
This comes with an important side note:
Don’t limit the number of team members to contribute to product discovery. Open up and include them as soon as possible. Ideally, try to get at minimum one team member per dimension. Invite team members to contribute if they like, make it optional, don’t force them.
Tweet
Also don’t exclude team members contributing and participating product discovery. Once you’re excluding someone from product discovery, you’ll have a total different problem.
From my experience, once you’re opening up, roles will be covered by team members and change over time who will lead product discovery from a technology perspective. As by nature developers and qa are stronger in number of people on a team level compared to uxdesign and PO’s.
“If you’re just using your engineers to code, you’re only getting about half their value.”
Marty Cagan
To really solve customer problems, teams need to do product and product delivery in parallel, it needs to be a vital part of each team.
It’s critical that the team that is building the product is the same team that is engaging with customers directly.
Teresa Torres
The main challenge I’ve seen multiple times is to engage developers participating in interviews on top of their product delivery burden as participation in product discovery usually is a huge time invest, especially in organizations where delivery and output is more valued.
Another recommendation how to make work more digestible:
Include product discovery work into your team backlog each and every sprint. Show progress and have discussions part of your team ceremonies like refinements, plannings and retrospectives!
Tweet
I experimented multiple ways, own backlog for product discovery, but single product backlog items (PBIs) in the same sprint work good and integrate the product discovery work into a sprint. It’s transparent for the whole team and they’ll know early on what’s coming next.
As a format I love to go with problem AND solution hypothesis, and let the uxdesigner do his or her work.
What’s next?
I’m going to write down my latest experiences about product discovery soon, happy to hear about yours too – I’d be happy if you let me know.
Best,
Patrick
Patrick Sauerwein | @virtual_patrick 