What kills me is that this sort of mystery is not in any way necessary. The planning methods from, e.g., Extreme Programming, are 15 years old. So that nobody else has to suffer like this, here's my 30-second intro to a basic version:
Everybody sit down at a table with a large stack of index cards, all of one color that isn't white, and n+1 sharpies. Talk about the product. As you go, every time something buildable is mentioned, write it on an index card with a sharpie. 3-7 words is enough; the cards aren't documentation; they're just tokens representing conversations. Every card should create business value that is visible to all stakeholders. No "set up the IDE", no "learn node", just business value cards.
After 30-60 minutes, put the cards in strict linear order of business desire, ignoring technical dependencies. Now take a bunch of cards, write "RELEASE" on them, and insert them into the order every time something shippable is necessary, including investor demos, user tests, private betas, and the like.
Next, look at the top 10-20 cards. For each one, ask the developers if it will take a week or more. No wizardry needed, just gut-level estimates. If the answer is yes, tear up the card and replace it with cards that are all smaller than a week of effort. Congrats! Now you have a plan that is enough for developers to get started. Make a permanent home for the cards on a table or wall with three columns: backlog, working, done.
Each week on Monday morning, everybody should sit together, look at the backlog, and take an hour to discuss everything that will likely get worked on. During the week, when people start on a card, move it from "backlog" to "working". When everybody agrees that it is completely done and the business value is has been demonstrated, move it to "done". And the end of the week, sit down together again, review how it went, count the cards completed. Protip: keep the number of cards in "working" as small as possible.
After a few weeks, the business stakeholder can look at the number of cards completed each week, look at the backlog, and make reasonable guesses as to how long things will take. And after a few weeks seeing the team deliver business value each week, they'll have a good notion of how effective their team is.
There are nuances (about which I'm glad to answer questions), but that's enough to get going. I've built a number of products this way and helped others do the same. Please, founders: adopt some simple short-cycle iterative process. It's not hard, it doesn't take long, and it will save you immense trouble.