The Three-Legged Stool

Rav Dhaliwal
7 min readApr 27, 2022
Rav Dhaliwal

The platitude

A common start-up axiom is that “Customer success begins in the sales cycle”, yet a cursory look at how most start-ups conduct their sales discovery reveals that this is (unfortunately) almost always a platitude.

The reason for this does not lie with any one individual or team but rather stems from the (conventional) view that only two sets of skills are required to conduct effective sales discovery.

The “discovery” stool

AE owned commercial discovery

If we were to represent this conventional sales view as a stool, with the seat representing the customer opportunity, the first leg of the stool would be the “commercial discovery” skills, owned and conducted by an Account Executive (AE).

In some (very) early-stage start-ups or start-ups which offer a simple consumer-style service, this single leg of discovery can sometimes be sufficient to convert the opportunity.

However, for even a moderately complex software product, a second “technical discovery” leg, owned and conducted by a Sales Engineer (SE) is almost always required to ensure the prospective customer’s functional, compliance and security requirements are met.

AE + SE owned technical discovery

Once both discovery legs have been conducted, conventional sales wisdom dictates that no further discovery should be required to convert the opportunity into new revenue.


Whilst “two legs” of discovery may be sufficient (in the short-term) to convert the first opportunity with a prospective customer, a two-legged stool is an inherently unstable structure for a start-up’s long-term revenue growth.

This is because the delivery model of software as a service (SaaS), combined with subscription licensing allows a contemporary software buyer to start with a smaller initial purchase and “ease in’’ to wider usage over time, but only if the software demonstrably adds timely value to their business.

By contrast, the conventional view that sales discovery only requires commercial and technical skills was established in the on-premises, perpetual licensing era when “time to value” was rarely (if ever) a buyer consideration, as both buyers and sellers generally understood and accepted that significant amounts of time, effort and capital would be required to deploy, host, run and manage software.

For founders in the contemporary SaaS subscription era looking to ensure that their (often hard-won) revenue from new customers is not only retained but also increases healthily over time, a third leg needs to be added to the discovery stool to ensure greater revenue stability.

The three-legged stool

AE + SE + CSM owned deployment discovery

Owned and conducted by a Customer Success Manager (CSM), “deployment discovery” runs in parallel to the commercial and technical legs so as not to slow down deal momentum.

And to minimize the effort of (often scarce) Customer Success resources, deployment discovery need only occur in the later stages of the sales cycle when the likelihood of a successful conversion is high.

The purpose of deployment discovery is to assess how successful (or not) a prospective customer is likely to be with deploying and using the software and most importantly, whether they can achieve both in a timely manner.

The reason it is critical to make this assessment in the sales cycle is that it minimizes one of the most common (but regularly obfuscated) challenges start-ups face with long-term revenue growth — “the buyer-deployer gap”.

The buyer-deployer gap

Enterprise software buyers are typically in leadership or executive positions and evaluate software purchases through the lens of their desired business outcomes. In contrast, the people tasked with deploying and eventually using the software are almost always further down in the organization’s hierarchy, often with little or no context on what the software is for, why it was purchased and what outcomes or business value it is supposed to deliver. The larger the prospective customer is, the more disconnected these buyer and deployer groups tend to be.

The gap between these groups can result in a host of challenges that impact a start-up’s long term revenue growth prospects, chief of which is that the deployers have usually been “volunteered” the task of realising the buyer’s desired outcomes on top of their (already busy) day jobs.

Unless the deployers are personally invested in making the software a success, it is quite common for them to be unresponsive or slow moving because of the increased workload or competing priorities.

This can result in deployments or onboarding dragging on for a long time or never getting started. In some circumstances the start-up may even need to spend additional time and effort “reselling” the solution to the deployers in the hopes of getting things moving.

The longer the “time to value” is for a customer, the greater the long-term revenue risk is for the start-up.

For example, if it takes a customer 8 months of a 12-month subscription to fully deploy the software and onboard users, the window for demonstrating the buyer’s desired outcomes becomes so small that it risks losing the hard-won revenue at the upcoming renewal. Even more importantly, the longer it takes for a customer to see value, the right of the start-up to come back to the customer and propose doing additional business with them gets smaller and smaller (or even non-existent).

Considering the initial cost of sale, any loss of the original or future expansion revenue means the start-up’s options for healthy growth start to get narrower and narrower.

Closing the gap

Understanding the gap between the buyer and the deployer and taking proactive steps to close or minimise it during the sales cycle is at the core of what deployment discovery is designed to achieve.

Deployment discovery represents an opportunity (and window of time) for a CSM to discover if the customer has any blockers to achieving fast time to value.

In particular, ascertaining if they have -

  • Available skills & resources to deploy the software in a timely manner
  • The ability to drive any change management that may be required for successful user adoption
  • Sufficient executive sponsorship to prioritise the deployment and adoption appropriately
  • Measures or KPIs for demonstrating value within a timeframe that is both realistic and that aligns with the start-up’s
  • Specific internal approval processes, governance requirements or timing windows for any technical changes that may be required
  • A track record (or not) of successfully managing software deployment and user onboarding projects

Being armed with the results from this deployment discovery before the opportunity closes provides the start-up with a valuable window of time to close the “buyer — deployer gap” by working with the prospective customer to mitigate or minimise any blockers that would impede fast time to value.

Bringing in a partner, proposing professional services or working with the buyer to identify, engage, educate and establish rapport with the deployers ahead of deal closure, are just some of the examples of how deployment discovery can proactively help to mitigate or minimise time to value blockers.

Another important added bonus of deployment discovery is that if issues or delays do occur with the deployers, then the CSM has a ready-made escalation route back to the buyer via the relationship they established with them during discovery (without the need to re-engage and interrupt the new business focus of the AE and SE).

And, if done correctly, deployment discovery can represent an opportunity to accelerate the buyer’s thinking beyond the mechanics of closing the deal, to the real world business value they will be able to realise, which in turn should add further momentum, excitement and urgency to get the deal done.

Shift left

In much the same way as software engineering has shifted testing tasks to much earlier in the development cycle to ensure the release of more stable software, founders wishing to create a more stable foundation for long-term revenue growth by “shifting” deployment discovery in to the sales cycle should consider the following –

  • Adding “deployment discovery” as a mandatory step in the sales process
  • Deciding the deal stage (or percentage likelihood) for when it should be conducted, keeping in mind that -
    Too early in the sales cycle risks slowing down the momentum of the deal, or mis-allocating CS resources
    Too late in the sales cycle risks not having enough time to assess, minimise or mitigate any time to value blockers
  • Allocating CSMs to opportunities using the same assignment criteria used for SEs, or if CS resource is constrained, implementing “opportunity thresholds” so that only the highest value opportunities are assigned a CSM for deployment discovery
  • In a high-volume sales environment where a CSM can not be allocated to every opportunity, providing deployment discovery checklists for AEs and SEs or even self-service discovery surveys for customers, to capture the necessary information.

Together, these considerations should help the start-up to minimise the inherent “tug-of-war” tension that often exists between “time to close” and “time to value”.

Avoiding the platitude

Founders and early start-up hires can often “live and breathe” their product so intensely that they can very easily assume that its business value is self-evident to both buyers and deployers.

As a result, it’s not uncommon for founders to believe that renewal and growth revenue either happens automatically, or only requires attention and effort after contract signature.

Adopting the mindset and approach of being in a continuous sales motion and making deployment discovery a core part of the sales process acts as a forcing function for the start-up to actually deliver on the promise of the software’s value as quickly as possible, and if done correctly should maximise the chances of both fast time to value for customers and stable long term revenue growth for the start-up.



Rav Dhaliwal

Investor, Board Member, Venture & Limited Partner @crane_vc . Alumni @slackhq @zendesk @yammer @salesforce and others.