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

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.