Gates and Boundaries for Sales and FDE Motions

We always advocate at Dynamic the importance of getting to a technical win. A technical win is when the customer agrees that a specific workflow, integration, architecture, deployment path, or technical outcome now works well enough to justify the next commercial step.

Across both PLG and Sales-led motions, product adoption remains critical, often requiring more resources. There are two things that make a forward-deployed or solutions-oriented motion far more effective regardless of your customer engagement (e.g. design partner, POC, or existing customer): 1) Gating each part of the process and 2) Building boundaries.

Although obvious, few teams do this well! Lots of companies have high committed ARR and no customer usage because steps were skipped and no clear alignment on the gates to ultimately achieve long-term success. Alternatively, there are many companies with 8-9 figure run rate growing fast but with low NRR.

Without clearly defining a technical win, you end up doing a lot of work that feels productive but does not actually create leverage in the sales process. Answering questions, getting engineers involved, scheduling late calls all without the prospect agreeing in formal fashion what needs to be proven, who needs to validate it, what happens if it works, or what commercial step happens on the other side. For the record doing these things are a requirement to win, but with limited resources focus matters.

First: Gating each part of the process (not just scheduling the next call)

This does not mean putting a next step on the calendar or saying what you expect the prospect to do next over email. It means formally getting the customer's commitment around how and why we are going to help them achieve something specific. And if we achieve that specific thing, there will be dollars on the other side. If you do not have that, you do not need to build.

The gate should sound something like: if we prove X workflow by Y date with Z stakeholder, the next step is a paid pilot, expansion, security review, contract review, or commercial conversation (more on how to do this without being awkward here).

This is especially important for technical products because the customer will often ask for more before they have committed anything meaningful (custom workflows, integration requirements, more resources, etc.), and sometimes you need to say yes to earn their trust, but the better you get at earning goodwill and trust early in the process and get something in return, the faster you'll grow.

Second: Building boundaries

There are situations where you have to prove and build value before you have any real trust from the customer. Oftentimes with limited discovery, or any for that matter because you spend most of the time trying to explain what the hell it is you do compared to many other options. However, going back to point one, it is very important you can identify when to prove the build, when to go back and make the ask, and how to use that momentum to move the deal forward.

The companies that have done this exceptionally well like Databricks, Clay, Parallel, Cognition, and others, run the same loop: build, show, prove, position the technical win, ask for the dollars, and repeat.

Most teams get good at the first half. They build, show, and prove, and then wait for the customer to tell them what happens next. The technical win is the permission structure for the commercial conversation, but it does not run the conversation for you. Once you have proven the workflow, translate it: we agreed this was the workflow that mattered, we proved it with your team, here is the business impact, here is who needs to be involved now, here is the next phase (selling the next step, not just nudging it by putting a meeting on the calendar).

A great way to build boundaries is through buyer/executive enrollment. A champion who loves you but cannot fight for you internally is a coach, and you need to know the difference (you also need to know the difference between a buyer, signer, and budget owner). Before the work starts, map who validates the technical requirements, who owns the business case, who signs, and who can block. Your job is to arm your champion and anticipate what they need to sell internally: the business case, the technical proof, the trap-setting questions for competitors, the phased rollout, and the reason this matters now.

Examples of boundary setting below, and what we consider to be "required touchpoints" that all deals should have:

Motion

Sales-led

1. DiscoveryQualify deal
2. Technical Deep Dive / ScopingIdentify priority use case and success criteria
3. Executive AlignmentSign off success criteria; multi-thread and gain access to buyer
4. POC KickoffMeeting with key stakeholders
5. POC ValidationFormal meeting to walk through performance of the POC
6. Demand ForecastingScope credits, know current + future use cases
7. Proposal ReviewReview formal pricing with signer

Motion

Hands-on AI-Native / PLG

1. DiscoveryQualify deal
2. Technical Deep Dive / ScopingIdentify priority use case and success criteria
3. Data Test ApprovalGet internal approval for data test
4. POC Readout + Usage ScopingScheduled meeting to review results live
5. Pricing Review + Exec AlignmentReview formal pricing with signer

AI-native / PLG: Customer can easily get up and running, value should be easy to achieve, but as most technical Founders know, onboarding to new products often require a human touchpoint at some point in the process. Customers may have access to you on Slack and can get help, but it may require supporting the build of a custom workflow or engineering resource (maybe even you) before anyone has discussed commercials or what happens at the end of the trial. Rather than just committing to free implementation support to win the trust of the customer, you can earn their trust by constantly giving help, but looking for key leverage points to get something in return.

To start, on the technical side, you can scope the evaluation like an engineering sprint: 30 days, one workflow to prove. The parallel path on the commercial side is to identify the signer before the start of the work, maybe through a review of "how pricing works" and which options they'll have at the end of the trial.

Example: the customer can start with a low friction usage-based agreement with card on file, or a small committed package. However, conversion trigger should be exceptionally clear: if the workflow works, usage continues into a paid phase (paygo/self-service), or an annual contract. In this motion, the technical win often comes before the formal sales process, but that does not mean the process should be unbounded. The best teams make adoption easy while still attaching every extra hour of help to a give/get.

Sales-led: In a sales-led motion, the POC should start with the finish line already agreed upon. Before the evaluation begins, you align with the buyer on the workflow being tested, the success criteria, the technical owner, the security and legal path, the signer, the price range, and the date you will make the commercial decision (key: build an evaluation document). Then every check-in starts from the same document: here is what we agreed to prove, here is what has been proven, here is what is still open, and here is what happens next.

The common mistake is to win the technical evaluation and then ask, "What do you think?" That invites delay. The better move is to say, "We agreed this was the technical win. We proved it with your team. Are we still on track for the paid pilot / contract review / expansion conversation we agreed to?" If the customer adds new requirements midstream, you do not automatically absorb them. You ask what changed, whether this replaces one of the original requirements, or whether it belongs in the paid phase after the initial win.

Boundaries show customers you know how to run a process, and they force the customer to decide whether this actually matters, which is information you want early. If you have done all of this, built alongside the customer, set the boundaries, won the technical evaluation, and enrolled the buyer, you have also built the raw materials for a case study post-signature.

Design partnerships: Design Partners should get early access, but only get deeper engineering access to the partners willing to put the right technical owner in the room, commit to a real use case, and agree on what happens if the product works. It's similar to the PLG motion above, but you need to highlight flexibility and earn trust through more work while knowing when to ask for commercials after you've achieved the committed milestones. Design Partners often are longer by nature, and that's okay. Just don't build for yourself, make sure you're building towards the expected and mutually agreed upon value the partner expects.

Cognition shares proof on how they started and where they are now

1. Used to bring everyone to the deal — you can and should do this early on, but you can't do this forever. Even in this scenario, I'm certain the team struggled when trying to land the first commercial agreement after doing a lot of work. It paid off though.
2. With more customers helps build a "process" each time you win another logo — Having a great logo like Nubank likely allowed them to have some referencable examples, architecture, and resources to improve the velocity of the next deal.
3. FDE has changed at scale, you can do FDE too, but you need safeguards — As they've matured, they now have control over the timelines, when a customer is expected to deploy, and the timeline expected to close a new customer.
4. Resource allocation is even more critical now — Even with this maturing process, there are more customers to support and their time allocation varies based on customer demands and the boundaries set with each one.

What we liked about this clip from Scott Wu at Cognition

Educate (lean in when needed)

• Show and understand value first (user education and guidance)
  • Show use cases and getting them to success
• "Debugging on their exact problems"
• Get deployed in first 3 months prove value ongoing

Qualifying

• Priority use case (notice how Scott doesn't point out "urgency or pain," but highlights the signal of investment already "if you have 25,000 software engineers that's in an org that's running, that costs 10 billion a year or something, that you think can move three times faster, usually it is a priority.")
• Deployment requirements (private cloud, etc)
• The customer can be self-sufficient using Devin not fully reliant on Cognition post-sale (you can still help, but this is not Palantir-esque as many think)

Case study proofpoints (learnings from previous FDE work)

• Show value of what you'll get similar to others
• Nubank became a future proofpoint and allowed them to compound

Process work (legal, security, etc)

• Only do this work as you qualify the process