Let’s talk about input goals vs output goals, and how you can use input goals to be more effective.

Definitions

Output goals are goals of a desired end result, i.e. the thing that you want. Output goals are more common as they represent the material outcome of your effort.

Input goals are goals on input effort or action. Think: Number of hours of doing an activity, or number of times doing an activity. Input effort without a material output is usually meaningless (besides the learning experience), but defining input goals can still be useful.

Using input goals to fight procrastination

Define an input goal based on a short number of hours of effort. E.g. By end of day, I will spend 4 hours drafting a design document; or I will spend 2 hours on chores then relax without feeling guilty. Give yourself permission to not have to complete the entire body of work and define a checkpoint you will be happy with. It sounds obvious, but procrastination often comes holding the entire mental effort in your head at one time, even though that’s never how work gets done. Using incremental time-based input goals is a great way to get started on something.

Using input goals to deal with ambiguity

If you’re working in a space that has many unknowns, and you don’t know if an output goal is realistic, defining an input goal can be helpful to get started. Again, give yourself permission to not fully know how to do something and learn along the way. One input goal I’ve taken recently is to spend 30 minutes a week writing for this blog, since my previous output goal of 1 blog post per month felt intimidating and I kept spending time drafting without posting anything.

For example, if you want to improve latency for your end users, it might be hard to define an output goal as there are many factors at play like differing user cohorts, user traffic patterns, warm/cold caches, undiscovered bottlenecks, networking topology; all of which can affect users and and features differently at different latency percentiles. One strategy you could consider is taking an input goal on completing N number of projects that improve latency in different ways, hoping that the cumulative result of the projects drives your output in the right direction. It’s not wrong to take a bold output goal that you’re not yet sure how to achieve, and this strategy depends on your org’s ability to identify the right opportunities for latency improvement, but it’s a strategy to consider.

Using input goals to focus on what’s within your control

If a problem space has many factors that are out of your control, it may feel demotivating to work towards an output goal. You can re-motivate yourself with an input goal that is within your control to complete. For example, if you’re working on a feature with highly volatile product requirements, you can take an input goal to have high quality tests to enable you to pivot and refactor your code in the face of later changes.

Another example is you may want to lose weight (an output goal), but that can be somewhat dependent on your body’s metabolism and biochemistry, so it might feel more motivating to take input goals on exercising 5 times a week or eliminating snacks outside of meal time.

Input goals are a tool

Input goals are a tool that may help you stay motivated and productive. Keep an eye out, you may already be using input goals on a regular basis, you may just not know it by that name. Hopefully this is a useful view in understanding your efforts in a different lens.

That being said, input goals are just a means to an end. You should always be able to tie your input goal into the bigger picture output goal that you’re working towards.

Related reading: SMART goals https://en.wikipedia.org/wiki/SMART_criteria