What is the Current → Desired → Impact framework for discovery that solution engineers can use?

The Current → Desired → Impact framework for discovery, described in the post and attributed to Robert Riefstahl’s book Demonstrating to Win!, guides solution engineers to first understand how work is currently done and where workflow gaps and friction exist, then uncover the customer’s ideal solution in the customer’s own positive language, and finally quantify the potential impact of that solution on time or revenue. The framework is presented as a way to connect technical depth to strategic impact by moving conversations from feature checklists to business outcomes.

How should a solution engineer ask about a customer’s current state during discovery?

According to the post, a solution engineer should ask questions such as “How is your work currently done? Walk me through the gaps in workflow. What systems are you using to get around that?” and then use the answers not just for documentation but to diagnose friction. This approach helps the solution engineer identify the pain behind the process, which the post describes as a key to building urgency.

How do I get a customer to describe their desired outcome without jumping straight into pitching my product?

The post recommends asking a question like “What’s your vision or ideal solution?” and then rephrasing that question in different language until the customer describes the ideal outcome in their own words and in positive rather than negative terms. The author emphasizes that the goal at this stage is not to pitch but to uncover what the customer wants fixed, prioritized, and streamlined, while setting up a path to bridge from that desired state to the solution during the demo.

How can I quantify impact in a sales demo as a solutions engineer?

The post suggests asking the customer a question such as “If you had a magic wand and this solution was in place, what would be the impact on your time, or better yet, revenue lift?” and using the response to build an ROI narrative. The author states that if a demo does not quantify impact in this way, the solution engineer is leaving value on the table and often losing the deal.

Why does the author think the Current → Desired → Impact framework matters beyond initial discovery calls?

The author states that the Current → Desired → Impact framework is a mindset for every customer conversation, not just discovery calls, because it elevates the dialogue from features to business outcomes. The post claims that when solution engineers consistently use this framework, churn drops, sales cycles shorten, and solution engineers become trusted advisors.

Why Your Demos Aren't Converting

Too many solution engineers treat discovery like a checklist. But the best drive discovery like a business consultant, connecting technical depth to strategic impact.

In Robert Riefstahl's Demonstrating to Win!, there's a deceptively simple framework that every revenue-focused technical leader should be using.

Current

"How is your work currently done? Walk me through the gaps in workflow. What systems are you using to get around that?" You're not just documenting. You're diagnosing friction. This is how you identify the pain behind the process, a key to building urgency.

Desired

"What's your vision or ideal solution?" Here's the gotcha: assuming your solution is the answer. Instead, ask this in different language until they describe their ideal outcome in their own words, in positive rather than negative language. The goal isn't to pitch yet. It's to uncover what they want fixed, prioritized, and streamlined, while mapping a way to get them across the bridge to desiring your solution during your demo.

Impact

"If you had a magic wand and this solution was in place, what would be the impact on your time, or better yet, revenue lift?" This is where the ROI narrative gets built. Because if your demo doesn't quantify impact, you're leaving value on the table. Often, you're also losing the deal.

My Take

This framework isn't just for discovery calls. It's a mindset for every customer conversation.

When you approach discovery and demos with Current → Desired → Impact, you elevate the dialogue from features to business outcomes. That's where churn drops. Sales cycles shorten. And solution engineers become trusted advisors.

Have you used a discovery framework that works? I'd love to hear your take.

Frequently asked questions

What is the Current → Desired → Impact framework for discovery that solution engineers can use?: The Current → Desired → Impact framework for discovery, described in the post and attributed to Robert Riefstahl’s book Demonstrating to Win!, guides solution engineers to first understand how work is currently done and where workflow gaps and friction exist, then uncover the customer’s ideal solution in the customer’s own positive language, and finally quantify the potential impact of that solution on time or revenue. The framework is presented as a way to connect technical depth to strategic impact by moving conversations from feature checklists to business outcomes.
How should a solution engineer ask about a customer’s current state during discovery?: According to the post, a solution engineer should ask questions such as “How is your work currently done? Walk me through the gaps in workflow. What systems are you using to get around that?” and then use the answers not just for documentation but to diagnose friction. This approach helps the solution engineer identify the pain behind the process, which the post describes as a key to building urgency.
How do I get a customer to describe their desired outcome without jumping straight into pitching my product?: The post recommends asking a question like “What’s your vision or ideal solution?” and then rephrasing that question in different language until the customer describes the ideal outcome in their own words and in positive rather than negative terms. The author emphasizes that the goal at this stage is not to pitch but to uncover what the customer wants fixed, prioritized, and streamlined, while setting up a path to bridge from that desired state to the solution during the demo.
How can I quantify impact in a sales demo as a solutions engineer?: The post suggests asking the customer a question such as “If you had a magic wand and this solution was in place, what would be the impact on your time, or better yet, revenue lift?” and using the response to build an ROI narrative. The author states that if a demo does not quantify impact in this way, the solution engineer is leaving value on the table and often losing the deal.
Why does the author think the Current → Desired → Impact framework matters beyond initial discovery calls?: The author states that the Current → Desired → Impact framework is a mindset for every customer conversation, not just discovery calls, because it elevates the dialogue from features to business outcomes. The post claims that when solution engineers consistently use this framework, churn drops, sales cycles shorten, and solution engineers become trusted advisors.