Linking Strategy to Outcomes in Health Care with OKRs

For many people in health care, the term OKR sounds faintly familiar — something borrowed from the tech world, mentioned in a podcast, a book, or in passing by a colleague who previously worked at a software company.

Yet when we surveyed attendees after our March 2022 quarterly meeting, one signal was very clear: while people had heard of OKRs, it was not obvious how they connected to our day-to-day work as a team, nor how they could be useful in the specific context of health care delivery.

This memo — now adapted as a public essay — was my attempt to answer that question back in 2022.

What are OKRs?

There is no shortage of material on OKRs. If you want a canonical reference, Measure What Matters by John Doerr and the What Matters website are both solid starting points.

But definitions only become useful once they are grounded in the realities of a particular organization. Here is how I chose to describe OKRs to our team:

“

OKRs are a vehicle that help us focus on a small set of important, measurable commitments — and show a direct line of impact for patients and for the enterprise.

From that definition, three themes matter: vehicle, focus, and measurement.

OKRs as a vehicle

Before OKRs, we had already introduced several tools and methods into our engineering and product practice:

• We had begun implementing scrum.
• We added a discovery backlog to get “upstream” of the sprint backlog.
• We worked with colleagues across Inception Health and Froedtert to stand up stream-aligned teams.
• We were in the process of hiring a new Product Manager.

All of these are useful. They improve how we organize and execute work inside squads. But they share a limitation: they help with the “how” much more than with the “what”.

• Scrum ceremonies will not tell you whether you are solving the right problem.
• A discovery backlog without a clear frame of reference for importance quickly becomes a parking lot of ideas.
• Team topologies help you organize flow, but they do not, on their own, articulate what the flow should be directed toward.

Concretely, I found it hard to do four things consistently:

• Understand the problems we were actually trying to solve as a health care organization.
• Analyze those problems deeply enough to justify committing scarce time and resources.
• Prioritize work based on outcomes and end goals, rather than on the “ordre du jour” of the loudest request or newest idea.
• Preserve the autonomy of squads to turn the “what” into a product, while remaining accountable for results.

After internal discussions, conversations with peers at other organizations, and a fair amount of reading, we landed on OKRs as the missing piece: a way to connect strategy, product, and measurable outcomes without abandoning the cultural principles we cared about.

OKRs, in other words, became the vehicle that tells us what we are building as a clinical engineering team — and why.

OKRs to focus

At the organizational level, we deliberately kept our OKRs short and sharp: a few Objectives, each with a small number of Key Results.

For one of our early quarters, our top-level objectives looked roughly like this:

• Transactions Objective – Make getting care easier through digital transactions.
• Growth Objective – Increase the number of patients who interact with us digitally.
• Value Objective – Grow value in primary care services and scale our preventive care programs at lower cost.

A few properties of these objectives are worth emphasizing:

• Mission-driven and inspiring. Objectives should speak to what matters for patients and for the business. They should not prescribe the solution, nor hide a metric in disguise.
• A commitment, not a wish. An objective is a statement of what the organization is actually willing to stand behind for the quarter — what we will trade off against other good ideas.
• A filter against noise. By naming what is important, we implicitly name what is not. OKRs give us a shared way to distinguish between strategic priorities and individual opinions.

For squads, this matters. A clear objective provides a crisp view of what the organization believes our patients need most right now. It acts as a shield against the constant wave of feature requests, stakeholder opinions, and “could you just…” asks that any successful team attracts.

Take our mobile app. We had already built a solid platform, but we regularly disagreed on which features to prioritize. The root cause was not the lack of ideas; it was the lack of a clear conduit to distill, share, and agree on our goals. OKRs were our attempt to build that conduit.

OKRs to measure

If objectives tell us where we are going, Key Results tell us how we will know whether we are making progress.

Key Results are not tasks. They are not a list of features. They are specific, measurable outcomes that, taken together, indicate whether we are on track to achieve the objective.

A good mental model:

• Objectives are ambitious.
  
• Objectives are about direction.

while

• Key Results are concrete and measurable.
  
• Key Results are about evidence.

In the original memo, I used one of our FY22 key results as an example:

Decrease by 40% the total number of support calls per 100,000 sessions in our platform by the end of the year.

This single sentence encodes several important properties:

• It is a specific measure tied directly to an objective like “Make it easy for patients to interact with us.”
• It is tangible, pragmatic, and time-bounded. Instead of asking, “Did we make things easier?”, we can ask, “What is our support call volume per 100,000 sessions this month?”
• It is defined upstream at the strategy level but implemented downstream by the product team. That combination gives squads clarity on what matters without prescribing how to get there.
• It requires commitment. A squad that signs up for this key result has the autonomy to navigate the implementation — and the responsibility to own the outcome.
• It functions as a powerful acceptance criterion. It forces us to deepen discovery and avoid filling the backlog with loosely defined ideas.
• It is tied to things we can reasonably influence or control, while acknowledging that some external factors will always be outside our reach.
• It is informed by strategy and vision, not invented in isolation from leadership’s view of where the organization needs to go.

In short: the objective is the destination; the key results form the compass. They do not guarantee good weather on the journey, but they prevent us from wandering without realizing it.

How do OKRs fit into our strategy and engineering?

My enthusiasm for OKRs has never been about the framework itself. Tools are only useful insofar as they help organizations communicate better and build better products.

From the start, I tried to frame OKRs not as a doctrine, but as an experiment with a high upside: If we defined them carefully, used them consistently, and wove them into our engineering fabric,

then OKRs could become a critical component of how we build — rather than yet another management fad that everyone learns to ignore.

That is also why I do not expect everyone to simply “believe in” OKRs. Skepticism is healthy. The commitment I asked for then, and still ask for now, is slightly different: Let us take the experiment seriously, work with it in good faith, and improve it together.

If at any point you are unclear, unconvinced, or see friction between the framework and the reality on the ground, that is not a reason to disengage; it is a reason to talk. Slack channels, memos, 1:1 conversations with tech leads, engineering managers, or with me directly — all of these are valid places to surface questions and concerns.

Over a few iterations, I expected two things to happen:

1. Our implementation of OKRs would evolve in ways that are specific to our context.
2. The real test of success would not be a perfectly written set of OKRs, but whether we had built products and services that delivered real value to patients and the community.

Looking back from today, that expectation was directionally right.

What OKRs are not

When organizations adopt a new framework, there is a recurring temptation to load it with expectations it cannot possibly carry. To avoid that, I found it helpful to describe what OKRs are not intended to be.

• OKRs are not a religion. They are a mechanism to improve how we work as an organization, not a creed to be followed blindly. The goal is clarity and alignment, not ritual compliance.
• OKRs are not the only lever we have. We still need to improve the quality of our code, our release cadence, our ability to measure, and our design and clinical workflows. OKRs sit alongside these efforts; they do not replace them.
• OKRs are not an excuse to stop exploring. Innovation, creativity, and going beyond the obvious remain essential. The point is not to suppress new ideas, but to ensure that each squad’s explorations still contribute to the organization’s most important outcomes.
• OKRs do not cover everything we do. They focus on the subset of work we are willing to measure ourselves against at an organizational level. There will always be important activities — operational maintenance, foundational work — that sit outside formal OKRs.

Used in this spirit, OKRs become a shared language: a way for patients, stakeholders, leaders, clinicians, and engineers to talk about what we are trying to achieve, not just what we are trying to build.

Postscript - 2025

When I first wrote this memo in 2022, OKRs were new to us. They required deliberate explanation, training, and a bit of advocacy. They were visible — sometimes too visible.

Today, they occupy a different place in our practice.

OKRs have become part of the routine architecture of how we run product at Inception Health: they anchor our quarterly planning, they shape the conversations we have with our board, and they show up naturally in the way we report on progress.

Interestingly, they are now less visible precisely because they are better integrated. We use them almost instinctively:

• Teams draft and refine OKRs as part of their normal planning, not as a separate exercise.
• The framework itself has become more nuanced, informed by our experience, our team topologies, and other tools we have adopted along the way.

In other words, OKRs are no longer the story. They are part of the operating system.

That said, the conviction from 2022 still holds: OKRs alone are not enough. They sit alongside many other elements — discovery practices, technical excellence, measurement capabilities, design, clinical partnership, and team structures — that are required to make the whole system useful.

Most importantly, none of these frameworks change the fundamental test that matters: Are we delivering better outcomes for patients, and are we relentlessly raising our own bar for excellence?

If the answer is yes, the specific tools we use will evolve over time, and that is fine. If the answer is no, a beautifully written set of OKRs will not save us.

OKRs helped us build a clearer bridge between intent and impact. But the ultimate litmus test remains the same: the real-world outcomes we create for patients, caregivers, and communities — and our willingness to hold ourselves accountable to them.

I would like to thank Brad Crotty and the entire Inception Health team for their ongoing commitment to exploring how product engineering can serve our patients and community.