Sales engineering for technical founders: build the buyer's version
How CharacterQuilt uses discovery, customer feedback, and shareable custom demos to help buyers see their own work getting done.
Adapted from Bhairav's founder essay on CharacterQuilt's sales process.
Sales engineering helps a buyer see how a product would solve their actual problem before they commit to buying or integrating it. At CharacterQuilt, that means taking what a prospect says in discovery, building a campaign around it, revising it from their feedback, and giving them something they can share with their team.
Our first mistake was thinking a personalized demo was enough. We would arrive with campaigns in a prospect's brand and show how much work we could produce. The recurring objection was much simpler: those were not campaigns they wanted to run. We were asking them to imagine the last step for themselves.
What makes a custom demo useful?
A useful demo reflects the buyer's goal, workflow, and constraints. A company logo on an arbitrary campaign shows that you did some preparation. A campaign the buyer asked for, revised in response to their comments, shows that you understand the work.
The difference became clear in an early customer meeting. A prototype built from a whiteboard discussion received a long list of objections. The revised version, incorporating that feedback, received a very different response. The lesson was about participation: the customer needed to recognize their own judgment in the result.
How do we run the first conversation?
We show enough of the product to make the possibilities concrete, then spend the rest of the conversation learning what the prospect would change. Our two most useful questions are:
- What did we get wrong about your brand or campaign? Ask for specifics about the audience, message, creative, measurement, and workflow.
- What campaign would you actually want to run? Ground the answer in work already on their calendar or backlog.
We try to resist answering every objection with another feature demonstration. Jumping straight to a screen can cut off the more useful explanation of why the issue matters. “What would you need to see?” often gives us better material for the next version.
A hard requirement still deserves a direct answer. If a capability is unavailable, say so. A demo should make the evaluation more accurate.
What goes from the call into the next demo?
We use the discovery notes and transcript, where recording is permitted, to turn feedback into a short build brief. The brief should distinguish the buyer's actual request from the seller's interpretation.
| Input from discovery | Change in the next version |
|---|---|
| A specific upcoming campaign | Show that campaign's audience, message, and assets. |
| A correction to the brand or voice | Apply the correction consistently across the example. |
| A question about where work lands | Show the relevant destination and explain the integration boundary. |
| A requirement from another stakeholder | Add the evidence that person needs to evaluate the proposal. |
Fast turnaround matters because the discussion is still fresh. In our founder-led process, we aimed to return the revised work by the next working day when scope allowed. That is a description of our approach, not a delivery promise for every project.
How do you show integrations before a customer connects their tools?
Use a clearly labeled demo environment. Our sales process has included simulated marketing tools and sample data to show what a workflow could look like before we have access to a prospect's systems. A simulation explains an intended workflow; it does not prove a live integration.
- Label sample data and simulated screens where the viewer sees them.
- Separate capabilities available today from proposed work.
- Explain which permissions and setup are needed for a live evaluation.
- Verify the real workflow in an agreed environment before treating it as operational.
This distinction also makes the next step easier to scope. The buyer can evaluate the campaign first, then test the deployment path with the people who own their systems. Our demo process and deployment overview explain those stages.
What should a champion be able to forward internally?
The artifact should explain itself when you are absent. Lead with the buyer's problem, show the proposed work, identify what is demonstrated, and state the next decision. A short walkthrough and a shareable page can help a colleague understand the proposal without sitting through the original call.
For example, an illustrative sales room for an account-based campaign could contain the target segment, an email sequence, a landing page, a labeled view of the destination system, and the open questions for marketing operations. It should focus on the few things the buying group cares about.
Our strongest demos became a way for the champion to show their own idea taking shape. That is more useful internally than a catalog of everything our product can do.
When is this approach worth the effort?
It is best suited to considered purchases where value depends on the customer's workflow and the team can justify the preparation. Our experience comes from founder-led enterprise marketing sales. The economics will be different for a low-cost, self-serve product.
Set a limit on custom work before starting. Track preparation time, whether buyers share the result, which questions remain, and whether the next meeting advances the evaluation. A beautiful demo that answers the wrong problem is still the wrong demo.
How does this connect to our dinner playbook?
A dinner creates a setting where people can talk openly about their work. Sales engineering turns that understanding into something concrete. The sequence is to earn the conversation, learn what matters, and build a relevant next step. Read how we use small dinners to start those conversations.
Ready to clear your campaign backlog?
Tell us the campaign you have in mind. We'll build it and launch it in the tools you already use.
