“Our job is to find the fit”: Transparency, trust, and the art of the Technical Sale

As the Technical Sales guru at Learnosity, David O’Sullivan combines an oceanic knowledge of our product suite with a deep-seated customer empathy.

Soft-spoken and sharp-witted, David O’Sullivan offers the calm self-assurance of someone who truly knows their stuff. With a diverse career portfolio that includes stints in construction, banking, and nightclub promotion, David is a font of wisdom and anecdotes. Here, he outlines the many dimensions of his role in Technical Sales and the trailblazing potential of the API economy in edtech.

From custom codebase to the cloud

You come from a tech background and ran your own business in a previous life. Can you give me a little more on your background as it relates to what you do at Learnosity? 

Yes, I co-founded and ran an ecommerce start-up for 6 years. We grew to a team of 25 across 5 countries but did not survive the global financial crisis. I wrote the initial version of the software from scratch before hiring a CTO and moving into a hybrid tech/business operations role. I enjoyed the cross-over role between business and tech and carried that on to Learnosity.

They say timing is everything in business, the API economy, in which Learnosity is now a major player, was in its infancy when we launched our startup. We ended up writing the bulk of the software to run our non-traditional ecommerce functions ourselves. We did use APIs for things like geo-location, forex and messaging, but spent a lot of time building and maintaining a custom codebase. 

In today’s world APIs could do a lot of that for us. It showed me the value and strength of APIs. We would have liked to spend our time on other things but needed to maintain that custom code for years. I see this same problem in so many of the edtech companies that Learnosity speaks to today.

Mind the gap: How APIs can bridge product chasms

Do you think that as a former business owner you’ve gained a greater sense of the kinds of challenges clients face when they decide to build solutions themselves?

Absolutely! I learned a lot about the benefits of leaning on others for core functionality. Standing on the shoulders of giants leads to a less stressful life, there is no doubt about that in my mind—it’s a lesson I learned the hard way. 

Because I run the Technical Sales function at Learnosity, I speak to founders of edtech start-ups on a daily basis. What I sometimes see is entrepreneurs wanting full control and ownership of their system and reluctance to use third-party systems.

Frankly, having full control and ownership of the code that provides the basic authoring, rendering, and reporting functions for multiple choice questions should not be the focus. Every competitor has that same multiple choice functionality, it does nothing to differentiate, and unless that founder has invested ten years of work and tens of millions of dollars into it, their version will be inferior to competitors who’ve embraced the API economy. 

No two prospects are the same. In Technical Sales, our job is to understand the client’s business objectives and determine if Learnosity can help them achieve those objectives. Share on X

It no longer makes sense for a founder to do that for multiple choice, then do it again dozens of times for 50+ other question experiences. It is expensive, greatly increases time-to-market, creates technical debt and, in today’s market, only provides entry-level functionality.

When you consider that our APIs also bring adaptive assessments, offline assessments, teacher-authoring, configurable auto-scoring, and in-depth analytics you get to see how far a startup will have to go on their own before catching up with those already using APIs. 

Let me give a quick example. On my first day in the Learnosity office in 2015, I sat beside an engineer who was working on a small problem related to drag and drop behavior in certain browsers. A highly talented guy, he spent three months fixing that issue. When an edtech startup has 100 such issues to fix, progress is slow. Relying on others for bug fixing, security, privacy, and uptime takes so much weight off edtech development teams’ shoulders and fosters innovation within their group.

On finding the right fit

What kinds of things are you looking for when determining if we’ll be a good fit for a client, and vice versa?

No two prospects are the same. In Technical Sales, our job is to understand the client’s business objectives and determine if Learnosity can help them achieve those objectives. To do that we need to understand the technology required to reach the client’s goals, as well as the client’s current technology, and then present a technical plan on how our APIs can make it happen. So, in short, the technical fit has to be there. Our job is not to make a sale, our job is to find the fit. If it isn’t there then we will stop the sale. 

The salesperson and the Technical Sales team have very different motivations. It’s our job to find the potential problems, a potential mismatch, before a contract is signed. We aim to be a trusted advisor for the prospective client, not a division of the sales team. Closing down a potential sale early, when the technical fit is not there, will save both parties a lot of headache in the end. 

One of the first things I do in my presentations is to point out what Learnosity is not. We are not a platform, we are not a rostering system, we are not a publishing tool. We are an assessment engine providing unmatched assessment capabilities across authoring, assessment, and analytics. If a client’s requirements fall outside of those capabilities, then the fit is rarely there. 

We aim to be a trusted advisor for the prospective client, not a division of the sales team. Closing down a potential sale early, when the technical fit is not there, will save both parties a lot of headache in the end.  Share on X

Our solution is a technical one, so the client needs to have a technical team available. It is essential to my work that those technical staff have an understanding of how modern APIs operate, so my process involves looking through code samples and talking through that code with the client’s tech staff. If they don’t have technical ability in their organization, we can provide it through our Partner Network.

The art of the Technical Sale 

Briefly talk me through what happens when you come into the process. What are the general steps you take prospects through?

The process begins when our sales and marketing teams have identified a prospect and opened a dialogue with them. As Learnosity is a highly technical, consultative sale, the process quickly moves to a technical discussion. That’s where I, and my colleague DJ, get involved. If that goes well we proceed to several additional calls, focusing on specific requirements, delving more into the code, and getting the client working on a proof of concept. Technical due diligence for both parties is critical.

I enjoy one-to-one conversations with our clients’ developers, helping them with code samples that might remove 70-80% of the code they would otherwise need to write and maintain. When working with developers, provided the technical fit is right, I truly feel like I’m providing significant help to them by making our APIs available to them. I know it will make their lives easier and allow them to spend their time innovating and creating something new and exciting.

What are the most important qualities of a good Technical Sales representative?

Being an attentive listener is a good start. We don’t want to present a monologue, it has to be a conversation. Being able to tease out the details of the client’s requirements—and hopefully unearth other areas where we can help, areas that the client had not considered—is only possible through conversation and listening. 

When working with developers, I feel like I’m providing significant help to them by making our APIs available. I know it will make their lives easier and allow them to spend their time innovating and creating something new and exciting. Share on X

Business development managers and authoring staff will have very different interests compared to CTOs and Lead Architects. Being able to present the software to technical and non-technical audiences alike is important in Sales Engineering.

Finally, having expert knowledge of the integration options and quickly getting an understanding of the client’s system is an essential part of the work. 

Tales from the Technical Sales front line

Can you share an example of a time you had to talk a prospect out of a sale because you knew it wouldn’t work?

Learnosity is a cutting-edge assessment engine. When speaking to modern learning platforms we quickly need to determine what tools they are using to render their publications.

Some systems do not support the latest version of HTML. That becomes a blocker for inline assessments. In those cases there may be a path to creating a parallel assessment mechanism rather than an inline one, but where that is not desired we quickly inform the client that embedding questions inline will not be possible in the system they use. We encounter this maybe once every couple of months.

Not long ago, we spoke to a client that loved our analytics functionality but it was not possible for them to run student assessments through our assessment player. The client wanted to overcome this by attempting to recreate external student sessions in Learnosity. We know from experience that this would not work in the long term. That was one project we decided not to move forward with.

Similarly, can you recall an instance where you were confident there was a good fit but had to convince a prospect of it? What was it that caused the penny to drop in the end?

Learnosity doesn’t really have any competitors insofar as there are no other API-driven assessment engines out there. People often come to us expecting to see a platform. Sometimes prospects look at the default view of the authoring tool, the default view of the assessment player, and decide this will not work for them because what they need should look and behave differently. They do not see how we can fit their needs.

As I do this every day, I am better positioned to see the fit, but sometimes clients need to be persuaded that it exists. To get to this point we will usually be forty minutes into an hour-long meeting. 

To present a custom solution I use a series of four Learnosity websites and a site I run on my local machine to explain how the Learnosity APIs can be customized in a way to meet their needs. Where possible, I will show live code samples so they can see the solution in action. The live code samples allow me to chain the pieces together as the prospect watches. This helps them understand how deeply embedded Learnosity can be in their system and how it can match their look and feel seamlessly.

You’ve had a rich and varied career to date. In what ways have those experiences informed what you do at Learnosity?

Like many people, I’ve had a few odd jobs along the way. I started in construction with my father. Back in 1992, I promoted nightclubs in two Irish cities. Later I worked for a postal company in London and used to deliver mail around the city, including to Buckingham Palace. I spent some time building skyscrapers. I worked in banking for a while. I worked for a company that developed software for Formula One cars.

I think having a diverse work history is really valuable, it provides a broader view of the world. At Learnosity, as well as having clients that work with universities, others deliver vocational training. We have clients that provide compliance training. I’ve touched on all those areas in my career to date.
 
As you know, accessibility in assessment systems is very important. I speak to edtech companies about that several times each week. If you find yourself on the platform of the Lexington Avenue line of Grand Central Station in NYC and you look down you’ll see yellow tiles with bubbles on them. They are called Tactiles because they are tactile—you can feel them underfoot. They help those with visual impairments know when they are close to the platform edge. I was one of the crew that put those there about 20 years ago. That was probably my first accessibility project.🙂