Good Goals

Having led goal-setting processes with teams of 1 to 500 people, at all stages of product maturity, I find I get more or less the same questions, and the same pushback, every time. This is my answer to those questions. While you can easily find lots of tactical advice online about goal-setting processes, here I want to focus on the spirit of what we’re actually trying to achieve and how to know if we’ve done it well. To that end, this post covers: (1) why set goals, (2) what good goals look like, (3) heuristics for testing your goals, (4) FAQ.

Why we set goals

Define success. Goals are statements about successful end states: what are you trying to do, and how would you know if you did it? Plans are sets of activities. Executing on a plan may help you achieve a goal, but it’s not itself the goal. To maximize your odds of achieving a successful outcome, start with the end in mind and work back to the activities most likely to get you there.

Focus. There are always far more reasonable things we could be doing than we have capacity for. Productive teams clearly distinguish the most important things from all the other good ideas, and they relentlessly focus on those top priorities. This also helps ensure all the different parts of the team are operating in concert, rather than independently working on related things.

Allow for autonomy. Aligning around and committing to a shared definition of success creates accountability. Doing it without mandating specific activities allows that accountability to coexist with autonomy and creativity.

What good goals look like

Focused, concise, and comprehensible

  • Everyone on the team should be able to easily memorize the team’s goals. This is important, since the progress you make in a quarter or a year is the result of thousands of independent decisions. Too many goals, or too many details, interferes with this. People can remember about 3–5 things.
  • Focus on the most important things. Your goals should help you identify and avoid the distractions.
  • Use plain English, easily understandable to anyone with a passing familiarity with your team’s strategy. This helps with strategic clarity, memorability, and communicability. Jargon often masks strategic gaps.

Objectively assessable

  • Everyone on the team should have the same understanding of what success looks like and what it doesn’t. Goals don’t need to be quantitative, but they cannot be subjective.

Challenging but possible

  • Your goals needs to be credible. If people consider the outcome unimaginable, they’ll simply ignore it and give up.
  • Your goals should also stretch the team, inspiring and challenging people. If you ask your team to stretch, you’ll often discover it finds ways to deliver more than you expect.
  • A good rule of thumb is to shoot for about a 70% success rate. (However, some goals may be considered a stretch, and some may be considered a must hit—be explicit if so.)

User oriented

  • Never organize team goals by function (Engineering, etc.). Success depends on all team functions coming together to deliver great products, and a single set of goals helps force alignment of efforts. Even if some goals presumably depend more on one function than another, allow for the team to flexibly organize its capabilities and solve problems creatively.
  • Don’t organize goals around features you’re delivering. Thinking about your expected activities and working forwards is likely to leave gaps.
  • Instead, focus on the customer problem you’re solving, and set your goals as close to the customer as possible

States not activities

  • If you detail specific activities to pursue, you’re removing the opportunity for teams to solve problems autonomously, creatively, and iteratively. Instead, focus on the outcome you want. How would you describe the state of the world in a success case?
  • Define these outcomes as precisely as possible. Sensitivity: your goals should allow for the outcomes that you would consider success. Specificity: your goals should rule out unsuccessful outcomes.

Testing your goals against these guidelines

  1. Does your goal start with a verb (launch, build, refactor, etc.)? You probably have an action, so reframe it to describe the outcome you want. Often this takes the form of translating “X so that Y” into “Y via X” (and consider if you need X in there at all). A helpful trick to figuring out the proper framing is to read the goal out, ask yourself “why?,” answer that question, and then do that a couple of times until the true goal comes into focus. For example:
    • Refactor backend → Backend supports 5+ teams concurrently adding features
    • Launch v2 product → Double conversion rate via new payment integrations
    • Add infinite scrolling to search→ X% of search queries receive result clicks
  2. Do you have “engineering goals” and “business goals” or similar? STOP IT.
  3. Are your goals more than one page, more than 3–5 objectives, or more than 3–5 KRs per objective? No one will read, let alone remember, them.
  4. When you (or your team) look at your goals, do you wince and think “what about X? I was really hoping to get to that this quarter.” If not, you probably haven’t focused enough, and your goals are not adding value.
  5. Could one team member think a goal is achieved and another one completely disagree? Then your goal isn’t specific enough. (By contrast, if everyone feels it’s mostly successful but the assessments range from 60% to 80% done, who cares?) Look for wishy washy qualifiers like “better” or “delightful”—How much better? How do we know if it’s easy or not?
  6. Can you imagine a scenario where the goal is achieved but you’re still dissatisfied with where you ended up? Then your goal isn’t specific enough, or an aspect is missing.
  7. Could you be successful without achieving the goal? Then your goal is overly specific, and you should rethink how to define success.

FAQ

Where do the goals come from?

What process do you use to set the goals?

  1. Think about what you consider the most important things to accomplish in the time period. If you know what your strategy is, this should be straightforward (less than an hour).
  2. Ruthlessly limit this list to the top 1–5 priorities
  3. Talk about this list with your team, as a casual conversation of priorities. Know what you think, but be open to alternatives. Ask them if they have other ideas. Give them a few days to talk with other people outside the room. Gather the results back into a shared list of priorities.
  4. Phrase your priorities as descriptions of the state of the world at the end of the time period
  5. Simplify by removing any redundancy, unnecessary phrases, jargon, etc.
  6. Ask yourself if you could actually be happy even if these statements didn’t come true, or if you could actually be unhappy even if these statements came true. Iterate until false.
  7. Assign each item named owners. Ensure explicit commitment from the owners that it’s the right goal and they plan to deliver on it. If you sense hesitancy, talk in person to resolve it.

What tools do you use for capturing & tracking goals?

What if your team is too big to have such a concise set of goals?

How do you manage against the goals?

How do you score goals?

What do you do if the goal changes before the time period ends?

How aggressive should the goals be?

What about quantifiable measurability?

However, sometimes people get hung up on enforcing quantifiability and can lose track of what really matters. It’s fine for some goals to have no numbers, as long as it’s clear what success looks like, not a subjective question. A goal like “MVP is up and running on production hardware and multiple external companies have tested it and provided early feedback” has no numbers, but it’s very concrete. The important thing is that the whole team assesses success and failure the same way. As Andy Grove said about goal assessment, the important thing is that “at the end, you can look without any argument and say ‘Did I do that, or did I not do that?’ Yes. No. Simple.”

What if I can’t measure the thing I want to optimize?

What if I have a metric, but I don’t know what the right target is?

What if you can’t agree on what the goals should be?

Here are some common issues people get hung up on. Work from the top down until you find the place you fall out of alignment, and work through that question while holding everything else to the side. Then continue down one step at a time.

  1. Different assumptions about vision or strategy. If we aren’t aligned on what we’re trying to do as a team, there’s no effective way to figure out the milestones along the way.
  2. Different assumptions about priorities. Similarly, if you think that we should do A first, then B, and I think we should do B first, then A, we can’t align around goals.
  3. Different interpretations. Tease this out by talking through concrete scenarios and seeing if you agree on what success is and what it isn’t.
  4. Incomplete success statements. If your goals don’t capture something important for success, you may see people trying to pull things up a level into very broad statements. Try adding additional, very specific statements to narrow down the range of good outcomes until you’re on the same page, then simplify as appropriate.
  5. Different assumptions about feasibility. If someone feels the goal is fundamentally not possible, or cost-prohibitive, it’s good to name this explicitly and dig into it.
  6. Different assumptions about capacity. Try expanding the timeframe a bit and see if you all agree on the overall plan, and are simply disagreeing on how far we should get in a specific time period.

Why “goals” and not “OKRs”?

  1. Where do I want to go? This answer provides the objective.
  2. How will I pace myself to see if I am getting there? This answer provides the milestones, or key results.

However, lots of people have PTSD with OKRs, since you can use the same structure and break all of the rules discussed here. Many OKR processes devolve into detailed activity planning. My concern isn’t with the framework, it’s with defining good goals. So I just use the term “goals” in this document, since most people agree that goal setting is worth it (but not everyone!).

--

--

products, software, data, cities, housing, mobility, San Francisco, Boston sports, minds, music, coffee, spirits, funny stuff, beautiful stuff, amazing stuff

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Siliski

products, software, data, cities, housing, mobility, San Francisco, Boston sports, minds, music, coffee, spirits, funny stuff, beautiful stuff, amazing stuff