The person who pays for your product is not the person who wants to use it. The person who wants to use your product is not the person who can pay for it. The product experience is not instant. Welcome to the world of B2B software. How do you proceed? Here's a story about that.

You are a starting B2B software vendor (I know, it's a startup). Your product offers a DSL based approach to data integration that plays nice with modern development tooling like CI/CD pipelines and version control. Sounds good, right?

After a lot of crunch time you feel that your product is ready for prime time (it isn't, but don't worry, it never is). You are eager to hit the road doing sales. Actually you have already managed to schedule a first meeting with Susan, the head of IT of medium sized logistics business who would greatly benefit from your product. Susan also started her career as a developer so you should have no problem convincing her of your technology's superiority over existing tools. Armed with slides, a product demo, and your unrestrained enthusiasm you enter the meeting. The demo goes great and Susan nods in agreement with all of your technology choices. After the meeting you follow up with an email to recap your product's potential and outline next steps. You're taking off!

And then she never gets back to you.

Much later you learn that Susan asked one of her senior architects, John, about your product. John would be a prospective user of your software, but apparently he had never heard of it so nobody thought it was important.

As it turns out, Susan is not the user of your product. For her it doesn't matter how it solves the problem. For her it matters more whether the problem exists in her organisation and whether it is worth solving right now. John is a more hands on kind of person. He needs to experience something first hand before he will even consider it.

As a B2B vendor, you need to be aware of the following:

• The person who pays for your product is not the person who wants to use it.
• The person who wants to use your product is not the person who can pay for it.
• The product experience is not instant.

Let's have a look at how to deal with this.

Turn your Users into your Champions

Next time you talk to Susan, you want John to be well aware of your product and why it is important. Consider these 6 phases for turning prospective users into your product champions.

1. Create buy in for the idea

Before John can consider your product he has to first consider the idea of using a DSL for data integration projects as opposed to all the GUI based tooling that dominates this space. The best way to achieve this, is to conceptualise and sell your audience the concept before the product. This is why nobody is telling you to "make API calls to AWS using a declarative scripting tool" but instead are telling you to "move your IT to Infrastructure as Code", which is way more awesome because a person at a conference gave a talk about it. Similarly, nobody is telling you to run autocorrelation on your infrastructure metrics but instead are talking about AIOps. The latter term is also more convenient in conversations with people who don't know about autocorrelation or infrastructure metrics.

Here is your playbook:

• Invent the concept: Code Based Integration Engineering (it has all the robustness of data integration tooling and all the modern agility of software development; yay!).
• Write a thorough sounding article full of industry jargon explaining why Code Based Integration Engineering is the new way of doing things and what business and process benefits it will bring.
• Start a Code Based Integration Engineering meetup group in any location that you care to do business in.
• Become a member of every data integration LinkedIn group and other relevant online community that exists and make people aware of the disruption of Code Based Integration Engineering that is about to hit the market (be sure to discretely point out that article, but definitely mask your post as an honest question and not a piece of marketing copy).
• Get invited to a conference as a speaker on Code Based Integration Engineering.

If you are getting annoyed by how often you just read Code Based Integration Engineering then you get the point. The next time Susan asks John about your product, he needs to tell her: "Yeah, they do Code Based Integration Engineering. There was a great talk at a conference about it. I really think the world is moving to that paradigm.".

Serverless Computing, Containerisation, and Infrastructure as Code were all invented to sell software products. (Really, containers are a packaged combination of CGroups and kernel namespaces.). They provide your audience a more convenient way to talk about products.

This isn't new. And this isn't tied to tech. Generally accepted concepts make it easier to tell people what you do. Ride hailing (Uber, Lyft, etc.), social network (FB, LI), and coworking (WeWork) are concepts. They help convince users that they are doing more than just getting a cab, messaging a friend, or renting a desk. But sometimes humble software engineers are not naturally inclinced to think of their tool as more than just a tool. Show some grandeur and invent a concept that elevates your tool to something that your users can champion. If the concept already exists (in which case you are competing with others), get on the bandwagon and try to become an authority in that space.

2. Product experience

Show your product. Really. However complex it necessarily is, however hard the first use is, however tricky the initial setup is, people need to experience your product in some kind of way before they can be a champion for it.

Unfortunately, it is not equally trivial to allow a user to test drive for all software. Some software requires complex integrations in order to be useful. Sometimes tedious setup is needed. Understandably no one is going to go through a complex on boarding just to get a demo. To conquer this, consider different levels of product experience and gradually work your way through them.

Passive experience

The most basic and arguably the worst way to experience a software product is through a slow spoken, poorly edited, non-annoted screencast. One of those which require you to actually get out your headphones to listen while trying to cleverly skip forward in the video without missing important bits. And still, this is better than a feature list and a screenshot. You can understand why; your software's look and feel is hard to communicate in most other ways. There is literally no excuse for not getting that 30 day trial version of some screencasting software, setting yourself up in a quiet space doing the best you can to sound like a professional voice actor. Thinking "my app should always be presented in a live demo" is a great way to narrow the top of your funnel. Get over it. Show your goods.

Other options for passive experiences that you can provide are:

• annotated videos, because people mute things
• detailed blog posts on how to succeed at particular tasks, because people search for "can you do X with product Y"
• leaving your product documentation open, even for proprietary software
• webinars, because in spite of what we all think, they actually work (why do you think they still exist)

Active guided experience

Did you know you could join a FREE Couchbase NoSQL Workshop in Paris:

At this FREE daylong event you’ll have one-on-one access to your local Couchbase experts and learn how to get more out of your NoSQL database through technical presentations and hands-on experience with Couchbase’s most powerful features.

What you see here is a software vendor creating a guided active product exprience for John and his colleagues. I can tell from experience that these kinds of sessions are almost exclusively attended by software architects (decision influencers) and freelancers (people without a real training budget). In the former category, experience with your product will be limited to reading about it. This is their first time actually taking it for a spin. Unfortunately you have to book a conference room at some chain hotel and buy everybody lunch to get to that point.

Another venue for active product experiences are conference sponsor booths where you can do live demos. They are more expensive than conference rooms and keeping attention is tricky, but the conference should take care of delivering you an audience.

Actual use

Finally John is going to get hands on with your DSL himself. He downloads the free trial and works through the tutorials.

Depending on the amount of required onboarding to make your product work, trial editions can range from downloadable and ready to run on one end to uniquely provisioned hosted demo environments with ready to use test data and adjacent services running on the other end of the spectrum. Either way, you have to create a trial experience for your prospects. Even if you have to setup hosting and automate deployments for it. Don't assume anyone is going to integrate your product into their existing setup just to give it a spin.

3. Building confidence

John is going to take a stab at rebuilding one of the internal integration processes using your DSL. You will obviously help him succeed through your community support. He can now become an ambassador for your product. At this point he is likely to showcase his success to colleagues, mention it over lunch with others, or start a discussion on internal channels (e.g. #interesting-tech on the company Slack).

4. Struggle

Next thing you know, someone in another department than John's is asking whether your integration solution can deal with XML that has encoding issues in a non standards compliant way. This is important, because many of the older systems produce XML using string concatenation and have a hard coded encoding in the header which isn't actually used when creating the document body. In their existing tool, there is a check box that allows to skip over parser warnings and minor errors.

If this sounds far fetched, think again. You're in enterprise land now. String concatenation is a perfectly acceptable way to create XML or JSON. Either way, you will hit something like this. Luckily, this presents a great opportunity for John to learn the more obscure configuration features of your product. Just be sure to be there with support when the struggle happens.

5. Power use

Whatever the issue, John's got a solution. Anything the existing tooling can do, John can do in a superior way using Code Based Integration Engineering. John even figured out a more elegant way to handle those off-standards XML files and he shared it with community support. You invite him to speak about it at the local Code Based Integration Engineering meetup.

6. Lock in

The obvious next stop is that John can no longer do his work without your solution. At this point changing course away from your product will incur a cost and will make people unhappy, since they spent a lot of effort becoming power users. Your work here is done.

Turn your (Prospective) Sponsors into Success Stories

Somewhere along the timeline of John's journey to a product champion, Susan will have to actually buy the stuff. Her phases of engagement with a vendor are completely different from John's. As noted before, it all starts with the realisation that there is a problem in need of a solution.

1. Urgency

What acute multi million dollar risks is Susan exposed to by not preparing for a future with your product in it? She has an entire team of integration specialists who are already expensive enough without additional licenses, re-training, and hours lost in re-implementing what already works. She has projects to deliver. She has DDoS attacks to worry about. She has a challenge hiring people for even the most basic roles. What's one good reason to have a conversation about integration? Well, here's a couple:

• Old school integration specialists are a dying breed; if you don't evolve to Code Based Integration Engineering, no sane person graduating in the 21st century will work on your integrations.
• In this world of ever increasing complexity, timely delivering on integrations is a must to stay competitive. Your "research" has shown that Code Based Integration Engineering can save up to 50% of the lead time on new integrations and reduces the maintenance burden significantly (you know, significant is a word you can liberally use as long as there is no information on sample sizes around).
• A recent survey among senior developers shows that moving to Code Based Integration Engineering would make working in the integration layer more attractive to them.
• In the days of DevOps and Cloud, integration layers without CI/CD will not stand the test of time.

In other words, Susan's current way of doing integration is the next COBOL. It is going to cost millions to maintain these systems and there will be no people left willing to even touch them five years from now. On top of that, things will not be Agile (TM). This is the inevitable future if Susan doesn't get on board with Code Based Integration Engineering and it is your job to make her very afraid of that future. This is why at executive dinners there is always the invited speaker who has already moved onto the greener pastures of, in this example, Code Based Integration Engineering. He will talk about the dark days when they still used to do things the old way. He will be patronising towards his peers like Susan, saying things like "Ah, you are still on old integration development. Yeah, we used to do that too.". Some time later, you want Susan to be the speaker at one of those executive sessions as well (see #6 below).

2. Validation

Did you know that Slack supports eDiscovery? Well, it does. Do you know what eDiscovery is? Susan does. And that's why that check mark for eDiscovery is right there when you visit the Enterprise page of the Slack website. It has something to do with legal and that check mark is important for Susan's career. There are more check marks like it and you need to tick them all. Once again, Susan is not likely going to ask how you implement the check marks as long as they are there. Your sponsor will have a check list that basically determines which products can not be purchased for compliance or policy reasons. If there are multiple products that check all the marks, then comes pricing and finally comes what the actual users prefer. Make sure to check the boxes and have the check list prepared. Slack's Enterprise page is actually a great example. It states the concept (the collaboration hub for connected enterprises), it shows the check list (including support for eDiscovery), it showcases a number of reference customers, and it iterates a list of problems that Slack attacks (e.g. "build bridges between teams"). Most importantly, it does not mention a single product feature of Slack.

Don't worry. John will only visit your enterprise page once Susan hands him the check list for validation.

3. De-risk

At this point Susan starts to understand that doing business with you is a likely outcome. Unfortunately for her, there is no way of knowing ahead of time whether the long term impact of using your product will be net positive for her organisation. As such, she will try to maximally de-risk the decision legally, financially, and operationally. That means that every agreement that you make on paper will be scrutinised by the legal department. Next, Susan will minimise her exposure to your product for the first deployment, asking for the smallest of all possible Proof Of Concept projects that would show a hint of your product in action, and she is going to assign you the least amount of internal resources for your Proof of Concept that she can get away with.

Keep in mind that at this point you are already negotiating. Legal is going to ask you to drop certain things from your Terms and Conditions. Know in advance which items you are prepared to drop and which not. Customers will always ask you to do a Proof of Concept at a loss. Know in advance how much you are prepared to spend and if you can, put in the contract that you will only take the loss if there's a subsequent larger sale. Also understand what you need from the customer to make your Proof of Concept a success and make sure those resources are allocated to you; don't get setup for failure. If a customer crosses the line on any of these, you will have to tell them no. Failure is typically a worse outcome than not trying for things that you only get to try once; you can try later.

4. Confidence

Now we need to make sure that Susan builds confidence in your product. This is what customer success management is about. During the initial engagement, their job is to make sure that any bad news or experience that John may have gets tackled before it reaches Susan. John needs to be a happy user and he needs to deliver on his internal promises by moving to the bright new world of Code Based Integration Engineering with your product. It's hand holding time with your users to make sure your sponsors remain confident in the outcome.

5. Claim success

The Proof of Concept was a success. The product is gradually moving to production use. Users are happy they got their new thing. John was promoted to Lead Senior Architect. Most importantly, Susan is happy to exclaim that their innovative move to Code Based Integration Engineering with your product was a great idea and an even better executive decision. She needs a stage to make her peers aware of this success and it is your job to provide it. Susan should be the next speaker at your breakfast seminar, your executive dinner, or some important enough IT management conference. The bigger and more important the audience, the better. This is good for your sales, and her career and network. Win-win!

6. Operationalise

Susan has claimed her success, the systems are humming along nicely. It is time to move on to the next thing. The account contact for this customer is to be moved from Susan to the manager of the integration department. He will now have the honour of annually approving the renewal of your licenses. (Until, of course, the time has come for AI Powered Integration Automation, which is likely to coincide with the mass adoption of self programming computers.)

Conclusion

There are two audiences that require two different approaches on two separate timelines that you need to both progress and keep aligned. Don't push hard for a sale if you don't have a champion yet. Don't over invest in community engagement with an organisation where you have not identified and engaged with your sponsors. The common thread for both audiences is the concept and its implementation that you are selling, but the conversations are vastly different. Often you will have both parties in the same meeting. When that's the case, be sure to also bring both counterparts from your end (e.g. sales and customer success / pre sales engineering).

If you think that some products are so great that they can just sell themselves to relevant businesses, keep in mind that at the time of this writing Slack has about 1800 employees of whom 750 (42%) work in sales roles (source: LinkedIn search). Of course they get online signups from businesses that they hadn't even heard of, but for the contracts that matter substantially to the bottom line, every product business needs a sponsor and a champion.

P.S. If you care for a DSL based approach to data integration, check this out.