Adoption Engineering

Founders are familiar with sales cycles. They plan around them, model them in their forecasts, and track them in CRM dashboards. But there’s a second timeline running in parallel that often goes unnoticed: the adoption cycle.

Sales cycles tell you how long it takes to close a deal.

Adoption cycles tell you how often customers are even ready to consider change.

It’s not the same thing.

Not every customer is in market.

Some categories see regular movement—annual tooling refreshes, budget-driven evaluations. Others shift more slowly—one big decision every few years, often tied to leadership changes, compliance shifts, or major infrastructure upgrades.

When a team just rolled out a new system 18 months ago, the bar for switching is higher—regardless of how good your pitch is.

This is especially relevant in brownfield markets, where customers already have a solution in place. It’s not just about proving you’re better; it’s about catching them at the right moment to even consider moving.

Timing matters as much as fit.

In greenfield markets, the challenge is education. In brownfield ones, it’s timing. Even with clear pain, there’s often a window during which adoption is actually possible—driven by budget cycles, roadmap shifts, or external pressure.

Ignoring that timing can lead to a long tail of conversations that never convert—not because the product isn’t relevant, but because the buyer isn’t ready.

A simple shift in approach

Adoption engineering means asking a few slightly different questions upfront:

• How often do customers in this category adopt or switch?

• What tends to trigger that adoption?

• Where are the natural windows for consideration?

• Are we in a greenfield or a brownfield—and what’s the real cost of entry?
  

It’s not a replacement for sales thinking. It’s a complement to it. And for teams building into new or replacement categories, it can be the difference between slowly grinding forward… and aligning with momentum that’s already there.

Exploratory Markets vs. Buying Markets

There’s a very important distinction with regards to how we research markets between an exploratory market and a buying one.

An exploratory market = most of the interest among potential customers is focused on researching the subject matter while they’re still in the early stages of understanding how deep the pain actually is within their organization. More often than not, it’s also not just about understanding the pain depth but also what an actual solution architecture might look like and which one would best fit their organization and existing workflows.

A buying market = a more mature landscape where the pain/solution equation is much clearer. Customers are coming to conversations with vendors with ready-made budgets, priorities and at least a rough idea on how their ideal solution may look like.

Obviously, there are many shades of grey between the two - the dynamic here isn't binary.

Founders may struggle, in the beginning, to differentiate between these possible states of the market, since many on the customer side don’t identify themselves clearly as explorers vs. buyers. It’s critical to understand at which phase of the maturity of the buy-side we are currently, as this might indicate whether we’re too early or too late to the ‘party’.

4 Observations on Interviewing Buyers

1. Share insights before asking for priorities - The common approach of going to a potential buyer and trying to figure out their top 5 pains without prior context is not as effective as it might have been a few years ago. Buyers are quite tired of founders coming to interviews without a clear agenda and original insight. This has never been very effective anyways. Most buyers need some form of inspiration from the founders before they share their priorities. The ideal formula is focusing on a sub-domain, sharing differentiated insights (at least initial ones) on this sub-domain’s dynamics and having a priorities-led discussion flowing from there.
   

2. Attention span is key - The fact that there’s a pain/inefficiency existing within a certain team does not necessarily mean that it’ll be a part of its agenda for the coming months. In the end, you need to figure out buyers’ strategic attention span on top of whether an issue exists. The difference between urgency and importance is naturally relevant here. Also, whether a team has already carried out a heavy-duty implementation project in this domain in the past 2-3 years would also likely deter it from going after a new one.
   

3. C-level buyers vs. working-level buyers - Who should you interview and convince, the C-level buyer or the team lead? The answer is often both. It’s usually a good idea to start with the C-level buyer, if that’s available to you. But more often than not, you’ll then be referred to the working-level user/buyer, whose approval you’ll also need to obtain. So your pitch and approach should appeal to both levels.
   

4. Workflow disruption - Ideally, your solution won’t cause too much disruption to the current workflows of your target users. The elegance in which you can provide your solution - especially during the POV (proof of value) phase - is key. And by elegance, I mean maximizing value while minimizing discomfort. Try and figure out the path of least resistance in the road to adoption.