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
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.
> 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.
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.
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.
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
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.
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...
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.
I use a priority quadrant[0]
[0] https://appfluence.com/productivity/why-you-should-manage-ta...
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.
It works surprisingly well to keep me focused on the task at hand :)
So what's a "higher negative score"? :) Is it a score that's nearer to 0 or further away from it?
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.