[edmundsauto]

I think of it as building a staircase. If we need to hit 98% eventually, we need to make certain progress now. It is possible that a new breakthrough could appear in 2 years to spike that, but the safer assumption is that our near term progress will harvest the low hanging fruit.

Therefore, intermediate and measurable milestones are to derisk something. Even if you are doing a moonshot, there are still steps you can identify. The namesake, Apollo, didn’t try for the moon on the first launch!

[potatolicious]

Exactly this. Intermediate shippables are derisking. There are a few things that this strategy represents to executives:

- "You have already received benefit X for your investment in our team, and X has been well worth it. Continued investment in us will yield benefit Y."

- "Even if the project is terminated early, or later stages become blocked due to business or technical impracticalities, the company will have gained a tangible benefit already in the form of X. There is a payout, even if it is not the full thing we wanted."

- "The intermediate products validate the technology/product/business model, such that every incremental deliverable means an overall reduction in risk to the final goal."

[edmundsauto]

100%. And the sooner low level folks like me can provide this signal, the sooner the execs can make decisions. That saves cycle time and is the real secret sauce for growth.

That’s why my favorite interview question (I’ve done hundreds of interviews) is “tell me about a time you cut corners on a project”. My role as a data person is to provide enough signal as early as possible - not necessarily to give a precise answer to everything we want to know.

[iknownthing]

Right but the "how" is the tricky part. For example, wrt to ML, what is the milestone and how do you know you will hit it by a particular date? Very difficult to say with ML.

[edmundsauto]

This is where smart analytics teams are super useful. It is a really hard projection estimation! Even understanding what the F1 score should be to be "good enough" is nearly impossible, much less understanding what it takes to go from "where we are" to "good enough".

What you can do is estimate something like "we think we need $measurement_value on $metric by $date, we are at $current_value. If we're not at 75% of the gap in 50% of the project time (when we have low hanging fruit), we cancel."

[iknownthing]

Yep, time-boxing is kind of the only solution.