Why your Discovery Insights
|
Dear Reader,
"I believe we should split-test this change to the funnel."
"No, we tried that 3 years ago. Didn't work."
End of story...right?
9-ish years ago, I got to listen to Willem Isbrucker sharing his insights from running experiments at booking.com (famous for their quantitative data-first approach) at ProductTank Hamburg. Among other things, he discussed how split-test results had an expiration date. If I remember correctly, it was 6 months. Meaning, if you had an idea that was tested less than 6 months ago, it might not be worth retesting right now. But if it was more than 6 months ago, the changes that have occurred in the meantime justify re-testing.
Many people get hung up on how "horrible" booking.com's UI looks or how "6 months doesn't work for us." But I believe there's a more universal practice in that anecdote, that applies to you, no matter the industry, company size, or maturity: It's that what was true in the past might no longer be true because of context changes. In simpler terms, your insights could benefit from an expiration date.
In the context of Product Discovery, this doesn't necessarily mean you have to re-do generative research or evaluative testing every six months. What it means instead is to run planned decisions and activities through a mental checklist:
Having researched or tested something in the past isn't a reason not to do it again, any more than it's a reason to start all over every time. What it is is an insight from a specific context you need to check for its applicability right now.
So, take this with you into your day:
What is an activity or decision you have recently dismissed because there was an effort around it in the past? How long was that ago? What has changed since then that might yield different, more actionable results?
Then, please reply to this email and let me know what came up for you.
Thank you for Practicing Product,
Tim
I'm excited to bring my beloved in-person workshops back to Berlin in January 2026. You can choose between 1-day workshops on Product Strategy, Product OKRs, or Product Discovery, or opt for the full 3-day experience for you or your team.
| LEARN MORE |
(reach out for custom team quotes)
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.
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 #405 How to treat Prototypes as Decision-Making Tools PUBLISHED Apr 23, 2026 READ ON HERBIG.CO From Strategy Choice to Planned Experiments in One Workshop In my upcoming live remote workshop From Strategy to Discovery, I take you from sharpening your Product Strategy, to defining leading indicators for measuring progress, all the way to prioritized assumptions you need to derisk end-to-end. Three 4h Live Sessions - Lifetime Material and Recording Access - Real Results Join...
Product Practice #404 Linked Better Practices over Stacked Best Practices PUBLISHED Apr 16, 2026 READ ON HERBIG.CO Dear Reader, During a recent webinar, someone asked a question I had to think about a bit longer: "What do you do when your strategy is still early, and you're not sure if it's right?" The answer that popped into my head was based on an incredible piece of advice (or admission) I received from a former boss 10+ years ago: No one knows if their strategy is right in the beginning,...
Product Practice #403 Linked Better Practices over Stacked Best Practices PUBLISHED Apr 9, 2026 READ ON HERBIG.CO Dear Reader, During my last webinar on Connect Strategy, Goals, and Discovery with Progress Wheel, I asked people which part of their work is most prone to Alibi Progress. Almost everyone who chimed in named OKRs. And that's because many OKR cycles start the same way for teams: Someone opens a spreadsheet, fills in three to five semi-random metrics, and picks a value that isn't...