The surprisingly simple science of goal setting

Ankit Arora

A lot has been said about how to track goals. And the business world is full of jargons like KPIs, OKRs, KRAs, SMART .. but how do you identify which goals to go after? No one can spoon-feed you that. You have to go through that journey yourself. And it’s scary to decide what to prioritise and what to give up. Who should own it and when.

Most of us suffer from a bias-of-action & do-something-syndrome (I was really bad at this till 2016, only got better recently). But a little bit of planning never hurt anybody. Now I take my time to go through this checklist every few months ..

Making the right decision is 100x more impactful than execution. If you are going after the wrong goal, no amount of talent & hard work can give you great results.

Build a manifesto

This is your team’s guiding light to remind you what works for you; and what you believe in.

via Divinations & Hiten Shah

The image above is a great way to think about your company’s strategy. If you merge your mental models and values with the frameworks; you get good goals as an output. When we at Kaapi decided to launch Kaapi for remote leaders over Slack first, this is how the diagram looked for us:

  • Inputs = we researched a lot to see which industries are generating sustainable growth + the market forces were trending up for remote work
  • Frameworks = we had to ship fast + we are bootstrapped hence couldn’t try to build a new category (Blue ocean vs red ocean) + must be SaaS + focused on under served persona
  • Output = build remote HR tools for remote managers while sitting on top of Slack, Microsoft Teams etc

Avoid stupidity vs seeking brilliance

"All I Want To Know Is Where I'm Going To Die So I'll Never Go There: Buffett & Munger"

Sounds obvious right? But easier said than done. I can’t even count the number of times I have run after the shiny things vs catching the lower hanging fruits first. And while I was busy being the hero and slaying dragons, my company died silently behind me.

A good way to get started is to make a list of things that will kill you, and then remove those first. Or simply, just do a post-mortem in advance.

The last time I did this exercise, I realised that the kind of things that can kill your business are rather silly, but all avoidable ⚡️If we are really building this company slow and steady, for the next 5 years minimum and possibly for the rest of our lives, then we get 10x more impact by removing obvious obstacles and de-risking.

Take a project, transport yourself 6 months in the future, and then imagine why that project has failed. When you have a list of reasons, solve for all of them today.

Non-stretch goals, with 20% buffer

My 2015 self would have absolutely hated me saying this. I used to believe in shooting for the moon every quarter. Stretch your ambitions and plans to the limit. But no more. When was the last time any of us was happy with what we achieved that quarter? Do you remember that fleeting feeling? 🤔

Plan well, spend 80% time sharpening the axe, and then execute well. Then go home. Constantly not hitting our goals can only lead to two things:

  • Goals stop being important in our eyes
  • Fatigue and constant feeling of failing. Burn out is never good. Especially since we want to play a long term game here

If you are an early stage team, you will anyways face roadblocks that are sure to derail you. After all, you are creating something beautiful from scratch. Don’t fuck up the whole thing by aiming for something that can never be done. Then why even plan at all? If you are scared that your team will sit empty with no work for 20% of the month; you need to solve those trust issues first.

Focus on Z metric, not X, Y

Let’s talk a bit about metrics to measure success and failure. It’s pretty simple, but so many of us suck at this (including me, many times). Focus on the outcomes, not the inputs. E.g. If I was a salesperson, this is how I would plan my work:

x+y = z (input, output metrics)(x) 10 email reachouts a day + (y) 3 phone calls from that a day = (z) 1 deal closed per week

Almost everyone can plan their work in this way, even a data scientist (to some degree). Goals are z, and the updates you give on daily standup are x, y.


Don’t go overboard with this approach. You can not invent metrics like x bugs squashed per day. That will just invite gaming the system.

Cut scope. Keep budget and timelines same

This is where ambition comes in. Want to build a rocket to the moon? Let’s go! But you only have one month, and 1000$ to do it, the same as before. So now you have to the most beautiful kick ass backyard toy rocket with AI controlled boosters that can land the rocket on its return path.

The fine people at Basecamp explain this way better than me, so I would recommend you read this article.

Be aware of Chesterton's fence

During the goal planning exercise, you will make a lot of decisions. But try to analyse and figure out every second and third order effect of your decisions. Asking the 5 whys helps.

The final goal should be a story

People want to play a small part in the larger theater. They don’t want to be reduced to numbers. They want a role. tAt the end of the exercise this is how individual goals should sound like.

This month, I am a GTM Guru. My goal is to finalise one USP, and three distribution channels that can give us 20% cheaper growth in new markets.
Hi! In May, I am the Onboarding Champion. I am on a sprint to finish all features required for a great Dx until they create the first app. We have a list of 18 tasks, which should get done in 3 weeks.
We are Kaapi → Employee feedback tool over Slack. In June, we want to onboard 20 new customers, and get our first paying customer.

A small caveat

There is no way that this checklist is one size fits all. This works for us. And I am pretty sure that mostly all of these points apply in all situations to you. You can add / remove some steps from the checklist.

The 1% better newsletter

Actionable guides on remote work, leadership & lifestyle design.
No spam, ever.

Read more

We (finally) analysed our product usage. This is what we learnt.

As a product team, you don't know your customers as much as you think you do

Read Story

I self-learned to code at 30. And so can you.

You can build your first software project in just 234 hours of practice.

Read Story