Stakeholder Maps and Discovery Techniques
The source states that the single most common reason an FDE engagement fails is not technical, but picking the wrong problem to work on.
A Project That Succeeds and Still Fails
Imagine a project that starts well. The customer is excited, the data is ready, and the technology fits the task. Months later the team has a system that runs correctly from start to finish. Yet the system sits unused, or it stalls when procurement reviews it at the final step, or the value it creates reaches no one who matters inside the organization. The source uses this exact situation to open its discussion of why engagements fail.
The lesson of this opening is that a project can succeed technically and still fail as an engagement. This article asks two questions: where that failure actually comes from, and what practice the source recommends for preventing it.
Guessing the Root Cause
What do you think happens?
A team's system works in every test but is never adopted after launch. Which cause does the source identify as the most likely root of the failure?
Reveal answer
The team picked the wrong problem to work on.
The source states that the single most common reason an FDE engagement fails is not technical. It is the team picking the wrong problem. The accuracy, speed, and integration of the system can all be sound while the problem itself was the wrong one to build for.
Why Technical Success Is Not Enough
A common instinct is to treat an FDE engagement as a technical problem. The reasoning goes that if the model is accurate, the pipeline runs, and the integration works, the engagement has succeeded. The source directly challenges this instinct. It states that the single most common reason an FDE engagement fails is not technical. The failure is attributed to the team picking the wrong problem to work on.
The source also names a related assumption that causes trouble: assuming a problem is tractable without proper discovery. A problem can look workable on the surface and still be the wrong one to build for. The source's examples show the same sequence repeating, with a well-built system that never gets used.
The Real Problem Versus the Stated Request
Read together, the three patterns show what a wrong choice of problem costs. The team can do excellent work on a problem and still end with nothing that the organization uses or values. The difference lies in whether the team confirmed which problem was worth solving before it started building.
Discovery as Diagnosing the Real Problem
Discovery is the process of diagnosing the real problem to work on. It is the central activity of the scoping phase and extends into early validation.
The source places discovery within the engagement's timeline. Discovery is the main work of scoping, and it carries forward into the first stage of checking whether the chosen problem is worth pursuing. This means discovery is not a single meeting at the start of a project. It is an activity that spans the scoping work and continues into validation.
How Echo Mode Relates to Discovery
Echo mode enters the picture here. The source states that discovery is what Echo mode is for, and that Echo mode is related to discovery. The source does not elaborate on Echo mode in this section, so the safe takeaway is the direct relationship it states: Echo mode is the mode associated with the discovery work.
Tracing a Stalled Engagement
Following an Engagement From Request to Outcome
A customer asks the team for a system to automate a task. The model is accurate and the pipeline runs. Why might the engagement still fail, and where in the sequence did the failure begin?
- 1Check the technical result
The model is accurate, the pipeline runs, and the integration works. By the source's own framing, this alone does not show the engagement succeeded.
- 2Ask which problem was chosen
The source places the most common failure in the choice of problem. The team must check whether the task they automated was the real problem worth solving.
- 3Locate the failure pattern
If the system sits unused, it matches the first pattern. If it stalls at procurement, it matches the second. If its value reaches no one important, it matches the third. All three trace back to the same earlier decision.
- 4Locate the phase where the decision belongs
The decision about which problem to work on belongs to discovery, the central activity of scoping that carries into early validation. The failure began there, not at deployment.
The technical success was real, but the engagement failed because the team committed to the wrong problem during discovery. The breakdown appeared at the end but began at the start.
Mistakes Teams Make About Problem Choice
Common mistake Treating a working system as proof of a successful engagement
Why it failsThe source states that a working system can still fail as an engagement if it goes unused, is blocked at the last mile, or produces value for no one important.
Do this insteadJudge the engagement by whether the system is used and benefits the right people, not only by whether it runs correctly.
Common mistake Assuming a problem is tractable without proper discovery
Why it failsA problem can look workable on the surface and still be the wrong one to build for.
Do this insteadDiagnose the real problem through discovery before committing to build.
Common mistake Treating discovery as a single meeting at the start
Why it failsThe source places discovery as the central activity of scoping that extends into early validation.
Do this insteadExpect discovery to span scoping and carry into the first stage of checking whether the chosen problem is worth pursuing.
Checking Your Own Engagement
Think of a project you know, real or imagined, that produced a working system. Identify which of the three failure patterns it might have fallen into, and name the earlier decision that the source would point to as the likely root cause.
Hints
- Ask whether the system was used, whether it was blocked at final approval, and whether its value reached the right people.
- The source traces all three patterns to the choice of problem made earlier in the engagement.
Key Takeaways From the Opening Argument
- 1The source states that the single most common reason an FDE engagement fails is not technical, but picking the wrong problem to work on.
- 2A working system can still fail as an engagement if it goes unused, is blocked at the last mile by procurement, or produces value for no one important.
- 3Discovery is the process of diagnosing the real problem to work on. It is the central activity of scoping and extends into early validation.
- 4The source states that discovery is what Echo mode is for, and that Echo mode is related to discovery.
At a glance
- The most common reason an FDE engagement fails is picking the wrong problem to work on, not a technical shortfall.
- The three failure patterns are an unused system, a system blocked at the last mile, and value that reaches no one important.
- Discovery diagnoses the real problem to work on, sits at the center of scoping, and extends into early validation.
- The source states that Echo mode is related to discovery, and that discovery is what Echo mode is for.