This is how I work, in two parts. The first is about selling technical expertise, which is most of my job. The second is the broader set of principles I bring to any team or project.
Selling technical expertise
Technical companies rarely lose a deal because of the product. They lose it because the buyer can’t explain the decision to the people who approve it. These five principles are how I work on that problem. They come from solution selling, adapted for technical sales.
1. Start with their problem, not your product
The first conversation is about the buyer’s operation: how it runs today, where it breaks, and who deals with the fallout. Hold the product back until you understand that. Show it too early and the meeting turns into a demo.
2. Make the cost of doing nothing visible
A good product isn’t a reason to change. People change when the current way costs too much. Put a number on it: downtime, rework, hours of manual reporting, a quote that takes two weeks. Without a cost, there’s no reason to act now.
3. Map who decides and what each of them needs
A plant manager, an IT lead, and a CFO look at the same system and care about different things. Tell the same story in a way each of them understands. Find out who signs, who can block it, and who has to use it every day.
4. Translate features into daily work
A feature list says what the product can do. The buyer wants to know what’s different in their day once it’s running. End every technical point with what it means for the operator, the manager, and whoever owns the budget.
5. Give your champion a story they can retell
Most of the decision happens in meetings you’re not in. Your contact has to explain it to people who never saw your demo. If they can’t do that in a couple of minutes, the job isn’t done.
What this isn’t
It isn’t a pitch deck, a script, or more product training. Your technical people already know enough. The work is helping them turn what they know into a story the buyer can pass on and defend.
How I approach the work
Outside the sales conversation, these are the principles I return to when building a team and running the work. They’re not universal truths, but they’ve held up across enough projects that I trust them as a starting point.
Small teams move
Fewer meetings, faster decisions, nowhere to hide. One person who builds and thinks is worth a team that only coordinates. The best work I’ve seen came from small, focused groups where everyone understood the outcome and had the autonomy to reach it. Scale the team only when the constraint is capacity, not clarity.
Visibility creates alignment
When teams can see the same work, the argument changes. It stops being about who said what and starts being about what’s actually happening. Shared visibility doesn’t solve every disagreement, but it removes the ones that exist only because different people have different information.
The constraint is often imagination
Most companies underestimate what’s possible with what they already have. The people, the systems, the data, the relationships: there’s usually more leverage in the existing situation than anyone has mapped. The gap isn’t always resources. Sometimes it’s just the belief that things could work differently.