More on this book
Community
Kindle Notes & Highlights
by
Josh Seiden
Read between
June 17 - June 20, 2025
For our well project, the model might be something like this: we plan our resources (the people, materials, money, and other things we need), we undertake a set of activities (traveling to the village, acquiring and transporting our materials, building a well). If all of this goes according to plan, we create the output—the well. If the well works as planned, we achieve our outcome—people in the village spend less time carrying water. That in turn, becomes an important contributor to the impact we seek: a higher standard of living in the village.
My team on Wall Street knew we should be delivering value sooner than we planned to—but we didn’t know how to step back and think critically about our work. If we had known about outcomes, we might have been able to adjust course. We might have asked, “what is the outcome that our business seeks?” If an outcome is a change in customer behavior that drives business results, we could have asked, “what is the customer behavior change that we are looking for?”
There are a lot of meanings to this phrase, but the way I use it, it simply means “an experiment.” An MVP is NOT version 1.0 of your product. Instead, think of MVP as the the smallest thing you can do or the smallest thing you can make to learn if your hypothesis is correct.
So how do you write better OKRs? One way is to think of Key Results as outcomes. If you express your Key Result as a measurable customer behavior, you almost automatically have a well-written OKR.
For example, your objective might be to Successfully Launch our New Product. Your key results might be: 25 positive reviews in app store in first day 3 mentions on industry blogs before launch 1000 new user registrations in first week 25% of new users convert to repeat users
Use the magic questions to define outcomes: what are the human behaviors that drive business results? How can we get people to do more of these things? How will we know we’re right?
Roadmaps are supposed to help organizations manage uncertainty—they promise to answer questions like, “what are we going to be working on? What are we going to deliver? When can we expect this new capability/feature/product?” These are all reasonable questions. The problem is that most of the time, the answers that make it to the roadmap are guesses, fiction, or lies.
Instead of building plans around the outputs that you’ll make, it often makes more sense to plan around themes of work, problems to solve, or outcomes to deliver. The less certain you are that your outputs (ie. the features you want to deliver) will deliver the results you seek, the more it makes sense to plan in terms of outcomes, and to build your roadmaps around sets of outcomes.
CEO Robert told me, “If someone comes to me with a proposal, then I challenge the individual: What’s the outcome? What’s the impact? Does it move the needle in one of our six important [strategic] Impact Categories? If it does, then I’m a sponsor.”
If we create this outcome for the user, it will deliver this outcome for the business.

