Frameworks

Mission, Customer, Metrics

Apply this framework to any task or project you are doing

• Mission: What is the number one goal you are trying to achieve?
• Customer: Which customer are you serving to achieve this mission?
  • Your customer doesn't necessarily mean a Fig user e.g.
    • if you are building an internal tool, your customer is your teammate
    • if you are building an integration with iTerm to the Fig macOS your customer is the engineering team in charge of the macOS app
    • if you are writing onboarding docs, your customer are your new teammates
• Metric: What metric can we use to assess how good of a job you are doing to achieve your mission for your customer?
  • If your metric is as high as it can possibly be, your customer should be insanely happy about your performance in that particular mission
  • You should be able to measure your metric and plot changes over time e.g. if a quantitative metric like "user love" or "happiness", survey your customer (e.g. NPS) or talk to them and ask them a set of objective questions.
  • When deciding on a metric, don't worry at first about about if it's quantifiable or not. It usually is quantifiable. You shouldn't choose the wrong metric just because it's easy to measure.

Having one single mission for each task / team you manage allows you to focus on doing one thing unbelievably well.

90/10 Rule

Is there a way to do 10% of the work for 90% of the solution? Most often, yes. This rule allows you to test hypotheses quickly. Building a new product? Rather than build it, speak to users. Manually do the work for them. Verify if it helped or not. When Doordash first started they had a simple website that listed 5 menus + a phone number. Users would call to order food. When they started getting too many calls, they started building functionality to make orders easier. A simple website was 10% of the work and it allowed them to spend all their time validating that food delivery was something people wanted.

Problem vs Solution vs Job to be done

Look at the writup in principles

Hair on fire problems

If your hair is on fire, the only thing you are worried about is putting the fire out. At that point in time, nothing else in the world matters, just putting that fire out. It is such a big problem that you are willing to try anything. If someone gave you milk, you'd pour it on your head. Apple juice? You bet that's going on your head. A towel? Sure, i guess it works. Obviously the optimal solution here is water or some sort of fire extinguisher. But the problem is so bad **you are literally willing to do anything. **

Hair on fire problems are the best problems to solve. As we just proved above, it doesn't matter how bad the solution someone presents is, you are willing to use it. Let's apply this to business

The best problems to solve are these hair on fire problems. You can generally find such a problem when

• Someone's life depends on a solution
• Someone getting fired from their job depends on a solution
• Someone has actively tried a bunch of other solutions for a problem and none of them work

Brendan Prioritisation Framework

Let's say you have 10 tasks to be done. You have the capacity to do 4 full tasks in a week. Task 1 is top priority. Task 10 is lowest priority. However, you don't know the exact priority. Rather, you think the priority order is 1, 2, 4, 5, 3, 6, 8, 7, 10, 9.

There are three ways to approach this:

1. Spend time getting the rank order exactly correct
   1. In practice, you probably still won't get this right AND you end up wasting a lot of time.
2. Try and work on a bunch of the tasks at the same time
   1. In practice, working on too many things becomes overwhelming. In 1 week, rather than getting 50% of 8 tasks done, you probably average about 30-40% of each 8 tasks and you never end up completing any of them.
3. Commit to 4 tasks and get them done
   1. This is the optimal strategy. Although you end up doing the tasks in the wrong order, after two weeks, you will actually have tasks 1-8 done. These are our top priority tasks for the two weeks. You don't get it right the first week, but you correct in the second. And you get everything done.

Prioritisation is good up to a point, but when you are wasting substantial time trying to prioritise, you end up falling behind. As outlined in our Principles, if you have ~70% confidence in something, do it. You will probably be wrong, just correct your mistakes quickly.

Automate when it's painful

It's very easy to think you know what you need to do and therefore think you shouldd automate it from the get go. As discussed above, you are often very wrong. Have a hypothesis, do 10% of the work, and move on. When you start doing the same thing over and over to the point where it's painful, then you know exactly what you need to automate. It turns out, this method is much more fruitful than trying to predict your needs.