DevOps and developer tools sales objections, questions and competitors

When they push back.

The objections DevOps and developer tools buyers raise most, what to say in the next ten seconds, and what not to promise.

"This is more expensive than what we pay now."

Fair. Compared to what, exactly: the license, or the license plus the time your team spends keeping the current setup running?

Do not discount on the first push. Do not invent hour savings; ask them to estimate.

"Migrating everything would take forever."

What would you have to move first to prove it works, and what could stay where it is for now?

Do not promise an easy migration or a timeline you have not scoped with an engineer.

"We built our own and it works fine."

That makes sense. Who maintains it today, and what happens when that person moves on?

Do not insult the internal tool. The person who built it may be on the call.

"Now is not a good time. We are in the middle of a big project."

Understood. When that project lands, what will be harder or easier because of the tooling you have today?

Do not push for a proof of concept they cannot staff. A stalled pilot hurts more than waiting.

"Security will never approve a tool with access to our code and cloud."

What does security usually need to see for a tool like this, and can we get that list early?

Do not claim certifications or controls you have not confirmed with your own security team.

"We already use GitHub for that."

Got it. Which parts of that are working well, and where are people adding other tools around it?

Do not run down the incumbent. Do not claim features the incumbent lacks unless you are sure.

Every one of these is a deal that slips a quarter if you fumble it. Ghost puts the answer on your screen while the buyer is still talking.

Download for Windows Download for Mac

When they name a competitor.

Give them credit, then ask whether that vendor's strength matters to this buyer.

JFrog

JFrog is the name many teams trust for artifacts and binaries. Is artifact management the gap, or is it something further down the pipeline?

Datadog

Datadog is known for broad observability in one place. Is visibility the problem, or is it what happens before code reaches production?

Harness

Harness is known for software delivery with a lot of automation and AI features. Which part of delivery are you trying to fix first?

CircleCI

CircleCI is known for fast, hosted CI that developers like. Is build speed the issue, or what comes after the build?

CloudBees

CloudBees is the enterprise home for Jenkins. How much of your pipeline runs on Jenkins today, and how do you feel about that?

Snyk

Snyk is well known for developer-first security scanning. Is the gap in finding issues, or in fixing them and proving it to auditors?

JetBrains

JetBrains makes the IDEs a lot of your developers love. Is this about the individual developer's tools, or the team's workflow?

Sonar

Sonar is the standard for code quality checks in a lot of shops. Is the problem code quality, or what happens once code is merged?

Questions that qualify the deal.

Ask these on the first call. Then dig into the pain when they say it out loud.

Qualify

Can you walk me through the last change you shipped, from commit to production? Where did it wait?
If I asked your developers what slows them down most, what would they say?
When that breaks or slows down, what does it cost the business? Who notices first?
What changed that made this worth looking at this quarter instead of next year?
Besides you, who has to say yes, and who could say no?
Is this already budgeted, or would it replace spend on something you have today?

Dig into the pain

"Our platform team is buried in tickets from developers." What kinds of tickets come in most, and what would it mean if many of them answered themselves?
"We have too many tools and nobody knows how they fit together." If you listed every tool in the path to production, which ones would you keep if you started over?
"Our cloud setup drifted and nobody trusts what is in code." When someone changes something in the console, how do you find out today?
"Security keeps finding problems late, right before release." Where in the process does security usually find issues, and what happens to the release when they do?

Know who is in the room.

Tools engineers use to write, build, test, ship and run software. The category spans source control, CI/CD, artifact management, infrastructure as code, security scanning, observability and internal developer platforms. Most teams run a stack of several of these, stitched together by a platform or DevOps group.

Who buys and who signs

Economic buyer: VP Engineering or CTO for platform-wide tools. A director can often sign team-level tools on a card or a small order.
Champion: A platform engineering lead, staff engineer or DevOps manager who feels the pain daily and has tried to fix it.
Users: Application developers, SREs, platform engineers and security engineers. They will test the product hands-on before anyone signs.
Blockers: Security (access to code and cloud credentials), procurement (vendor consolidation), finance (usage-based bills), and senior engineers who prefer to build or stick with open source.

Signs the deal isn't real

Only individual engineers are engaged and nobody can name who owns the budget.
"We are just looking" with no trigger event, no deadline and no current pain they can describe.
The champion cannot get you time with security or the platform lead.
They want a free proof of concept with no success criteria and no end date.
The real goal is a pricing benchmark to beat up the incumbent at renewal.
A reorg or platform rewrite is pending and nobody knows who will own the tool after it.

26 words DevOps and developer tools buyers use

CI/CD: Continuous integration and delivery; the pipeline that builds, tests and deploys code.
IaC: Infrastructure as code; defining cloud resources in files such as Terraform, OpenTofu or Pulumi.
Platform engineering: A team that builds paved roads and self-service tooling for other developers.
Golden path: The supported, opinionated way to build and ship a service.
IDP: Internal developer platform or portal, often built on Backstage.
DORA metrics: Deploy frequency, lead time, change failure rate and time to restore.
Toil: Repetitive manual work that adds no lasting value.
Drift: When live infrastructure no longer matches what is in code.
Shift left: Catching security and quality issues earlier in the pipeline.
SBOM: Software bill of materials; a list of components in a build.
Runner: The compute that executes pipeline jobs, hosted or self-managed.
Monorepo: One repository holding many services or projects.
On-call: The rotation of engineers who respond to incidents.
Blast radius: How much breaks when a change goes wrong.
How do you handle Terraform state?: Terraform keeps a file that records what it built. That file is the state.
What about state locking?: A lock that stops two people changing the same infrastructure at the same time.
How do you deal with drift?: Drift means the live cloud no longer matches what the code says.
Which remote backends do you support?: The place the state file is stored, like an S3 bucket, instead of a laptop.
How do you handle a multi-account setup?: Running many separate cloud accounts, for example one per team or environment, instead of one big one.
Do you build landing zones?: The starting setup of a cloud: accounts, network, access and security rules, ready for teams to use.
Do you support OIDC?: A standard way to prove who someone (or a pipeline) is, without sharing passwords or long-lived keys.
How do you handle least privilege?: Give each person or tool only the access it needs, nothing more.
Do you support SCIM?: Automatic adding and removing of user accounts from the company directory, like Okta or Entra ID.
What is the blast radius if something goes wrong?: How much breaks if one thing fails or one mistake is made.
Do you support golden paths?: A ready-made, approved way for developers to build and ship, so they do not start from scratch.
Can we enforce policy as code?: Rules written as code that run automatically to block changes that break them.

Selling DevOps and developer tools: questions

What objections come up when selling DevOps and developer tools?

The most common are: "This is more expensive than what we pay now", "Migrating everything would take forever", "We built our own and it works fine", "Now is not a good time. We are in the middle of a big project", "Security will never approve a tool with access to our code and cloud" and "We already use GitHub for that". Each one above has a line to say back and what to avoid.

What discovery questions should I ask a DevOps and developer tools buyer?

Start with: Can you walk me through the last change you shipped, from commit to production? Where did it wait? If I asked your developers what slows them down most, what would they say? When that breaks or slows down, what does it cost the business? Who notices first? What changed that made this worth looking at this quarter instead of next year?

Who are the main competitors in DevOps and developer tools?

Buyers most often compare JFrog, Datadog, Harness, CircleCI, CloudBees, Snyk, JetBrains and Sonar.

Who buys DevOps and developer tools?

Economic buyer: VP Engineering or CTO for platform-wide tools. A director can often sign team-level tools on a card or a small order.

How does Ghost help on DevOps and developer tools calls?

Pick the DevOps and developer tools market pack in Ghost's setup and every card on this page loads into Ghost. When a buyer raises one of these objections or names one of these competitors on a live call, Ghost shows you what to say on your screen, hidden from screen shares and recordings.

Other markets

CRM Cybersecurity Cloud infrastructure Data and databases Observability ERP Collaboration HCM and payroll Analytics and BI ITSM and IT operations Supply chain Marketing automation Contact center and CX Finance and spend Ecommerce PLM and CAD Healthcare EHR Payments and POS Applicant tracking

DevOps and developer tools: what buyers say on the call, and what to say back.