Why do the real constraints show up after we've already committed?
You and your pod are good at discovery. You ask the right opening questions, you map the system, you nod at the plan. Then weeks later, in the middle of the build, something buried surfaces — a dependency no one named, a limit no one tested, a stakeholder no one asked. It costs you time, and it costs you the team's trust in your process. Here is the honest reason. Your discovery is built to confirm that a plan can work. It is not built to find what will make it fail. Those are different questions, asked differently, and most teams only ask the first one. The second question feels like doubt, so people avoid it — and call the avoiding "efficiency." You are working with others, which makes this worse, not better. Each person assumes someone else checked the risky part. No one owns the hunt. Fix the ownership, and the timing fixes itself.
They surface late because no one was assigned to hunt for them early. Discovery, as you run it, finds what confirms the plan — it is not built to find what breaks it. Choose, before your next commitment, to run one session whose only job is to ask: what will stop this working? Name who answers.
What changes unlock by starting
- Constraints surface in discovery, while they are still cheap to fix, not mid-build when they are expensive.
- Your pod stops being ambushed by its own project.
- Stakeholders trust you more, because you ask hard questions before you promise, not after.
- Your commitments get smaller, more honest, and more often kept.