1) Make two lists. Write everything down in the first list. The second list is empty.
2) Something came up! One item on this list cannot be done. It doesn't matter why: you know which one that is. Which one is it? Write that down in the second list and mark it off the first list.
3) Repeat until the first list is done.
Congratulations, your second list is prioritized (albeit likely in reverse order), without extraneous algebraic diversions.
Bonus points for going Warren Buffett on it: only the top 3 priorities matter, sideline everything else; consider repeating the exercise after those three are complete.
Thanks for this. It's interesting because it's super close to another method: Write down everything, put the most important thing at the top of a list, next important next, go till done. That's maybe the most naive method possible and essentially shouldn't count as advice for "how to prioritize".
But, maybe the fact that you're going from least to most important makes it materially easier. It's functionally different because you're picking out the least important stuff when the list of unchosen items is big and the most important stuff when the list is small. I can see how this would help a lot.
“put the most important thing at the top of a list, next important next” you realize you’re basically saying “the trick to prioritizing is you have to prioritize” right? The idea behind all of these systems is to help people figure out what is actually important.
The link suggests replacing your intuition with how important a task is with your intuition about 3 different aspects of the task. Which has a similar problem.
The real trick to prioritization is to have enough capacity.
Capacity informs how well/fast you can execute through your priorities, which can sometimes mean that you should reprioritize according to your available throughput (“Capacity says we’ll have this 10th thing next year, we need it this year, let’s reprioritize). But unless you have specific time horizons for your wants/needs, capacity and priorities aren’t as related as most people think.
You should prioritize the things that will have the highest impact to your customers or your business. That could be:
- a mission critical infrastructure change
- a small bug that is driving people nuts
- a differentiating new feature
- a whole new product that will take a long time to build
Good prioritization facts in multiple criteria. Bad (most common) prioritization is a function of loudest voices yelling.
Approaching it from "least to most" circumvents the problem of rationalizing and justifying. We get caught up in that when we're looking for "most important" or "what to do", but we already know what's got to come off the bottom of the list, without even having to explain it.
It also helps mitigate our fear avoidance strategies (ex: (a|b|c) - (x|y|z) + (w|t|f), Einsenhower quadrants, and so on) because there's just no room for it. Something has to go. What? Okay. Next.
This is genius! It's like getting the benefits of procrastination without actually procrastinating.
This seems to me that this would work best for deciding what to do within a fixed timeframe. How can this be adapted for things of varying time frames? Certain things don't need to be done today on any given day, but if months go by and i haven't done them, it's bad.
I like this idea, but isn’t this a recipe for only ever doing the urgent stuff, not the not-urgent-but-important stuff? For example, if your list had “read 1 chapter of SICP” on it, you might never get to it.
Most tasks on most task lists are not tasks - they are wishes or outcomes
Prioritising outcomes is easy. Do we get five new corporate customers this month or do we build a web scaling system on AWS.
One is a task, one is an unknown project with no clear definitions or starting process. Which is why many startups have great infrastructure and not enough customers.
So, unless you know which right people to put in a room, the thing in front of you is not a task it's an investigation.
And to me this answers the question a few days back about sam altmann - determination is what gets you from "get five customers" to "call bob smith of company X after Joe Schmoe introduces us and offer him a 12 month for price of 6 deal if they sign this week"
Determination is of course made easier with contacts but politicians will politician
> One is a task, one is an unknown project with no clear definitions or starting process. Which is why many startups have great infrastructure and not enough customers.
It's interesting that I worked with a company that had a strong sales department but a weak (or non existent?) IT department. Getting five new corporate customers was a task for them. But setting up an AWS EC2 instance with an RDS server? That was an investigation that is requiring a trip to Singapore.
Instead of maximizing “benefit - cost” I would recommend maximizing “cost/benefit”.
The former will bias towards big tasks with big payoffs, but often there are small tasks with extremely good ROI, which will get lost if you just look at the magnitude of the net benefit.
But, +1 to the general approach of trying to put a number on it. Remember though, your numbers are uncertain, beware the McNamara fallacy.
I've found it more useful to focus on "How to deprioritize tasks?" There, it's helpful to have a good understanding of the operative principles and values. All sorts of possible to-do items come up that only kinda sorta express those values. Those are the enemy. You have to get good at the logic of necessity and sufficiency to recognize which ones you can ignore entirely.
> Sorting a “Big List” of epics doesn’t seem like the right way .. The first problem is that you’re sorting things that are incomparable .. The second problem is that the resulting decision is unsatisfying to [all] stakeholders .. The third problem is that The Big List conflates the idea of “prioritization”—what is most important—with “work-planning”—which is the order that specific work will be executed ... The solution is to prioritize items in separate, actually-comparable streams ... Don't forget to schedule rocks, then pebbles, then sand. That’s an even more primary principle for work-planning. Separate prioritization streams help identify which rocks and pebbles should be scheduled in the first place.
Do people really have this hard of a time deciding what task to do? If you have something that needs doing urgently, then do that. Otherwise... it just depends? There's no one-size-fits-all solution.
I have seen teams spending most of their time on working on the highest priority (by a single measure) and not spending any time on overall delivery efficiency.
So having a balanced prioritisation approach would seem to be pretty important.
Sometimes the exercise of explicitly trying to quantify and compare urgency, importance, and cost helps you develop a better understanding of the project, which leads to a better work plan.
It is a very complex function which takes into account all your previous experiences, your value system and your estimations regarding the future.
Good news though! Your brain already computed it, and presents you the answer in the form of "I want to do that thing right now".
Quick debug sheet:
- my brain in wrong, what I want is not what I should - are you sure? Figure out your narration. If you ever have been excited about some project you know how well your "want" will align with your "should". You may be stuck in some story about yourself which you haven't updated.
- I want it all! Yeah you are really still just looking, if you are not sure what you want, that's not really a problem. It's fine to not want anything in particular. If you keep telling yourself you really want it all just choose at random, and then when you "have time" slowly and patiently explain yourself that your time is finite, and amount of ideas you can come up with, not necessarily.
I suggest also trusting yourself with this. Worst case scenario you spend some time doing the thing you wanted to do and observing that will be a valuable data point (automatically integrated) into your future "I want to".
edit: I answered it in the context of personal lists, startups have much simpler optimization function
It's a nice idea, but I'd like to see some examples of this in practice. One problem I see with this particular system is one of relative scale, in that your x,y,z and a,b,c and p,q,r triples all need to be somewhat-carefully tuned to remain on the same numerical order of magnitude. I wonder if a better system can be constructed that depends more on the relative rankings within each category, and less on absolute quantities.
That said, I've started using another system that a coworker recently introduced me to. He likes to model the total business value of an improvement or cost-savings as a discounted cash flow. You estimate the gain as a cash flow per period, and run that through the standard present-value formulas, either picking a discount rate out of a hat or using a range of discount rates to see how the results vary. You can then compare this to your total estimated cost (e.g. your hourly rate times the expected hours of work) to see if the thing is worth doing.
For me, I think of projects as sort of having two phases: the discovery phase and the "get it over the finish line" phase.
In the first phase, there are a ton of unknowns. You don't know what all the technical challenges are, so it's difficult to even estimate how long the project will take. As such, I think it's more important to take on tasks that have the most number of unknowns. Your goal here is to unearth any "unknown unknowns". You end up prototyping a lot at this stage to prove out ideas, and the work here will naturally generate even more tasks for you, but that's a good thing as it's better to find that out now rather than later, when you think "you're almost done" and then have to push out the schedule a ton because you find some technical limitation that would sidetrack your entire project.
Eventually, once you get through this "discovery" phase, you get to a phase where you generally know the big pieces and have a way better idea of what the big technical challenges are.
You now have a long list of tasks and how long it would take if you did absolutely everything. You won't do everything though since you don't have all the time in the world. Now you enter the "get it over the finish line" phase. I think at this point you just draw a line in the sand and say "we ship on this date" based on what you think you can ship for your MVP and given the list of tasks. You prioritize things would prevent you from getting across the finish line.
This is a pretty coarse way of looking at things, for sure, and there is a middle phase in there where you just execute through tasks based on lighting up features or demo'ing progress to stakeholders, but I think looking at it as "discovering" and "finishing" is a simpler way to ensure you're not just spinning your wheels doing tasks just because they're there.
Yeah, that's the way I look at. You de-risk a project by front-loading “investigate open questions about ___,” and then getting to the stuff that’s obviously just work that’s doable.
1. The ratio of value generated per given effort: If there are two tasks with similar value but one of them requires less effort then the one with lesser effort goes higher in priority. On the contrary if two tasks require the same effort but one of them has higher value then the one with higher value gets higher priority.
2. Time sensitivity: Certain tasks are time sensitive and should be given higher priority. Tasks can be time sensitive because they are blockers for other tasks or because they help de-risk technical or business risks and may affect the fate of other tasks going on in parallel. These are usually information generating tasks and they help reduce wasted effort on other tasks if the information is revealed early.
One makes a priority decision based on the best judgement combining the above criteria. The intent is to increase the overall value generated by the team.
I'm currently working on moving across the country, which involves a ton of small, more or less self-contained tasks that all need to be done by a set date. There is some room for prioritizing (e.g. pack this room so there is space to lay out this other stuff to sort, or order this item now so it can arrive in time to use it for the move), but the vast majority of the tasks are of equal priority and trying to sort them is a recipe for wasting time. I'm prone to wasting that time, so I've been writing up a list, throwing a random number at it, and doing whatever comes up. It is quite freeing, and made me more efficient in this time.
I have a similar methodology, and you can even use a spreadsheet to assign values across multiple factors. For example, we may use a series of 1's and 0's to represent:
Expected - Do customers expect this feature from us? (e.g. competitors)
Wow Factor - Does building this make our users go wow?
Need by Others - Is this a dependency for other items?
The more factors, the more divisive the points are, and plotting them makes it easy to understand and visualize what to go build next or where we might need more resources
Decide if something is urgent, and if it is important.
Urgent and important? Do it.
Urgent and not important? Delegate it.
Not urgent and important? Schedule it.
Not urgent and not important? Bin.
Lots of things that are urgent and important? Choose 1 thing. Do it. Then do the next one.
I read 4000 Weeks by Oliver Burkeman recently. TLDR: embrace you don't have time for it all, and if you try and optimise you'll just create more work for yourself. Get rid of as much as you can as a first step.
It definitely doesn't need maths. If it does, you're optimising for the wrong thing.
I've seen this four quadrant method frequently referenced, most recently I came across it in David Allen's book "Getting Things Done". I don't quite understand the logic behind delegating non-urgent and important work. Two points of confusion:
1) In business, how do I have the authority to delegate when responsibility is frequently defined by the role/organization or I'm at the bottom of the organization?
2) Delegating urgent not important tasks seems like an ineffective use of valuable resources and a recipe for a toxic working relationship. Rather, I would expect someone to delegate not urgent important work so that there is time to deal with the additional cost of handing off work to another person.
For 1), I suspect once you figure out you can just start asking your co-workers to do your stuff, you reach first level of enlightenment and transition from $jobtitle into senior $jobtitle.
For 2), the point is to throw the task - and responsibility for completing it - over the wall. That's why it's prescribed for Urgent and Not Important work: urgency is satisfied by you delegating quickly, and if your victim screws up and fails the task, well, no big deal - the task wasn't important anyway.
All that to say: yeah, I can't see a way this isn't abusive and antisocial, unless done in business context with clear rules, such as hiring people specifically for you to delegate work to them.
Worth remembering that priority and sequence are not quite the same thing.
There's a useful framework called RICE where you evaluate/score ideas by Reach, Impact, Confidence, and Effort. Sometimes assigning numeric values feels forced so I often use it as "dimensions to be thinking about" rather than a literal scoring system. [1]
There's some great stuff in Reinertsen's Flow book about different sequencing strategies and when to use each. Eg, When delay costs are homogeneous, do the shortest task first. When task durations are homogeneous, do the highest cost-of-delay task first.
I tried something similar a while back. It made me feel like I was doing really we;; at prioritising my work, but it's honestly a hard thing to do well and without over-engineering prioritisation.
These days I just have a list of weekly objectives (TODOs), and a daily list of things that I'm "doing". The doing list is based mostly on gut feel about what's important right now, and is in part - based on what my team / the business feels is important right now.
All the things in the weekly objective list are always high priority / important, if it isn't, then it doesn't go on a list.
With less introspection, I’ve usually done the long list, scanning for something I either feel joy or guilt, and do that. Not that effective at work because most of the work doesn’t bring joy.
If I applied this strategy I would quickly be fired. All of the things that my management chain finds valuable are not things which are valuable to the product (mostly, planning and producing as work output JIRA tasks, spreadsheets, timetables, etc.). Actually working on things valuable to customers is seen as a necessary evil, a game we play to score the primary work output, i.e. plans.
In sideprojects that are early stage, I have a todo.txt in my repo with one line, the thing I have to focus on. I keep this thing small in scope. Once it's done I replace it with another thing that's in my head.
It works surprisingly well to keep me focused on the task at hand :)
I seems to always think of new things. Writing them down helps me forget about them and stay focused. So I end up with a much longer todo list.
But once I'm done I have lots of options to choose from. This helps me pick something that I have the energy for instead of getting stuck in 1 tangenital task after another which can feel a bit repetitive.
It's probably correct, but now the problem just moved to accurately scoring each task on a variety of scales. What I find more and more is that it's very hard to see beyond the tasks and figure out side effects of finishing some task or feature because it quickly gets very complex and if you spend time on really thinking it all through to the point where you're certain about the right order, you probably could've knocked half of the tasks out already instead of studying their relationships and long-term effects.
It's trying to leverage mathematics to make correct decisions, but missing the point that the choice of mathematical function is entirely arbitrary. There are literally an infinite number of scoring functions that take three parameters.
There's no reason why picking any one of them would give a reasonable priority of tasks, other than some mysterious mathematical astrology, while aimed to reduce the amount of intuitive guessing is composed entirely of intuitive guessing.
How to Prioritize Anything:
1) Make two lists. Write everything down in the first list. The second list is empty.
2) Something came up! One item on this list cannot be done. It doesn't matter why: you know which one that is. Which one is it? Write that down in the second list and mark it off the first list.
3) Repeat until the first list is done.
Congratulations, your second list is prioritized (albeit likely in reverse order), without extraneous algebraic diversions.
Bonus points for going Warren Buffett on it: only the top 3 priorities matter, sideline everything else; consider repeating the exercise after those three are complete.
Thanks for this. It's interesting because it's super close to another method: Write down everything, put the most important thing at the top of a list, next important next, go till done. That's maybe the most naive method possible and essentially shouldn't count as advice for "how to prioritize".
But, maybe the fact that you're going from least to most important makes it materially easier. It's functionally different because you're picking out the least important stuff when the list of unchosen items is big and the most important stuff when the list is small. I can see how this would help a lot.
“put the most important thing at the top of a list, next important next” you realize you’re basically saying “the trick to prioritizing is you have to prioritize” right? The idea behind all of these systems is to help people figure out what is actually important.
The link suggests replacing your intuition with how important a task is with your intuition about 3 different aspects of the task. Which has a similar problem.
The real trick to prioritization is to have enough capacity.
Capacity informs how well/fast you can execute through your priorities, which can sometimes mean that you should reprioritize according to your available throughput (“Capacity says we’ll have this 10th thing next year, we need it this year, let’s reprioritize). But unless you have specific time horizons for your wants/needs, capacity and priorities aren’t as related as most people think.
You should prioritize the things that will have the highest impact to your customers or your business. That could be:
- a mission critical infrastructure change - a small bug that is driving people nuts - a differentiating new feature - a whole new product that will take a long time to build
Good prioritization facts in multiple criteria. Bad (most common) prioritization is a function of loudest voices yelling.
> you realize you’re basically saying “the trick to prioritizing is you have to prioritize” right?
I'm very aware of it. The next sentence I wrote:
> That's maybe the most naive method possible and essentially shouldn't count as advice for "how to prioritize".
Approaching it from "least to most" circumvents the problem of rationalizing and justifying. We get caught up in that when we're looking for "most important" or "what to do", but we already know what's got to come off the bottom of the list, without even having to explain it.
It also helps mitigate our fear avoidance strategies (ex: (a|b|c) - (x|y|z) + (w|t|f), Einsenhower quadrants, and so on) because there's just no room for it. Something has to go. What? Okay. Next.
This is genius! It's like getting the benefits of procrastination without actually procrastinating.
This seems to me that this would work best for deciding what to do within a fixed timeframe. How can this be adapted for things of varying time frames? Certain things don't need to be done today on any given day, but if months go by and i haven't done them, it's bad.
I like this idea, but isn’t this a recipe for only ever doing the urgent stuff, not the not-urgent-but-important stuff? For example, if your list had “read 1 chapter of SICP” on it, you might never get to it.
It’s not prioritization if it doesn’t hurt.
That sounds more like you need free time where you are not "working on tasks".
I'd like to read more about this. Are there any additional resources on this prioritization method?
"Find additional resources about this prioritization method" should definitely go at the the very top of the second list.
Haha nice
The right people in the right room
Most tasks on most task lists are not tasks - they are wishes or outcomes
Prioritising outcomes is easy. Do we get five new corporate customers this month or do we build a web scaling system on AWS.
One is a task, one is an unknown project with no clear definitions or starting process. Which is why many startups have great infrastructure and not enough customers.
So, unless you know which right people to put in a room, the thing in front of you is not a task it's an investigation.
And to me this answers the question a few days back about sam altmann - determination is what gets you from "get five customers" to "call bob smith of company X after Joe Schmoe introduces us and offer him a 12 month for price of 6 deal if they sign this week"
Determination is of course made easier with contacts but politicians will politician
> One is a task, one is an unknown project with no clear definitions or starting process. Which is why many startups have great infrastructure and not enough customers.
It's interesting that I worked with a company that had a strong sales department but a weak (or non existent?) IT department. Getting five new corporate customers was a task for them. But setting up an AWS EC2 instance with an RDS server? That was an investigation that is requiring a trip to Singapore.
Instead of maximizing “benefit - cost” I would recommend maximizing “cost/benefit”.
The former will bias towards big tasks with big payoffs, but often there are small tasks with extremely good ROI, which will get lost if you just look at the magnitude of the net benefit.
But, +1 to the general approach of trying to put a number on it. Remember though, your numbers are uncertain, beware the McNamara fallacy.
I'm assuming that's accidentally inverted? Maximizing cost/benefit yields the most costly task for the least benefit.
Ha yes, ROI would be benefit/cost. Thanks!
I've found it more useful to focus on "How to deprioritize tasks?" There, it's helpful to have a good understanding of the operative principles and values. All sorts of possible to-do items come up that only kinda sorta express those values. Those are the enemy. You have to get good at the logic of necessity and sufficiency to recognize which ones you can ignore entirely.
https://longform.asmartbear.com/posts/jit-backlogs/
> Sorting a “Big List” of epics doesn’t seem like the right way .. The first problem is that you’re sorting things that are incomparable .. The second problem is that the resulting decision is unsatisfying to [all] stakeholders .. The third problem is that The Big List conflates the idea of “prioritization”—what is most important—with “work-planning”—which is the order that specific work will be executed ... The solution is to prioritize items in separate, actually-comparable streams ... Don't forget to schedule rocks, then pebbles, then sand. That’s an even more primary principle for work-planning. Separate prioritization streams help identify which rocks and pebbles should be scheduled in the first place.
Do people really have this hard of a time deciding what task to do? If you have something that needs doing urgently, then do that. Otherwise... it just depends? There's no one-size-fits-all solution.
This might work when working at large companies, but when running my own startup the problem is the urgent tasks will smother the important ones.
I've long thought that the single hardest problem in startups is prioritization: figuring out the most important thing to build (or do) next.
Strongly agree with this.
One thing I realised is, startups should spend more time optimising the decision of their top priority, and less time optimising efficiency.
There's no point working on the wrong thing with 100% efficiency.
I have seen teams spending most of their time on working on the highest priority (by a single measure) and not spending any time on overall delivery efficiency.
So having a balanced prioritisation approach would seem to be pretty important.
Agree to this. My personal thesis is paying the cost of doing it quickly is not payed months in a nebulous future, but often mere _hours_
A good bit of literature is starting to dispel the notion of the iron triangle, speed is quality, quality is speed.
It also is that while building new product often there is no single thing that is urgent but everything needs to be done.
Sometimes the exercise of explicitly trying to quantify and compare urgency, importance, and cost helps you develop a better understanding of the project, which leads to a better work plan.
Good question! Do you have a personal strategy for deciding which task to prioritize, if any?
It is a very complex function which takes into account all your previous experiences, your value system and your estimations regarding the future.
Good news though! Your brain already computed it, and presents you the answer in the form of "I want to do that thing right now".
Quick debug sheet:
- my brain in wrong, what I want is not what I should - are you sure? Figure out your narration. If you ever have been excited about some project you know how well your "want" will align with your "should". You may be stuck in some story about yourself which you haven't updated.
- I want it all! Yeah you are really still just looking, if you are not sure what you want, that's not really a problem. It's fine to not want anything in particular. If you keep telling yourself you really want it all just choose at random, and then when you "have time" slowly and patiently explain yourself that your time is finite, and amount of ideas you can come up with, not necessarily.
I suggest also trusting yourself with this. Worst case scenario you spend some time doing the thing you wanted to do and observing that will be a valuable data point (automatically integrated) into your future "I want to".
edit: I answered it in the context of personal lists, startups have much simpler optimization function
It's a nice idea, but I'd like to see some examples of this in practice. One problem I see with this particular system is one of relative scale, in that your x,y,z and a,b,c and p,q,r triples all need to be somewhat-carefully tuned to remain on the same numerical order of magnitude. I wonder if a better system can be constructed that depends more on the relative rankings within each category, and less on absolute quantities.
That said, I've started using another system that a coworker recently introduced me to. He likes to model the total business value of an improvement or cost-savings as a discounted cash flow. You estimate the gain as a cash flow per period, and run that through the standard present-value formulas, either picking a discount rate out of a hat or using a range of discount rates to see how the results vary. You can then compare this to your total estimated cost (e.g. your hourly rate times the expected hours of work) to see if the thing is worth doing.
For me, I think of projects as sort of having two phases: the discovery phase and the "get it over the finish line" phase.
In the first phase, there are a ton of unknowns. You don't know what all the technical challenges are, so it's difficult to even estimate how long the project will take. As such, I think it's more important to take on tasks that have the most number of unknowns. Your goal here is to unearth any "unknown unknowns". You end up prototyping a lot at this stage to prove out ideas, and the work here will naturally generate even more tasks for you, but that's a good thing as it's better to find that out now rather than later, when you think "you're almost done" and then have to push out the schedule a ton because you find some technical limitation that would sidetrack your entire project.
Eventually, once you get through this "discovery" phase, you get to a phase where you generally know the big pieces and have a way better idea of what the big technical challenges are.
You now have a long list of tasks and how long it would take if you did absolutely everything. You won't do everything though since you don't have all the time in the world. Now you enter the "get it over the finish line" phase. I think at this point you just draw a line in the sand and say "we ship on this date" based on what you think you can ship for your MVP and given the list of tasks. You prioritize things would prevent you from getting across the finish line.
This is a pretty coarse way of looking at things, for sure, and there is a middle phase in there where you just execute through tasks based on lighting up features or demo'ing progress to stakeholders, but I think looking at it as "discovering" and "finishing" is a simpler way to ensure you're not just spinning your wheels doing tasks just because they're there.
You can read more about this way of thinking in 37signals' book Shape Up:
https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-h...
Thanks for the link! It's good to know my personal observations about projects is shared by others. I'll have to read that book.
Yeah, that's the way I look at. You de-risk a project by front-loading “investigate open questions about ___,” and then getting to the stuff that’s obviously just work that’s doable.
From the way of work document at FluxNinja[0]:
Task priorities are decided based on two factors:
1. The ratio of value generated per given effort: If there are two tasks with similar value but one of them requires less effort then the one with lesser effort goes higher in priority. On the contrary if two tasks require the same effort but one of them has higher value then the one with higher value gets higher priority.
2. Time sensitivity: Certain tasks are time sensitive and should be given higher priority. Tasks can be time sensitive because they are blockers for other tasks or because they help de-risk technical or business risks and may affect the fate of other tasks going on in parallel. These are usually information generating tasks and they help reduce wasted effort on other tasks if the information is revealed early.
One makes a priority decision based on the best judgement combining the above criteria. The intent is to increase the overall value generated by the team.
[0]: fluxninja.com
I'm currently working on moving across the country, which involves a ton of small, more or less self-contained tasks that all need to be done by a set date. There is some room for prioritizing (e.g. pack this room so there is space to lay out this other stuff to sort, or order this item now so it can arrive in time to use it for the move), but the vast majority of the tasks are of equal priority and trying to sort them is a recipe for wasting time. I'm prone to wasting that time, so I've been writing up a list, throwing a random number at it, and doing whatever comes up. It is quite freeing, and made me more efficient in this time.
I have a similar methodology, and you can even use a spreadsheet to assign values across multiple factors. For example, we may use a series of 1's and 0's to represent:
Expected - Do customers expect this feature from us? (e.g. competitors) Wow Factor - Does building this make our users go wow? Need by Others - Is this a dependency for other items?
The more factors, the more divisive the points are, and plotting them makes it easy to understand and visualize what to go build next or where we might need more resources
https://www.heyraviteja.com/post/calculate-feature/
Eisenhower method is all you need.
Decide if something is urgent, and if it is important.
Urgent and important? Do it.
Urgent and not important? Delegate it.
Not urgent and important? Schedule it.
Not urgent and not important? Bin.
Lots of things that are urgent and important? Choose 1 thing. Do it. Then do the next one.
I read 4000 Weeks by Oliver Burkeman recently. TLDR: embrace you don't have time for it all, and if you try and optimise you'll just create more work for yourself. Get rid of as much as you can as a first step.
It definitely doesn't need maths. If it does, you're optimising for the wrong thing.
I've seen this four quadrant method frequently referenced, most recently I came across it in David Allen's book "Getting Things Done". I don't quite understand the logic behind delegating non-urgent and important work. Two points of confusion:
1) In business, how do I have the authority to delegate when responsibility is frequently defined by the role/organization or I'm at the bottom of the organization?
2) Delegating urgent not important tasks seems like an ineffective use of valuable resources and a recipe for a toxic working relationship. Rather, I would expect someone to delegate not urgent important work so that there is time to deal with the additional cost of handing off work to another person.
What am missing?
For 1), I suspect once you figure out you can just start asking your co-workers to do your stuff, you reach first level of enlightenment and transition from $jobtitle into senior $jobtitle.
For 2), the point is to throw the task - and responsibility for completing it - over the wall. That's why it's prescribed for Urgent and Not Important work: urgency is satisfied by you delegating quickly, and if your victim screws up and fails the task, well, no big deal - the task wasn't important anyway.
All that to say: yeah, I can't see a way this isn't abusive and antisocial, unless done in business context with clear rules, such as hiring people specifically for you to delegate work to them.
An urgent task needs to be done soon. An important task needs to be done by you.
1) If it's a work task and you're at the bottom of a hierarchy, everything given to you by the boss is 'important' by this definition.
2) It may be important to them - the trick is finding the right person.
Taking your kid to a scary dentist appointment is urgent and important; it can't be delayed and it can't be anyone else.
Do less.
Focus on the things you care about.
If you don’t know what you care about, spend time figuring that out first, even if it takes longer than you feel like it should.
A good place to start is Cal Newport’s podcast Deep Questions
Thuis reminders me of the opposite approach Mark Forster takes boy prioritising in the resistance a task creates http://markforster.squarespace.com/blog/2022/6/14/resistance...
Worth remembering that priority and sequence are not quite the same thing.
There's a useful framework called RICE where you evaluate/score ideas by Reach, Impact, Confidence, and Effort. Sometimes assigning numeric values feels forced so I often use it as "dimensions to be thinking about" rather than a literal scoring system. [1]
There's some great stuff in Reinertsen's Flow book about different sequencing strategies and when to use each. Eg, When delay costs are homogeneous, do the shortest task first. When task durations are homogeneous, do the highest cost-of-delay task first.
[1] https://www.intercom.com/blog/rice-simple-prioritization-for...
> How to Prioritize Tasks?
I use a priority quadrant[0]
[0] https://appfluence.com/productivity/why-you-should-manage-ta...
I tried something similar a while back. It made me feel like I was doing really we;; at prioritising my work, but it's honestly a hard thing to do well and without over-engineering prioritisation.
These days I just have a list of weekly objectives (TODOs), and a daily list of things that I'm "doing". The doing list is based mostly on gut feel about what's important right now, and is in part - based on what my team / the business feels is important right now.
All the things in the weekly objective list are always high priority / important, if it isn't, then it doesn't go on a list.
Another vote for all the work Mark Forster has done experimenting with different list methods.
http://markforster.squarespace.com/
With less introspection, I’ve usually done the long list, scanning for something I either feel joy or guilt, and do that. Not that effective at work because most of the work doesn’t bring joy.
If I applied this strategy I would quickly be fired. All of the things that my management chain finds valuable are not things which are valuable to the product (mostly, planning and producing as work output JIRA tasks, spreadsheets, timetables, etc.). Actually working on things valuable to customers is seen as a necessary evil, a game we play to score the primary work output, i.e. plans.
So the word to-do list is misleading. It should be a to-do heap. To be specific, a to-do min-abs-heap :)
In sideprojects that are early stage, I have a todo.txt in my repo with one line, the thing I have to focus on. I keep this thing small in scope. Once it's done I replace it with another thing that's in my head.
It works surprisingly well to keep me focused on the task at hand :)
I seems to always think of new things. Writing them down helps me forget about them and stay focused. So I end up with a much longer todo list.
But once I'm done I have lots of options to choose from. This helps me pick something that I have the energy for instead of getting stuck in 1 tangenital task after another which can feel a bit repetitive.
There is also this: https://www.productplan.com/glossary/weighted-shortest-job-f... Weighted Shortest Job First (WSJF)
>If there is immediate impact, assign a low negative score. And if only in the long term, assign a higher negative score.
So what's a "higher negative score"? :) Is it a score that's nearer to 0 or further away from it?
I see these kinds of posts a lot on here. This one is just like all the others. Trying to reduce effort/reward down to some kind of scoring method.
It's probably correct, but now the problem just moved to accurately scoring each task on a variety of scales. What I find more and more is that it's very hard to see beyond the tasks and figure out side effects of finishing some task or feature because it quickly gets very complex and if you spend time on really thinking it all through to the point where you're certain about the right order, you probably could've knocked half of the tasks out already instead of studying their relationships and long-term effects.
It's trying to leverage mathematics to make correct decisions, but missing the point that the choice of mathematical function is entirely arbitrary. There are literally an infinite number of scoring functions that take three parameters.
There's no reason why picking any one of them would give a reasonable priority of tasks, other than some mysterious mathematical astrology, while aimed to reduce the amount of intuitive guessing is composed entirely of intuitive guessing.
For me, Ease & Impact scoring has proven to be the best mix of simplicity and effectiveness