[kqr]

There's a fine line between shortest path first and most certain path first. It's tempting to jump in and do the things you know for sure how they will work – these are the things with the lowest need for exploration. Early-stage, you should focus on the things that are most uncertain, the things that have a chance of dooming the entire project if you don't understand them better.

You can still take the shortest path while focusing on the most uncertain first, but it is another concern that needs to be prioritised.

[evanlh]

Yes, totally agree with this-- I perhaps should have emphasized that my point is to code the shortest path thru the hardest problem. If somehow you just code around the hard part & keep deferring that til later you haven't learned anything.

[tuukkah]

I think the shortest/fastest path can have value even if you didn't learn much yet, because it can provide an end-to-end platform for learning: something to show and discuss with stakeholders and potential users.

After you have that platform, the next target can be the biggest uncertainty / hardest problem that you need to solve to achieve an MVP. "We have X, can we get to an MVP?"

(After you have an MVP, the hardest problems may still await you but you can prioritize based on what increases value.)

[Kalanos]

right, you might get an "actually, how about X?"

[tuukkah]

Yes, or even more likely Y ;-)