Good Goals

Why we set goals

What good goals look like

  • 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.
  • 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.
  • 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.)
  • 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
  • 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?

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?

  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.

--

--

--

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

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Three​ reasons why the valuation of employees matter

A small talk on meaningful leadership

Project Josh: Ensuring The Well-Being of Our Employees

Developers think managers don’t know enough about technology. And that’s hurting business.

1999–2019: Twenty Years of My Lessons as CEO

What is EI (Emotional Intelligence)

The Role of Communication in Crisis Management

Trust — A key Leadership Skills!

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

Michael Siliski

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

More from Medium

Top Myths of Product Management

Two Strategies to Facilitate Decision Making In Product Development

Prioritizing at different levels on a software-based product.

Essential skills for aligning stakeholders every time