Dan(iel) Ritz(enthaler)

A good objective (or goal) is a combination of a specific form of progress, a direction for the progress, and an expectation of change.

For example…

We intend to reduce the amount of time it takes to write a medical note so that our clinical staff is no longer working into the evening.

Time spent writing medical notes is what we can influence through the design of our software. We want to reduce the time spent. When we do that enough, we believe our clinical staff will stop writing notes in the evening and spend more time with their friends and family.

We can be specific about our work while also contributing to a big change.

The struggle to write a good objective (or goal) comes form one of two places:

1. We can’t think of anything specific to improve and get stuck.
2. We think of too many specific things to improve and get stuck.

These are similar forms of the same fear:

1. Our idea is too big to be measured in a specific way and we’re too scared to break it down.
2. Our idea will only work by improving several specific things simultaneously and we’re too scared to pick one.

Neither of these fears are true.

Fight the urge to combine and merge forms of progress into abstract concepts. Fight the urge to keep abstract concepts intact.

Working with abstract concepts doesn’t make us more strategic. It doesn’t mean we understand the big picture. It doesn’t mean we’re doing something more valuable.

It means we’re being vague. It means we’re unable to measure progress. It means we should expect low quality output.

Jumping to solutions™ is the quickest way to get in trouble.

A good objective should be agnostic to a solution. It should give a strong feedback loop without dictating a path. It can absorb more variation of planning and better adapt to new information.

Even though we can’t start with a solution, we still need to be fast. Work on making progress — the change will take care of itself.

We can’t wait to research a solution that guarantees our desired change. We also can’t wait to validate a “known” solution. That doesn’t mean we should take a leap of faith on a loosely studied solution.

Instead we can immediately get to work in ways that make progress. It doesn’t have to cause a big change, just make a little progress. We can make it small. We can measure a response. We can amplify if it works. We can dampen if it doesn’t work. We can make bigger bets as we get more feedback.

We many not see a beneficial change for some time, but if we’re seeing the right kind of progress we can assume we’re on the right track. We can explore. We can experiment. We can learn.

We don’t need a holistic solution to start. We just need to know what kind of progress to make and signs of success.

So write a good objective and get to work.