In our previous post, Understanding SaaS Products and How They Can Benefit Your Organization, we went over the differences between SaaS and other forms of software distribution. In this article, we’ll talk about what those differences mean when assessing a SaaS vendor. To start, it’s important to understand how a SaaS vendor differs from other software vendors.
What makes a SaaS vendor different?
With a traditional software vendor, a lot of the primary value is set up from the start, and the consumer is often more involved with the operations of managing the software. So naturally, the focus with a traditional software vendor is often more on the present, and is more on specific issues, such as the features of the product as it exists today, the vendor’s ability to set that software up in the way that you prefer, and the ongoing support and updates that will be provided.
With a SaaS vendor, there will be a lot more that happens behind-the-scenes. So, while many of these concerns are still important, there often needs to be a broader focus on the relationship with and the future of the vendor. For example, some SaaS vendors release updates every month, so the product you are using in just six months will be noticeably different than the product you see today. For that reason, you want to make sure you trust the SaaS vendor to make the right updates for you throughout your relationship with them.
What to look for in a SaaS vendor
In order to assess if a SaaS vendor is going to be able to reliably deliver an evolving product that is valuable to you, it is helpful to first understand the groups within a SaaS vendor:
- Development: This is often who is thought of when it comes to software, the tech experts who sit behind a computer and build the software. While this team is core, in many ways, they are the least important to the end user, as it is the remaining groups in this list that actually affect a user’s experience.
- Product: An often-overlooked group when it comes to software are the people responsible for guiding, coordinating, and monitoring the products to ensure that they provide optimal value to the end user. This is one of the most important groups for an end user, as it is generally the one that is responsible for ensuring the user gets a great experience with the software.
- Design: Sometimes undervalued, a group focused on design not only helps ensure that the products are created to be easy and pleasant to use, but also that they are produced efficiently. Iteration is inevitable in software and iterating in design is a lot faster than iterating in development.
- Infrastructure: As the foundation on which software is built, infrastructure is generally what determines the reliability and security of a software product. This includes both the technological infrastructure and the people responsible for managing it. When it comes to SaaS, this group is much more important than traditional software, as you will generally be relying on the infrastructure team to secure your data.
- Customer Support: When you have an issue with a SaaS product, this is the group that helps you address and resolve that issue. Hopefully, you’ll never need them, but practically, you may need them at some point or another.
- Leadership: The people making strategic decisions and ensuring that each of the above groups is empowered to effectively do their jobs. The nature and responsibilities of this group varies greatly depending on the size and structure of the vendor, but in many cases, there is some overlap in people between leadership and the above groups, such as a VP of Engineering.
These groups are not always set up as distinct teams or individuals, and the relationships between the groups can vary vendor-to-vendor. However, each of these groups are important in providing quality SaaS products, so it is important that a SaaS vendor has a solution for each part.
Important characteristics of a SaaS vendor
Understanding the groups in a SaaS vendor also allows us to better assess some of the important characteristics of such a vendor:
- Commitment: You are going to be relying on this vendor to continually provide you a functional and secure product, so it’s important that they are committed to providing you that product. If a vendor is not treating their SaaS product as a priority, for example if it is a legacy product or simply a minor complement to other products/services they provide, then you have to be ready for issues with that product to pile up, as the vendor is likely not going to prioritize addressing them.
- Practical Short-Term, Thoughtful Long-Term: A SaaS vendor will ideally be providing you a software as a service for a long period of time, perhaps indefinitely, which means it is important that they have a clear, transparent strategy for the long-term. Otherwise, they are going to quickly become outdated, or they will progress in a direction that is not desirable to you as a user. But with that being said, it is also important that a SaaS vendor doesn’t get lost in their own vision. When that happens, the vendor tends to promise way more than they can deliver in a reasonable period of time.
- Listens & Adapts: A SaaS vendor has to make a lot of big decisions about the direction of their product(s). However, they don’t always make the right decisions or have all the information to effectively make a decision. That is why it is important that they proactively listen to their users, ideally continually seeking feedback from them, and adapt their product(s) accordingly. Any good SaaS vendor needs to be willing to both admit when they were wrong and correct their mistake.
- Balance Between Security & Features: One of the most pervasive and problematic practices in software is the disproportionate focus on functionality over security. While of course it is important to create a product that does what the user needs, doing so in a way that puts the user at unnecessary risk of cybersecurity issues, such as data exposure, loss, or corruption, is simply unacceptable. In many cases, creating one or two less features so more time can be sent on securing the system is better for the user, the vendor, and frankly, society as whole, as cybersecurity issues can have pretty far-reaching consequences.
- Product > Development: Many software vendors, particular those focused on organizations and businesses, are very developer-led, which means they generally focus on how to make features work, not how to make them useful. This often leads to messy and confusing products with features simply stapled on, one after another, with no real organization or thought to the user experience. Many of these features don’t actually get used because they are too hidden, confusing, or irrelevant to be useful. In general, users and vendors alike are well served by a product-led structure, in which product people determine what the right direction for the product is, and then developers implement in an organized manner, based on guidance and oversight from the product people.
What to look for in a SaaS product
While the quality of a SaaS vendor is important, it is all meaningless if their product(s) aren’t any good. So that begs the question: how do you assess a SaaS product?
Fortunately, when it comes to assessing a SaaS product, a lot of it can be assessed very intuitively, by simply getting a demo and seeing how useful it seems to you or the user for which you would be purchasing the product. With that being said, there are a few other things to look for besides just the apparent functionality:
- Thoughtfulness: Some products seem to be carefully constructed based on an intimate knowledge of the intended use cases, while others seem to be simply a collection of almost independent features that vaguely relate to the intended use cases. The difference between these two approaches for a user can be substantial. To assess this, you can both evaluate the product during the demo to see how well the layout and connection of the features maps to how you would expect the product to be used, as well as talk to the person showing you the product to see how familiar they are with the perspective of a potential user and how that familiarity has been used to guide the design of the product.
- Organization: Similar to the above point, it is important for products to be structured in a way that makes their features as usable as possible. If it is hard to find the features that you want, or you never know where to look to see if the product even has a certain feature, then it will be very hard to use the product without a significant investment of time and energy.
- Priorities: Across the board, it is important to understand what the priorities for the product are. For example, is the product designed for your use case, or does it just happen to support it? Does the existing roadmap for the product align with what you would want, or is the product going to evolve in a direction that isn’t valuable to you? And if you purchased the product, how much input would you have on the roadmap?
- Security: While you want to make sure that security is a priority for the vendor as whole, it is also valuable to assess how much care has been put into the security of a specific product. Not all products require the same level or type of security, so it is important to understand the security of the product in the context that is relevant for that product. Generally, a good practice is to ask yourself: if the product was compromised, what’s the worst that could happen? Then check to see what security measures the product has to protect against those worst-case things from happening. Often, you can have someone from your IT organization talk with the vendor to assess their compliance with security best practices. But some good things to focus on are:
- Tenant Separation: How does the system ensure that another user doesn’t accidentally get access to your data? In traditional software models, you generally don’t have to worry about this. However, with SaaS systems, everything is generally running on the same machines, so it is important that there are strong logical divisions between tenants and safeguards that enforce that division. For example, most systems try to check the tenant at the application layer, but this should also be done at the data access layer.
- Data Encryption: Specifically, you want the product to use encryption in transit and encryption at rest, and both should be done with a well-known, cryptographically secure algorithm.
- Data Backups: Sometimes databases get corrupted or accidentally taken down. Will your data be lost when that happens, or does the system have a way of backing up your data?
- Permissioning: Should be done in a consistent, well-thought-out way, by a shared service. A specific issue to check for is privilege escalation, where a user can somehow give themselves more permissions in an unexpected way, such as creating a new account that has more permissions than their current account.
- Availability: If availability is something that is critical to you (e.g., an accounting system or emergency services system), then you’ll want to determine how well does the system scale with a legitimate spike in usage and does the system have safeguards against DoS/DDoS attacks.
- Internal Controls: One of the biggest vulnerabilities in many systems is lack of safeguards from employees. This doesn’t just mean protection from a malicious rogue employee, but also protections from employee mistakes. Good internal controls often include a mixture of automated system protections and rigorous, collaborative development processes.
Conclusion
Assessing SaaS vendors and products shares some similarities with traditional software vendors and products, but also has many distinct nuances. Hopefully, the above helps illuminate some of those distinctions. If you have any questions or comments, want to learn more about SaaS vendors and products, or just are interested in talking with someone who is passionate about SaaS for higher education, contact us here or reach out to the authors below. We are always interested in talking with and learning from our readers!
About the Authors
Sander Altman is the Chief Architect for the Product and Innovation business at Attain Partners. As the technical leader behind Attain Apps since its formation in 2017, Sander has extensive experience with the technology empowering the platform, as well as a developed understanding of the subject matter covered by the various products within the platform. With a background in AI and Intelligent Systems, as well as an M.S. and a B.S. in Computer Science, Sander has focused on providing institutions with intelligent and easy-to-use software to optimize their academic and research enterprises.
Alexander Brown is the Practice Leader for the Product and Innovation business at Attain Partners. Alex is responsible for the full product lifecycle of the Attain Apps product line, which features the firm’s cornerstone intellectual properties distilled into easy-to-use SaaS products. With a background in economics, and experience as a designer, developer, and consultant himself, Alex works hand-in-hand with experts and developers to create products that provide academic and research institutions with best practices and insights in an affordable and convenient package.
Be the First to Know
Subscribe to our monthly Pulse newsletter
to be the first to hear about new blog posts