BANT tells you which developers are worth a conversation. The Sales Grid is what you do once you’re in one.
If my previous post is about qualifying toward the right conversation, this one is about structuring that conversation so it actually goes somewhere. You’re not trying to uncover what the developer needs here - you already know that. What you’re building is a map of their situation: something useful to them in the moment, and exactly what sales needs to continue the relationship intelligently.
The framework comes from Force Management’s Command of the Message methodology, adapted here for a developer relations context. It works as a grid.
The Grid
| Before Scenario | Ideal Scenario |
|---|---|
| Negative Consequences | Positive Outcomes |
| Required Capabilities | |
The fifth section,, Required Capabilities, which is what the developer actually needs in order to move from the left side of the grid to the right.
The four quadrants above are a map you’re trying to fill in. Once you do, you understand their situation well enough to have a conversation that feels genuinely useful to them, while also producing something concrete you can hand to a salesperson.
Before Scenario
This is where the developer is right now, before they’ve solved the problem. Not the technical challenge in isolation, but the situation around it - what makes progress harder than it should be, and why it hasn’t been solved yet.
The reason this matters is that people make decisions based on contrast, not features. If you can articulate a developer’s current situation back to them with enough precision that they feel understood, you’ve created the conditions for an honest conversation - something most vendor interactions never reach.
Negative Consequences
What happens if the developer does nothing? This is worth thinking through carefully, because the answer isn’t always obvious, and it shapes how much urgency exists in the conversation.
The consequences might be technical - a dependency on something fragile, an integration that’s going to require a rewrite in six months. Or organizational: a project that stalls, a team that loses credibility on a bet they made. Or personal, which we’ll get to.
Understanding the cost of inaction tells you how motivated someone is to act, and it tells you how much weight to put behind the conversation.
Ideal Scenario
This is what the developer is trying to get to - the outcome the solution enables, not the solution itself. What does their code look like when the problem is solved? What can the system do that it couldn’t before?
The ideal scenario should be described in terms that belong to the developer, not to your product. “Use our platform” isn’t an ideal scenario - it’s a sales objective. “Ship a reliable integration by end of quarter without owning the maintenance burden long-term” is a picture of success you can actually work toward together.
Positive Outcomes
In a traditional sales context, positive outcomes are almost always business outcomes: cost reduction, revenue impact, risk reduction. Those apply in DevRel too, but they’re not the whole picture.
The personal layer is where DevRel conversations have an advantage over sales conversations, and where most DevRel practitioners underuse the framework. The developer who championed your tool, shipped something with it, and walks into their next performance review with something concrete to point to - that person has a strong personal reason to stay invested. The technical choice they made is now part of how they describe themselves at work.
Understanding what a good outcome means for the developer specifically, not just for their company, is what makes it possible to actually help them get there. And developers who get good personal outcomes from using your product are the ones who stick around, bring colleagues along, and write the forum posts and Discord threads that give your community actual signal.
Required Capabilities
Once you have the four quadrants filled in, the required capabilities almost write themselves. These are the specific things the developer needs to move from where they are to where they’re trying to get. A bridge, not a feature list.
This is also what you hand to sales: where the developer is, where they’re trying to get, what’s at stake if they stay put, and what they need to move. A salesperson can work with that.
What This Looks Like in Practice
Say you’re at a developer conference talking to a backend engineer at a mid-sized fintech. They’re building payment integrations and mentioned they’re currently hand-rolling webhooks with their own retry logic. After twenty minutes of genuine conversation, you might walk away with something like this:
| Before Scenario Hand-rolling webhook delivery and retry logic on top of an internal queue. Works, but it's fragile and the team owns all the failure handling. |
Ideal Scenario Reliable event delivery with no homegrown infrastructure to maintain. Team can focus on business logic. New integrations ship in days, not weeks. |
| Negative Consequences One bad deploy away from silent message loss. No visibility into failure modes. Tech debt is growing as more partners get added. If something breaks badly, it becomes their incident to own. |
Positive Outcomes Business: reduced ops burden, faster integration velocity, lower incident rate. Personal: engineer gets to retire code they've been embarrassed about. Looks like the person who fixed a systemic problem, not just patched symptoms. |
| Required Capabilities Managed webhook delivery with configurable retry policies, delivery logs with per-event status, and an API that fits into their existing event model without a rewrite. |
|
The Grid is a mental model you use during a conversation. The goal is to come away from any meaningful developer interaction with enough to populate each quadrant - through a conversation that was useful to them, not an interrogation.
A developer who feels like you understood their situation and gave them something useful will tell you things that fill the grid naturally. That’s the posture that makes this work: genuine usefulness first, structured understanding as a byproduct.
The handoff to sales, or the justification memo for your own work, is just an artifact of having done the conversation well.
In the third and final post in this series, we’ll look at what it means to be audible-ready - fluent enough in this framework that you can adjust your message in the moment, when the conversation goes somewhere you didn’t plan for.