One challenge that I have struggled with are tasks that aren’t quite “must do,” but are more than “should do.” This actually happens a lot when you are creating something new, such as a website or app. You wind up with items that you think should be part of the project, and would be very very beneficial, but aren’t actually required.
For example, let’s say you are building a project management app. To create a minimal viable product (MVP), there are certain things that you must have. Those are “must do.” And you have features that would be nice to have. Those are “should do” or even “could do.” But there are certain features that are so beneficial, it’d be a mistake not to do those before the other should do’s.
If I label these items as “must do,” it dilutes what “must do” actually means. if I include these in “should do,” it gets lost in a list of should do’s and things are not prioritized correctly.
My current solution to this dilemma is to create a priority level that sits between “must do” and “should do.” I am not sure what to actually call it though. I suppose, technically, it is just a higher priority “should do.”
Indeed, this is a problem—not too much for everyday to-do lists, but more so for formal prioritisation.
So for choosing features I’d recommend doing a cost-benefit analysis, of which even a quick rough one is far better than relying on gut feel to assign priorities. It so happens I’ve given a lecture all about how to do this for software features—see here:
One challenge that I have struggled with are tasks that aren’t quite “must do,” but are more than “should do.” This actually happens a lot when you are creating something new, such as a website or app. You wind up with items that you think should be part of the project, and would be very very beneficial, but aren’t actually required.
For example, let’s say you are building a project management app. To create a minimal viable product (MVP), there are certain things that you must have. Those are “must do.” And you have features that would be nice to have. Those are “should do” or even “could do.” But there are certain features that are so beneficial, it’d be a mistake not to do those before the other should do’s.
If I label these items as “must do,” it dilutes what “must do” actually means. if I include these in “should do,” it gets lost in a list of should do’s and things are not prioritized correctly.
My current solution to this dilemma is to create a priority level that sits between “must do” and “should do.” I am not sure what to actually call it though. I suppose, technically, it is just a higher priority “should do.”
Apologies for the slow reply.
Indeed, this is a problem—not too much for everyday to-do lists, but more so for formal prioritisation.
So for choosing features I’d recommend doing a cost-benefit analysis, of which even a quick rough one is far better than relying on gut feel to assign priorities. It so happens I’ve given a lecture all about how to do this for software features—see here:
https://www.youtube.com/watch?v=LUCtNJYcbxQ&t=0m1s
The slides (to view alongside it) are here: http://www.benfinn.uk/uploads/5/3/1/0/53108699/how_to_choose_features.pdf