Helping the buyer buy

Over the weekend, I had two long conversations with friends building early-stage companies.

One was working with a handful of design partners who said they were getting value from his product; the problem was that those relationships weren’t converting into paying customers.

The other had spotted an opportunity through work he was already doing as a contractor for an organization he had a great relationship with. He’d started building a product around it and was preparing to onboard a user – the person he was closest to on a team of twelve.

Both products had clear potential to help their prospective customers. Both conversations ended up focusing on how to make the most out of those relationships: how to demonstrate value, involve the right people, and help the customer build a case for buying.

I’ve supported go-to-market in different roles in startups over the last six years, and I’ve encountered parts of this problem myself. In particular, I know how difficult it can be to sell when you don’t yet have evidence from a customer using your product.

“Do you have a case study?”

My first ever "real job" was as a business development manager cold-calling and cold-emailing prospective customers.

In the first or second conversation with a prospect, it was almost certain this question would come up: do you have a case study?

We didn’t. The founders had deep expertise in the subject, and we could demonstrate the product and explain the value we believed it could create. But prospects wanted an example of that value being delivered for a real customer – which is totally fair. They needed something they could take to their stakeholders, but we were still asking someone to go first.

Getting that first customer was very difficult, but eventually someone took a chance on us. Once we had customers using the product, we created case studies, and those became extremely helpful in subsequent conversations – including during cold outreach itself as we now had numbers we could use.

This was part of what I wanted my friends to think about. At the end of these engagements, what would they have that could help someone justify buying? A promising demo gets you somewhere, but people are putting their organization’s money and their own reputation behind a decision. They need more than “trust me, bro.”

Being assigned a project doesn’t make you a champion

Creating that evidence would depend on people inside the customer’s organization helping the engagement succeed. With one of my friends, we discussed whether the person responsible had a reason to do that.

His commercial co-founder had initially been speaking with someone who, from what he described, I understood to be the economic buyer. They were interested in exploring the product and delegated implementation to a subordinate. My friend, the technical co-founder, then became responsible for working with that person to execute the design partnership.

My friend said the person wouldn't necessarily be a blocker, but it sometimes took four follow-ups to get a reply. I then just asked my friend why it was in this person’s interest for the project to succeed. Had he spent any time getting to know them beyond discussing implementation?

You never know. Maybe they hated their boss. Maybe this was another project added to their workload without anyone asking their opinion. We didn’t know, but being responsible for delivering something doesn’t mean you’re personally invested in its success.

My suggestion was quite literal: hop on a plane, go meet the guy for a coffee, and spend some time with him. You could learn much more about his priorities over an hour together than across multiple thirty-minute project calls where the person knows they're being recorded.

If he wanted this engagement to be different from another project assigned to that person, he needed to understand what they cared about. How could the project’s success also become a success for that person?

That relationship mattered because my friend would need their help involving users, gathering feedback, and moving the work forward internally. His co-founder handled business development, while he handled the technical work, but the commercial relationship still needed attention after the introduction. Opening the door was only part of it.

“They’ll have all their reports in one place”

Getting someone invested in the engagement also means agreeing on what it should accomplish. That was a bigger part of the conversation with my other friend, who was preparing to put his product into a user’s hands.

I asked how the customer would benefit. He replied that the customer would be able to see all their live dashboards, queried from a warehouse, in one place.

That did sound useful, but why did it matter? Would people spend less time searching for them? Would it make another part of their work easier? Having reports in one place described what the product did. We needed to get to the improvement the customer would care about.

As we talked, he described other benefits too. Those were the things I suggested agreeing with the customer upfront and tracking during the engagement. If the product was going to save time, for example, how long did the work take today? Without that baseline, agreed with the customer, we’d have nothing to compare the results against.

I suggested choosing a few meaningful success criteria together; three would likely be enough. Both sides needed to understand what they were measuring and why it mattered to the user, so they could discuss the results at the end rather than rely on a general impression that things had improved.

Those results would then need to support a business case. Saving time might create capacity, speed up a process, or remove a bottleneck. It doesn’t automatically mean the organization can recover the equivalent amount in cash. The buyer needs to understand what the improvement changes and why it’s worth paying for.

They need to know when it ends

That discussion also needed a point at which everyone would look at the results and decide what to do next.

My friend planned to onboard one user and hoped others would see the value and join. I asked where that process would end. He was thinking about the end of the year, but that hadn't been discussed with the user.

The problem with indefinite ‘trials’ is that they don’t force a decision. A lot of people say they enjoy something until they have to choose between giving it up and paying to keep using it.

I suggested a period long enough for meaningful use, with time at the beginning for onboarding and at the end to discuss the results. Depending on the product and what they needed to test, that could be four to ten weeks of live testing.

During that period, I’d want regular conversations with the relevant group of users, rather than rely entirely on one enthusiastic person. What was improving? What wasn’t working? What needed to change?

That would give him feedback to build with and evidence to discuss at the end. It would also let the users see how he responded to their problems. When users raise an issue and see it resolved a week later, they get a positive impression of what working with the company is like.

We also discussed what kind of engagement he was proposing. A design partnership can involve discovering problems and shaping the product together. A proof-of-value pilot would test a more defined proposition. There can be overlap, but the customer should understand which questions are being answered.

Where the purpose is to demonstrate enough value to support a purchase, I’d ideally want the conversation about production to start before the pilot did – even though, yes, that's hard. Who would make the decision? What evidence would they need? What approvals would follow? Could the commercial terms be discussed upfront?

He’d been considering a product-led approach, where users would start using the tool and adoption would grow from there. But his product needed access to organizational data. Even at the startup where I work, adding a plugin requires our CTO’s review, so there were likely technical and organizational approvals to understand alongside user enthusiasm.

He had an in-person meeting with the prospective customer’s CTO coming up – that was a great opportunity to discuss a wider proposal, including how the engagement would run, for how long, and what would be needed to move beyond it.

Negotiating a production agreement before someone has used the product can be difficult. But if meeting the agreed criteria would justify continuing, it makes sense to discuss what continuing would involve. This is also in the interest of the customer, as it reduces the gap between seeing value and then continuing to benefit from it. Otherwise, you can finish demonstrating the value and only then discover the buying process.

And what about the relationships already running?

My other friend couldn’t go back and have these conversations before his engagements started. Some had already been running for weeks or months, without a clear sense of when they'd turn into paid relationships.

I suggested going back to those prospective customers and agreeing on an end date.

Understandably, he was worried they might leave when that date arrived. That concern made sense – they were using the product and ending the arrangement could mean losing them. But continuing indefinitely wasn’t telling him whether they would ever become paying customers, and free trials don't prove product-market fit.

The date needed to be part of a conversation about what was still missing. What did they need the product to deliver? Was there a particular result or improvement that would make a paid relationship worthwhile? How could his company help them get there? If the prospective customer could describe that, there was something concrete to work toward. If they couldn’t, he needed to understand why.

The customer leaving at the end wouldn't prove they could never have bought. However, keeping the engagement open while avoiding that conversation oftentimes leads to more and more work without understanding whether there’s actually a purchase to work toward.

Give the next customer something to work with

We also discussed what the founders should ask for in return for the work they were putting into these engagements.

For a pilot, charging a fee is more than fair, and it helps with understanding whether people would really pay for your product. To help create the right incentives on both sides, it's possible to credit the pilot price against the first year of a production agreement.

For a design partnership, doing it for free can make sense, too, especially when you're at an early stage, and the customer can – in a well-structured design partnership – provide meaningful feedback to help shape the early product.

Either way, regardless of the model, both sides needed to understand what they were contributing and what they expected from it. If the engagement produced useful results, I suggested discussing a case study as well. Many customers will agree to participate without asking for anything in return, especially if you've developed a great relationship with them, but a small discount could also be worthwhile in exchange for the customer’s participation and permission to publish an honest account of the results.

Having a few examples across different kinds of customers gives the next prospect something concrete to examine. Who used the product? What were they trying to achieve? What improved?

That brings me back to those early conversations in my first job. Once we had customer evidence, we could help prospects answer questions that a demo alone hadn’t resolved. It also created social proof for outbound efforts.

The structure I suggested to my friends was intended to help them create that evidence while making the engagement worthwhile for everyone involved. The person vouching for the project needed a reason to invest time in it. Users needed an improvement in their work. The buyer needed evidence to justify the spend. The founders needed feedback and a path toward a paying relationship.

A schedule and a few metrics won’t guarantee a sale, but agreeing on the outcomes, responsibilities, and next decision gives people a way to work toward something together, rather than assume that usage will eventually become a purchase.

When you’re asking someone to put their budget and reputation behind your product, helping them build the case is part of the job.