Companies often don’t want external developers on their team. Does this objection sound familiar? You offer software consulting services, on-site or even remote. But new clients don’t bite. The question is: How do you sell consulting services? What’s the secret? How do you build a full sales pipeline for your software development consulting firm?
Let’s take a step back.
Who is Your Customer?
In general, it’s a company with software developers on staff is producing some software. Things are working for them so far. But surely, somewhere in the system must be workflows that don’t work as well as they could. It could be inefficient hand-offs between Dev and Ops, inaccurate testing, or the lack of code quality.
You have solutions for all of these problems. Yet, every time you discuss possible issues like these with executives, they wave them away. It’s not of any concern, or at least it wouldn’t warrant a consultant in the first place. They might bring up objections such as “It’s too expensive right now,” or “I don’t see why I should spend so much money on that kind of problem.”
On the other hand, their developers are grateful for all available help to address their ongoing problems. It’s weird. Developers want to work with you, but their bosses are not interested at all.
The problem is two-fold. For one, executives might not understand how an inefficient hand-off between Dev and Ops affects their business metrics. A CEO uses a different frame of reference they base decisions on than a developer or engineering manager. A developer might care about successful deployments, code quality, and as few bugs in production as possible. You could argue a CEO also cares about successful production deployments, bug-free and stable software, but for different reasons. The CEO is concerned with revenue, the competition, and shareholders.
Therefore, the question must be: How does your work, a few levels below the CEO, relate to C-Level business goals?
If you ask the developers why they want to work with you, they will say, “I trust you,” “I’ve seen your work on YouTube, your blog, or through conference talks, and that gives me the confidence you have expertise.” If you don’t have that kind of presence, developers are not interested in what you have to offer.
Sometimes, it’s already enough if developers influence the budget owner on your behalf to get approval for a purchase.
But more often than not, the budget owner is not convinced. They don’t know and therefore don’t trust you. The result: No business. How can you build trust and rapport with the executive?
Building Trust through trials
The CEO or decision-maker doesn’t trust you. Therefore they won’t approve any spending. In the SaaS/product world, what do you do if you’re not sure if the product is worth the price? You try it. 14-day trial, 30-day trial, no credit card required, and off you go.
What’s the trial equivalent in the services world? One option certainly would be to work for free at the risk of devaluing your brand.
Another option: Offer a paid product or service but with a smaller scope: A paid Proof of Concept.
A Paid Proof of Concept Template
But why would that CEO spend money now if they weren’t up for it in the first place? Put yourself in their shoes.
Hiring an unknown consultant or developer agency is risky. They require an upfront financial investment where the Return of Invest might not be evident.
Over time, the investment will pay off. It’s often hard to measure in metrics such as revenue or customer retention to justify the engagement directly.
Therefore, to make an initial engagement more straightforward, let’s offer something smaller in scope with a well-defined investment return. For instance, this PoC could be a paid code review of a legacy component in their architecture or a new service concept that the team needs to integrate. There are plenty of opportunities.
Find out pain points
Often, to determine the right kind of value, you need to discover what problems are most pressing within the organization. It might be work related to a legacy system, developer onboarding, or collaboration between Dev and Ops. Once you found out about current pain points, you need to draw connections to business goals. What is most important to the decision-maker? What are their goals? And how does, for instance, a code review of the legacy service help to drive success? Make a compelling case.
Here are some examples of what to offer:
- What are some engineering projects that could become a problem or liability soon? (for instance, a legacy service)
- Deliver a piece of work the customer can continue to work with even if they don’t hire you again, or you can use it as a starting point in a more long-term engagement
- The scope is clear: Only one component, fixed timeframe, fixed price
If the business leader is still hesitant to spend money on a scoped project, they might not be the right client for you in the first place right now.
Proof of Concept – What comes next
Defining and offering the Proof of Concept is the first step. But what comes next? You are interested in a long-term consulting engagement. For that to happen, you need to be clear that the Proof of Concept is the first stepping stone. Ask your stakeholders for success/acceptance criteria. When do they consider the Proof of Concept successful? And would they be open to extending a consulting contract?
Large, upfront investments like a 12-month consulting contract make it difficult for new clients to say yes. If you don’t know each other yet, scope out a small paid project to get to know each other.
You get paid for your work, and your client has less of an issue to authorize spending.
It might take a bit longer to get to a long-term consulting contract. On the other hand, the reward is a sustainable business relationship.
You are already offering Proof of Concepts, but clients still say no? Get in touch here. Together, we will improve your existing strategy so it will deliver measurable results.