I chatted with someone recently who has been working in EdTech startups for a few years and we got on the topic of sales and growth strategies. He mentioned that many startups’ initial strategy is selling their products to individuals, which in EdTech means individual students, parents, or instructors. This is largely out of necessity, as the sales cycle with institutional customers, such as universities, schools, or school districts is too long for a company to survive.
I’ve spent the last couple of years in higher-ed, but follow startups relatively closely. The topic of selling to higher-ed wasn’t entirely new to me, but it made me stop and reconsider some of the interactions I’ve witnessed between EdTech startups trying to get their products into the university.
While I understand the strategy and get frustrated with the slow pace of the university, it’s not usually a pleasant experience for those of us working on providing educational technology to the university. Frequently a faculty member or an individual school within the university will start using something, and then try to bring the rest of the university along later so it no longer comes entirely from their budget or to take advantage of integrations with university-wide systems. This can be frustrating for IT departments as they are undoubtedly feeling pressure from leadership to say “yes”, but the requested product may have serious issues (see Piazza). While IT will be responsible for supporting the product, they won’t be getting more resources. Thus, in my experience, we want to help the university community, but we’re not opposed to shutting down the request for the must-have app of the semester.
This isn’t to suggest I’ve been in charge of the complete procurement process at any institution. I work on a product team which provides a variety of academic technologies for students, faculty, and staff of the university. I occasionally listen in on pitches from companies that want to sell to the university, but more often I go to work after a successful pitch has been made to someone outside IT (or outside the teams responsible for providing and supporting the tools), who now wants the IT teams to implement a university-wide license.
I can’t reveal the entire procurement process because nobody knows it. Rules change frequently and depend on what you want to procure at what time of year. I can only speak about the parts of it that I come into contact with and mention some of the stumbling blocks for companies I’ve seen in the past few years.
Digital Accessibility
I’m not officially on the university’s digital accessibility team, but I’ve spent the past 18 months working on accessibility issues in my product. If someone tells me about a new product they want, an early step is to run an automated accessibility test, such as aXe, to see if there are any clear issues.
This is the easiest way to argue against a new request that comes to me or my team. All universities in the United States (not to mention those in Europe and Canada) are now assuming that they need to meet WCAG 2.0 AA standard for digital accessibility. We’ve been dealing with accessibility so long, that some on the team assume a vendor who isn’t close to perfect in this area is out of the loop or they don’t have other customers in higher-ed.
The number of lawsuits has been increasing and universities have been fined for accessibility issues that aren’t visible to the public web. Showing the university team a VPAT and telling them you are 508 Compliant does very little except show us that you hired a vendor to tell you what the problems are and you probably don’t have a good understanding of accessibility.
What could companies do to improve? Ideally, bring the product up to WCAG 2.0 AA standard. If that’s not possible in the next few months, bring a roadmap showing how you are going to address the issues discovered in the VPAT and maybe bring your accessibility engineer along to meet to the team. That sort of assurance makes it easier for teams like mine to go back to the university and show that the new product will not result in a lawsuit.
Execution
Someone is going to look at how your product is put together. While sales contacts may be on the academic side of the university or may not be well-versed in product, engineering, or design, teams with that expertise are frequently brought into the process or asked their opinions. It is likely that your product will be dissected by these teams, and doubly likely if there is any reason to be unsure about your company or product. (See the section on professionalism below.)
I mention this because sometimes a company with an established central product also needs a variety of integrations and plugins to get plugged into the university LMS and other systems. The teams that run these systems are experts in whatever the system is, whereas the engineer who created it may have needed to learn for this specific project. It’s not necessarily fair to compare the two, but if the engineering teams are handed junk code and asked to test out the integration, they will make their concerns known. If the support and product teams are asked to test something which seems overly complex, doesn’t work right, or even if it is simply ugly, they are already thinking about the required support effort and the reaction of their favorite and least favorite customers.
(I shouldn’t have to say that the vendor’s engineers should also know their product’s code. Recently someone from a vendor with an LTI integration asked our product manager several questions about his own company’s code. This doesn’t inspire confidence.)
Appearance of professionalism
“How do we know this isn’t two guys in a garage?”
This is the question which advocates for a new product in the university want to be able to answer with confidence. In some industries, two people building out of their garage isn’t necessarily a bad thing, but to describe higher-ed as risk-averse would be an understatement.
You might be connected with a wide range of people in the university in the process of demoing, testing, and setting up the product. If enough of these folks get odd emails at strange times of night (from someone based in the same timezone), or if the vendor’s engineers are unfamiliar with pieces of enterprise technology that those in the university take for granted, it’s going to be commented on.
Lack of attention to security is also something your university partners are probably quick to notice. University IT deals in sensitive information constantly and higher education is a high value target for bad actors. Thus, sending a university passwords or key and secret combinations over email will be remarked upon.
I heard recently at a conference that IT in higher education can be described as “hardware rich and human resources poor”. Many of us in the university are working on tiny teams to serve more users than the vendor currently has. We may know the signs of chaos and lack of resources on a support team or engineering team because we have been part of one within the larger university.
In the end, the product and support teams want to know if this vendor is reliable. It’s likely that the teams supporting the new product, which are likely already under-resourced, are not going to get anything extra to cover the increased surface area the new product brings. They may like the product, but if they can’t rely on support or professionalism, they will raise concerns about the deal.
Even if you make it in the door…
Companies who get the contract signed and the key and secret sent over aren’t immune from these issues either. Enough of these problems can lead to reduced usage of a product at the university, which raises questions about re-contracting. For example, some teams have stopped recommending use of a product to students and faculty because of accessibility. They now send users to the public, ad-supported competitor. That same product has turned many of the internal stakeholders against it because of repeated missteps in execution (buggy code, releasing major interface changes on a Monday afternoon, etc.) and an incredible lack of professionalism, probably because the teams we work with are under-resourced. While it’s a lot of work to change platforms, some teams, clients, and stakeholders may start to think it is worth it.
Conclusion
In the worst case for a company with a product for the university, these concerns can stop the deal. That’s not always the case, as leadership is frequently focused on the benefits and not the smaller, daily issues this may cause. However, even in my limited experience, I have seen one or more of the above stop the sales process.