Instructions
Every build plan has risks hiding in it. Some are obvious — the technical problem nobody has solved before, the integration you've never built, the third-party dependency you're betting heavily on. Others are less visible but equally dangerous: the team member whose capacity is actually half what was assumed, the scope that's technically possible but wildly underestimated.
Surface these risks before the build starts, not halfway through. Technical risks are best managed when they're identified early enough to change the plan — to test the risky component first, to find an alternative approach, or to adjust scope so the risk no longer exists. Discovering them during a build is far more disruptive.
Not all technical risks are equal. A risk that would prevent the MVP from functio...
