Before you build the system, get clear on what should actually change.
The Dark Funnel Discovery Plan (DFDP) is a paid strategic diagnosis for GTM problems that are too complex for a quick audit and too important to solve with disconnected tactics.
What DFDP is designed to answer
- Where is the GTM system losing useful signal or buyer context?
- Which signal sources and buying situations actually matter?
- Where do CRM states, routing, handoffs or workflows break the journey?
- Which assumptions need evidence before implementation?
- What should be fixed first, and what can wait?
- What GTM Engineering build would be practical and measurable?
What we review
- ICP, buying situations and current GTM motion.
- Signal sources and data availability.
- Account/person context and enrichment.
- CRM lifecycle, routing and handoffs.
- Outbound, inbound, paid and nurture interaction where relevant.
- Measurement and learning requirements.
- Operational dependencies, ownership and implementation readiness.
What you leave with
- A clearer problem definition.
- Prioritized findings and data gaps.
- Signal / orchestration opportunities worth testing.
- A sequenced roadmap.
- A decision on what should be implemented, deferred or excluded.
- A clearer handoff into GTM Engineering Build if implementation is justified.
Who it is for
DFDP is most useful when the problem is meaningful, involves multiple systems or teams, and needs strategic clarity before implementation.
Questions about DFDP
Why do we need DFDP before Build?
If the problem is already sufficiently verified and implementation-ready, you may not. DFDP is useful when the risk is building the wrong system or sequencing work badly.
Can you just implement one workflow?
Yes, if that workflow is sufficiently bounded and its dependencies are clear. The question is whether solving it alone creates the intended operating outcome.
Can you guarantee the result?
We can define the system, implementation and measurement standard. We should not guarantee a business outcome that depends on market, team, data and operating conditions outside the Build itself.
Is the Build part of the DFDP?
DFDP is the diagnosis and roadmap decision. Build is a separate implementation commitment with a different scope, dependencies and commercial acceptance.
Can you reduce the scope?
Yes. We can identify the smallest scope that still makes operational sense and state what remains outside it.
What if we're not ready now?
Then the right move is to record why, what would need to change, and stop pushing until the state changes.