| Product Practice #295 |
Dear Reader,
Many product teams perceive the focus on User Outcomes as arbitrary goal-setting and the opposite of serving users. And it‘s easy to understand why.
Many widely shared examples of User Outcomes out there read like this:
„Users buy more tickets“
„Customers use more integrations. “
„Returning shoppers add more items to their basket.“
A product leader recently approached me after a conference talk, sharing his team‘s concerns that Outcomes would just be repackaged business goals. Looking at the above examples, his team would be right. These read like how the company or business wants their customers to behave.
To make Outcomes (aka changes in human behavior) useful, you have to remember that they should describe changes in behavior that are useful to the audience you intend to serve, which requires a proven problem.
Useful Outcomes = Useful for the User
It‘s not enough if Outcomes describe „technically correct“ changes in behavior. Instead, there should be a clear connection between business-informed research intent and insights generated by qualitative and quantitative techniques.
Another way to approach this is to look at Outcomes as flipped user problems:
The simple question teams need to try and answer here is, „How would users whose problems got solved behave?“ This will then be the foundation for finding appropriate measures to set in your OKRs.
If you enjoyed this, you can share the essay on LinkedIn here.
That's (almost) all, Reader. If you enjoyed today's issue, please do reply (it helps with deliverability). If you didn't, you can unsubscribe here.
Thank you for Practicing Product,
Tim
PS: My friend Itamar released his long-awaited book "Evidence-Guided" last week. It's a practical synthesis of the principles taught by Itamar to help companies move away from opinions and towards more evidence. I highly recommend checking it out
Amazon USA: http://amazon.com/dp/B0CJCDP1H7
Amazon UK: http://amazon.co.uk/dp/B0CJCDP1H7
Amazon Germany: http://amazon.de/dp/B0CJCDP1H7
The Early Bird rates for my January 2024 workshops on Product Strategy, Product OKRs, and Product Discovery in Berlin expire on October 10. Secure your spot to make the most of your 2024 L&D budget.
Bundle options are available if you're interested in more than one workshop. For team packages, reply to this email for a custom quote.
| GET YOUR TICKETS |
What did you think of this week's newsletter?
Click here if you only want to see what's behind each option
As a Product Management Coach, I guide Product Teams to measure the progress of their evidence-informed decisions.
I identify and share the patterns among better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.
1 tip & 3 resources per week to improve your Strategy, OKRs, and Discovery practices in less than 5 minutes. Explore my new book on realprogressbook.com
Product Practice #384 Pragmatic OKRsKeynote Recording READ ON HERBIG.CO PUBLISHED Nov 13, 2025 READING TIME 2 min & 16 sec Dear Reader, Possibilities to Connect with me in the Next Two Weeks Nov 13: Product Owner Day (Online, German) Nov 18: UXCam Live Workshop (Online, English) Nov 18: Scrum Event (Online, English) Nov 20: ProductTank FFM (In-person, English) I hope to see you there. This week, I want to share the recording from my talk on Pragmatic OKRs from this year's World OKR Summit:...
Product Practice #383 When to recognizeYour OKR Planning takes too long READ ON HERBIG.CO PUBLISHED Nov 6, 2025 READING TIME 5 min & 37 sec Dear Reader, It's week three of Q4 planning. Your team has revised the OKRs five times. Leadership wants one more alignment session. The quarter starts in a week, but you haven't actually begun working toward the goals yet. The moment you're tweaking wording instead of committing to a strategic goal, you've crossed from Real Progress into Alibi Progress....
Product Practice #382 Discovery Activitiesover The Discovery READ ON HERBIG.CO PUBLISHED Oct 30, 2025 READING TIME 3 min & 52 sec Dear Reader, Most teams treat Discovery like a season: "We'll do Discovery for Q1, then build in Q2." This creates a problem. It separates learning from building, makes stakeholders impatient, and turns Discovery into something you have to defend rather than a practical way to reduce uncertainty. The real question isn't "Are we doing Discovery?" It's "Are we...