I think it’s much easier to think about the framework you should apply when thinking about your goals and purpose than to actually come up with the purpose. I’ll attempt to provide the framework I came up with. A nice thing about the framework is that it should be independent of one’s values, goals, and purpose — there may still be multiple different frameworks but they should be equivalent; modulo perhaps some things they are trying to optimize for (some framework may try to help you come up with a design more efficiently than some other, for example).
At the most fundamental level, this framework will help us answer a very simple question: “What should I be doing right now?”. We all ask ourselves this question many times (or wish to, but don’t): “Should I be working at my current job or not?”, “Should I buy a house?”, “Perhaps I should be helping poor children in third-world countries…”. We make some decisions but often we’re not sure whether our reasoning for our choices is correct. Ultimately, then, this will be the framework to guide us in making decisions in life.
Let’s start with goals because I think a lot of people viscerally understand what goals are. Goals are not the most concrete item but also not the most abstract (i.e. they influence other things in our life (for example, our actions), but are also shaped by other things), so we’ll have to explore goals in two directions — down (to the more concrete) and up (to the more abstract).
You may have been taught that goals should be SMART — specific, measurable, attainable, realistic, and timely. I’d actually simplify this mnemonic a little and say that a goal needs just one thing: to be measurable (i.e. you have to know when you’ve achieved it). For now I’ll assume that you already have a goal in mind that is measurable. Most likely it doesn’t have a timeline attached to it, and you’re not even sure if you can achieve it (other than a visceral feeling you have). This is fine, we’ll handle all these problems shortly.
The next step is to come up with a way to achieve that goal, a design. This is where art comes in. There is no formula for coming up with great designs. There are some properties that great designs have, however, and your design should also exhibit these properties:
- A good design is not sensitive to small changes in the inputs: if you miss some deadline, or if you catch a cold, a good design should be able to withstand it
- A good design anticipates any problems you may run into when trying to satisfy your goal
- A good design can be iterated upon so that it can be fine-tuned and altered
- A good design is modular — it consists of a list of subgoals that connect logically
You should be able to prove that your design satisfies your goal. This is usually hard, which is why having a modular design is a good idea — you should be able to prove at a high level why achieving subgoals X, Y and Z will achieve your goal G. We’ve just replaced our goal with three subgoals and a thin layer of “proof” connecting them all. Each subgoal needs a design, so yes, it may seem like there is much more work to be done, but these subgoals X, Y and Z are now most likely easier to measure (perhaps instead of a binary — “Have I achieved this goal?” — you can come up with a continuous — “How much of this goal have I achieved?” — measure). They may also be more timely (it’s good to get early feedback and if all you have is a binary goal and five years to achieve it, you are risking a big waste of time!) and specific, and, most importantly, they feel much more attainable (because they require less work to fulfill). And so as you come up with your tree of goals, the lower you get, the more SMART each goal gets. Ultimately, then, to fulfill your goal you just need to fulfill each of the “leaf” subgoals (and make sure that your logic for connecting subgoals is correct at each level). If at any point you are unable to come up with a design, you have an unrealistic or unattainable goal and you should alter your design.
Now that you have a design you can start executing on it. But you won’t get perfectly lucky — problems will arise that appear as outcomes in conflict with the outcomes you expected. A very smart man Ray (usually I fake out the initials but I hope he won’t mind me unanonymizing him) taught me a way to use these outcomes to refine the design (in fact, I owe my inspiration for coming up with my framework to him). The idea is simple: observe the outcomes, compare them to the outcomes you expect based on your design, and if the outcomes are in conflict, you have a problem. You can work around the problem, or solve it superficially, but the most effective thing to do is to alter your design based on fundamental, root causes of the problem. For example, if you’re a poor driver and keep smashing into walls, the solution is not to buy you a stronger car; it’s to improve your driving skills. If you alter your design according to the superficial causes, you are likely to encounter more problems that are due to the same fundamental cause.
In fact, in a robust design, you can anticipate all problems, diagnose them and change your design even before you started executing on it!
As you achieve your subgoals, you should make sure that your higher-level design is still correct by re-evaluating whether achieving your subgoals leads to a fulfillment of the overarching goal. It’s possible that your “proof” was weak and you didn’t take into account some inputs that have changed since you originally came up with your design. Or it was insufficient and you actually need to fulfill more than the subgoals you originally came up with.
Hence, assuming you know your goals already, you should be able to successfully execute upon them with a help of a simple design.
Now, to the much more interesting question: how do you come up with your goals?