I wanted to explore the updates, so I reached out to the company to begin the conversation. I’ll start out by saying that this experience wasn’t frictionless or easy from end to end—I still had to jump through the hoops of forced sales calls, etc.

In fact, one of the most frustrating parts of the experience was that the disparity between pricing listed on their site and the pricing the salesperson offered was significant. It ended up being cheaper than what was publicized, but knowing that ahead of time would have saved us a good amount of time doing research and sitting through sales calls.

In spite of all of those things, though, the company did two things that completely turned the purchasing experience around.

Product Engineer As Sales Rep?

The first thing that I noticed was that the SaaS company had a former product engineer join the sales person for parts of the sales process.

You don’t typically think about a software engineer for a product being a major component of the sales process, but, reflecting on it after the fact, I realized that it was a brilliant move. Someone who has worked on a complex SaaS product has felt the pain of trying to understand users’ needs and build something that solves their problems.

I would guess that the engineer on the call had far more experience-based empathy for interested customers like than the actual sales rep—not because the sales rep didn’t care, but because sales people don’t have to actually build the product that is used, so they aren’t as close to the practical problems companies are trying to solve.

The product engineer was truly the one who ‘sold’ me on the new features of the software I was interested in exploring. In fact, once we started talking, the sales rep barely said a thing for the rest of the call.

The Best Product Demo I’ve Ever Seen

The actual demo of the new features, though, was truly impressive. With demos, I’ve come to expect a walk through of a templated setup of the product, with explanations of how certain features might work in the context of my company (or the one I’m representing).

The engineer didn’t walk through a templated example. He didn’t even mention similar customers as “proof that the product could work” for us. He simply showed me exactly what it would be like to run the product in the actual business.

Here’s what happened: before the call, the product engineer went through and looked at the eCommerce site and app we wanted to use the tool in and mapped out a handful of user flows that were obvious drivers of the business. He then stubbed out a data set—a large data set—that modeled those flows with some reasonable assumptions on conversion rates..

The result was that, when he opened the product in the demo, I almost immediately saw the specific value the software could add, because I felt like I was looking at a dashboard for the actual business. I knew the data was fake, but I wanted it to be real. In previous product demos, I’ve found myself saying, “I want something like that.” In this demo, I wanted the specific dashboard the engineer was showing me.

The initial impression was significant, but the rest of the demo was even more powerful. Having a data set that mimicked the actual business, even if not perfect, meant that the person doing the demo didn’t have to explain what features could do—those were much easier to understand because I’d spent so much time looking at the business’s data in other contexts.

Instead, he showed me how to use those features to solve specific problems that the business probably faced. Then, after one or two examples, he asked me what specific problems we were currently working on, then proceeded to show me how to use their software to tackle them.

It’s All About ROI

I learned many things from that demo, but one thing in particular that really stuck out to me was how that product engineer took the time to stub out an example with data that closed the gap between features and ROI.

I leave most demos still wondering if the investment of time and money will actually live up to the promises. By the end of this particular demo, I’d already done the mental math on how much we could save in time alone using the tool to solve the handful of problems we’d walked through, making my internal sell to purchase the tool quick and easy.

In my experience, most sales reps are interested in describing features and talking about ROI in general, or giving cherry-picked examples of ROI from other customers.

Features are great, but at the end of the day, someone has to justify the cost of software and that always results in a discussion about ROI. The less imagination a prospect has to use to project ROI, the easier the sale is—both for the sales rep and internally for the purchaser.