The Problem with 0-1 Metrics
|
|
|
|
READING TIME
3 min & 51 sec
|
Dear es,
Scaling Product Discovery requires more than just having teams talk to more users. In fact, just having teams interview more users without structure and some baseline education might do more harm than good. Here’s what I took away from training over 30 product trios at The StepStone Group:
#1 Educate Cross-functional, wherever possible
It doesn’t make sense to expect Discovery collaboration between Product, UX, and Engineering but only train Product Managers. You want to avoid having the PMs be proxies for the skills you want the entire team to adopt. Having all three core competencies in the training meant that they could understand and challenge each other much better.
#2 Balance Adapting High-level Guidance with Tailored Practical Applications
Sarah Reeves and the Product Ops team experimented with many ways to get people the information they needed. First, they tried a high-level Mural to illustrate potential processes, which felt too theoretical and left people wanting more details. This led to a more in-depth playbook, which covered much ground but was too detailed.
So, the team returned to more high-level guidance in the form of the original Mural and a lighter version of the playbook. They incorporated feedback from each approach to strike the right balance between the vision, high-level reasoning, and practical knowledge that people need to incorporate learnings into their daily lives.
Their prior experience balancing guidance with practical application led us to agree to complement the training with a series of coaching sessions for those teams. In these sessions, I helped the product trios apply the appropriate discovery techniques to their context.
#3 Treat the Adoption of Product Discovery like a Product
Most product teams apply the principles of starting small, measuring progress and iterating accordingly to shipping solutions. One of Sarah’s biggest takeaways was to extend these principles beyond the product and use them to shape the way teams work.
“Do an MVP for certain areas to find and prove value quickly,” she recommends. That will give you “evidence to show the benefit of working this way.”
In practice, that means Defining a clear MVP for how you want to change things, testing it with a small group of the organization, and measuring progress to prove the value of your initiative. This will make it easier to scale upskilling efforts that have worked.
Did you enjoy this one or have feedback? Do reply. It's motivating. I'm not a robot; I read and respond to every subscriber email I get (ask around). If this newsletter isn't for you anymore, you can unsubscribe here.
Thank you for Practicing Product,
Tim
Join my In-Person Workshops in Berlin
I'm excited to bring my beloved in-person workshops back to Berlin in January 2025. You can choose between 1-day workshops on Product Strategy, Product OKRs, or Product Discovery OR get the full 3-day experience for you or your team.
(early bird pricing is available until Sep 21)
|
|
Content I found Practical This Week |
Switching from Miro to Jira Product Discovery
This was a detailed conversation where the team walked through: Why they started building opportunity solution trees in Miro and why that worked for quite some time; The limitations they eventually encountered as their trees grew bigger and their outcomes evolved; Why they choose Jira Product Discovery as their new tool of choice.
|
Continuous user research in 11.6 seconds
I call these “dedicated studies.” These are research studies that are put in place to answer very specific research questions such as, “Why are our customers adding items to the cart, but not checking out?” or “Which products or features are the least understood?” The challenge is that these studies will only and always answer the questions they are designed to answer. They will almost never answer questions you didn’t know you should ask, reveal hidden truths, and help uncover opportunities to innovate.
|
4 Common Product Discovery Mistakes (and how to avoid them)
When confidence is low, we should invest more in discovery as the risk of being wrong is higher and when confidence is high, we may not need to invest much time, if any, into discovery as the risk is low. When we don’t do enough discovery on something we end up in the “stupid zone,” increasing the likelihood that we end up building something that doesn’t solve a problem or isn’t the best possible solution. And when we do too much discovery, we simply waste time. So, there’s a safe zone that we ideally want to stay within.
|
What did you think of this week's newsletter?
As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.
I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.
Enjoy the newsletter? Please forward it. It only takes 2 clicks. Coming up with this one took 2 hours. |
| 