13 ms·

Enterprise Ready SaaS Feature Guides

290 points by tortilla 10y ago

gkoberger 10y ago
This is a really great guide... as a consumer/startup person, I never would have realized some of these things are features larger companies need (audit logs, how pricing forms should be laid out, etc)
Dawoodi 10y ago
It is pretty interesting. Nice guide.
Spooky23 10y ago
One thing that I'd suggest adding is the ability to ship logs to external destinations. Platforms like Splunk and SIEM tools are really common these days and analysis often takes place there for large companies. Coordinating user access activity in the cloud against employee termination, for example, is something that is high value and usually cannot take place in a cloud service.
- grantlmiller 10y ago
  Totally agree on that being super important and often overlooked. We tried to cover that in the section about audit logs being accessible from an API: https://preview.enterpriseready.io/features/audit-log/#key-functionality https://preview.enterpriseready.io/features/audit-log/#key-f... is there additional detail you think we need to add to that section?
  - Spooky23 10y ago
    I somehow missed that section. That pretty much covers it I think. We have a few services at work that I thought were sending native syslog, but it turns out we have a daemon pulling those logs from an API.
dmode 10y ago
This is a great guide. It also underscores why it is so difficult for young startups to unseat big incumbents like Oracle in Enterprise. Not only you have to compete with every corner case features, but also have all the other stuff done. Other things I would add to this list are: Accessibility and RTL readiness, configuration / implementation guides, Text replacement guides
- grantlmiller 10y ago
  Thanks & you're right these are all the things that are easy to overlook when eyeing up an incumbent. Accessibility - great call - did this at our last SaaS company (for mobile too!). A few questions... I'm unfamiliar with RTL readiness, can you elaborate? Same with text replacement, are you referring to internationalization?
  - powvans 10y ago
    Text replacement might mean changing a term throughout the application. Sort of like localization or perhaps more like white labeling gone wild. For example, Prospective Customer Corp doesn't use the term "Manager", but instead uses "Team Leader" or "Coach" and wants all references to that to match their internal language.
    - icebraining 10y ago
      That definitively happens; it helps if your platform allows for dynamic translation (e.g. from the database), rather than static dictionaries.
  - dmode 10y ago
    As the poster said below, text replacement gives customers the flexibility to brand things differently internally. For example, the app label says "chat", but customers want to re-label that and say "conversations". This is at the basic level. You also have to think about internationalization - can you replace chat in Spanish with conversation in Spanish. RTL = Right to Left. If the customer has operations in Middle East, they would need to display Arabic or Hebrew text, which unlike English, goes from Right to Left. Which means your screen orientation should be changed as well. If you have a screen with a picture on the left, for an Arabic user, the picture needs to move to the right. I also should have added internationalization to my original comment. Asian characters, especially Japanese, can cause a lot of challenges.
doublerebel 10y ago
I really like B2B SaaS. As long as you can show reduction of cost or labor, a business has a clear reason to make the buy. Awesome to have so many real-world examples in this guide, and not just generalized advice. For another example, here is Sidekiq's Commercial FAQ for customers looking to decide between 'Pro' and 'Enterprise' subscription levels. It gives some insight into the tradeoffs that make sense for both sides at the Enterprise level: https://github.com/mperham/sidekiq/wiki/Commercial-FAQ https://github.com/mperham/sidekiq/wiki/Commercial-FAQ This is particularly interesting to me as I previously co-founded a B2B SaaS and am currently launching a copy of Sidekiq's model for NodeJS.
- grantlmiller 10y ago
  Agree, I moved away from consumer stuff primarily because I think that enterprise buyers are more rational & logical (not completely... but more than consumers). If you're looking to create an enterprise installable version (a la Sidekiq)... well... read the deployment options post: https://www.enterpriseready.io/features/deployment-options/ https://www.enterpriseready.io/features/deployment-options/ (we run a company that helps other companies do just that).
NeutronBoy 10y ago
I love this site. Change Management is a super important one that often gets missed. Enterprise customers will have strict workflows around migrating changes from Dev, to Test, and then into Prod. They'll need warning about upcoming changes so they can plan and train users as well, which is often overlooked. A good example is a government client I recently worked for. For major application upgrades and changes (which they needed to apply to keep their SLAs in place with the vendor), they needed at least 12-18 months notice, because if they needed to re-train 15,000 users, that takes time and lots of money. And if they needed lots of money, they needed to submit a business case to the government and get funding in the next financial year.
- ohstopitu 10y ago
  but how does that work out for a SaaS app? (especially a startup that's always adding in new features?) I mean, one idea is to create sub domains - each running a different version of your app...but at that point, you kind of loose control and companies would love to stick to an older version (and you'd have to support an older version).
  - NeutronBoy 10y ago
    The same way that Salesforce does it - allow you to flick a switch and transition to a new interface, or turn on a new feature, or whatever. In terms of remaining on older versions, vendor typically restrict this through SLas - For example, you might only get your Tier 1 SLA response (acknowledgement of a serious issue within 1 hour, for example), if you're on the current version, or the previous version. Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that.
    - ohstopitu 10y ago
      Thanks for the reply! > Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that. Won't that just mean they'd not like the rate of progress (say daily updates for bug fixes, weekly updates for minor changes, and monthly updates for major changes), and just leave?
beat 10y ago
This is also about enterprise in particular, distinct from ordinary B2B. If you don't work enterprise, the distinction can be lost. The sales process can be long and slow, with lots of customization and seemingly arbitrary requirements. On the other hand, if you can build an enterprise-worthy product and a sales team that can handle it, it's an incredible cash cow. Six and seven figure contracts.
ejcx 10y ago
If you are a startup that is building a product you should consider these future wants when writing code. Audit logging, different roles, teams, permissions, auth mechanisms etc. Believe me when I say it is a lot easier to add these things in the future if you consider these future wants when building your abstractions. This may sound like a lot of work and accounting for unknown unknowns, but doing things like if (userHasPermission()) {} instead of if (user->permission == 1) {} will make your life much simpler down the line.
mnutt 10y ago
This is a really good overview of some features that are common in enterprise SaaS, but I would caution against thinking that they're necessary to be successful in enterprise SaaS.* My experience has been that if you have a really compelling core feature set, most everything else is negotiable. Some are nice to have, some are regulatory, and some are just something someone added to a list because they thought it sounded like a good idea. Even the ones you do decide to implement, make sure you do enough customer discovery to figure out how it relates to your market. * Except security. Always be thinking about security.
- grantlmiller 10y ago
  I appreciate your level response. You're correct that these features are not absolutely, always necessary for success. I would caution that even with a an incredibly compelling core feature set, you still have to negotiate yourself out of not providing these features. Even when you win you might be creating a maintenance nightmare for someone down the totem pole within your customer's org. Part of what we're trying to do with EnterpriseReady is show that many of the non-core (yet common among many enterprise customers) features 1) aren't that hard to understand 2) can be built really well in a way that will delight your users. * As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" - I genuinely hope that I did not do that. 100% - Always be thinking about security.
  - clay_to_n 10y ago
    >* As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" - I genuinely hope that I did not do that. In my reading he was referring to negotiations that SaaS product companies have with customers; saying that sometimes customers will request features that "sound like a good idea" but aren't necessary or fully thought out.
  - mnutt 10y ago
    I could have worded that better, I was referring to someone within the client organization adding on requirements arbitrarily.
theluketaylor 10y ago
I work in a heavily regulated industry and we cannot even consider a SaaS application until it does nearly all of these things. If an application doesn't have SAML, SIEM ready audit logs and RBAC it can't even be added to RFP consideration, let alone bid for our business. I have sat through a number of startup SaaS pitches where the product looks interesting and would solve one or more active business problems, but when I ask about roles or audit logs it hasn't even been considered and I cannot consider it any longer. One item lacking from the list is tenant isolation. We don't always require a fully isolated tenant (though we often do if customer data is going to be stored in the cloud), but we do require whatever isolation there is be fully documented and provided. I'm also noticing a trend among SaaS providers to have what they consider strong SLAs we find laughably weak. If your SEV1 SLA is more than 30 minute response time you're not ready to pitch me anything. This isn't beating up on the new guy; our internal business-critical applications all have 15 minute response requirements for the internal support teams.

290 points by tortilla 10y ago

This is a really great guide... as a consumer/startup person, I never would have realized some of these things are features larger companies need (audit logs, how pricing forms should be laid out, etc)

Dawoodi 10y ago

It is pretty interesting. Nice guide.

Spooky23 10y ago

One thing that I'd suggest adding is the ability to ship logs to external destinations. Platforms like Splunk and SIEM tools are really common these days and analysis often takes place there for large companies. Coordinating user access activity in the cloud against employee termination, for example, is something that is high value and usually cannot take place in a cloud service.

grantlmiller 10y ago
Totally agree on that being super important and often overlooked. We tried to cover that in the section about audit logs being accessible from an API: https://preview.enterpriseready.io/features/audit-log/#key-functionality https://preview.enterpriseready.io/features/audit-log/#key-f... is there additional detail you think we need to add to that section?
- Spooky23 10y ago
  I somehow missed that section. That pretty much covers it I think. We have a few services at work that I thought were sending native syslog, but it turns out we have a daemon pulling those logs from an API.

dmode 10y ago

This is a great guide. It also underscores why it is so difficult for young startups to unseat big incumbents like Oracle in Enterprise. Not only you have to compete with every corner case features, but also have all the other stuff done. Other things I would add to this list are: Accessibility and RTL readiness, configuration / implementation guides, Text replacement guides

grantlmiller 10y ago
Thanks & you're right these are all the things that are easy to overlook when eyeing up an incumbent. Accessibility - great call - did this at our last SaaS company (for mobile too!). A few questions... I'm unfamiliar with RTL readiness, can you elaborate? Same with text replacement, are you referring to internationalization?
- powvans 10y ago
  Text replacement might mean changing a term throughout the application. Sort of like localization or perhaps more like white labeling gone wild. For example, Prospective Customer Corp doesn't use the term "Manager", but instead uses "Team Leader" or "Coach" and wants all references to that to match their internal language.
  - icebraining 10y ago
    That definitively happens; it helps if your platform allows for dynamic translation (e.g. from the database), rather than static dictionaries.
- dmode 10y ago
  As the poster said below, text replacement gives customers the flexibility to brand things differently internally. For example, the app label says "chat", but customers want to re-label that and say "conversations". This is at the basic level. You also have to think about internationalization - can you replace chat in Spanish with conversation in Spanish. RTL = Right to Left. If the customer has operations in Middle East, they would need to display Arabic or Hebrew text, which unlike English, goes from Right to Left. Which means your screen orientation should be changed as well. If you have a screen with a picture on the left, for an Arabic user, the picture needs to move to the right. I also should have added internationalization to my original comment. Asian characters, especially Japanese, can cause a lot of challenges.

doublerebel 10y ago

I really like B2B SaaS. As long as you can show reduction of cost or labor, a business has a clear reason to make the buy. Awesome to have so many real-world examples in this guide, and not just generalized advice. For another example, here is Sidekiq's Commercial FAQ for customers looking to decide between 'Pro' and 'Enterprise' subscription levels. It gives some insight into the tradeoffs that make sense for both sides at the Enterprise level: https://github.com/mperham/sidekiq/wiki/Commercial-FAQ https://github.com/mperham/sidekiq/wiki/Commercial-FAQ This is particularly interesting to me as I previously co-founded a B2B SaaS and am currently launching a copy of Sidekiq's model for NodeJS.

grantlmiller 10y ago
Agree, I moved away from consumer stuff primarily because I think that enterprise buyers are more rational & logical (not completely... but more than consumers). If you're looking to create an enterprise installable version (a la Sidekiq)... well... read the deployment options post: https://www.enterpriseready.io/features/deployment-options/ https://www.enterpriseready.io/features/deployment-options/ (we run a company that helps other companies do just that).

NeutronBoy 10y ago

I love this site. Change Management is a super important one that often gets missed. Enterprise customers will have strict workflows around migrating changes from Dev, to Test, and then into Prod. They'll need warning about upcoming changes so they can plan and train users as well, which is often overlooked. A good example is a government client I recently worked for. For major application upgrades and changes (which they needed to apply to keep their SLAs in place with the vendor), they needed at least 12-18 months notice, because if they needed to re-train 15,000 users, that takes time and lots of money. And if they needed lots of money, they needed to submit a business case to the government and get funding in the next financial year.

ohstopitu 10y ago
but how does that work out for a SaaS app? (especially a startup that's always adding in new features?) I mean, one idea is to create sub domains - each running a different version of your app...but at that point, you kind of loose control and companies would love to stick to an older version (and you'd have to support an older version).
- NeutronBoy 10y ago
  The same way that Salesforce does it - allow you to flick a switch and transition to a new interface, or turn on a new feature, or whatever. In terms of remaining on older versions, vendor typically restrict this through SLas - For example, you might only get your Tier 1 SLA response (acknowledgement of a serious issue within 1 hour, for example), if you're on the current version, or the previous version. Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that.
  - ohstopitu 10y ago
    Thanks for the reply! > Once you're on an older version those SLAs often don't apply, and large organisations mostly aren't ok with that. Won't that just mean they'd not like the rate of progress (say daily updates for bug fixes, weekly updates for minor changes, and monthly updates for major changes), and just leave?

beat 10y ago

This is also about enterprise in particular, distinct from ordinary B2B. If you don't work enterprise, the distinction can be lost. The sales process can be long and slow, with lots of customization and seemingly arbitrary requirements. On the other hand, if you can build an enterprise-worthy product and a sales team that can handle it, it's an incredible cash cow. Six and seven figure contracts.

ejcx 10y ago

If you are a startup that is building a product you should consider these future wants when writing code. Audit logging, different roles, teams, permissions, auth mechanisms etc. Believe me when I say it is a lot easier to add these things in the future if you consider these future wants when building your abstractions. This may sound like a lot of work and accounting for unknown unknowns, but doing things like if (userHasPermission()) {} instead of if (user->permission == 1) {} will make your life much simpler down the line.

mnutt 10y ago

This is a really good overview of some features that are common in enterprise SaaS, but I would caution against thinking that they're necessary to be successful in enterprise SaaS.* My experience has been that if you have a really compelling core feature set, most everything else is negotiable. Some are nice to have, some are regulatory, and some are just something someone added to a list because they thought it sounded like a good idea. Even the ones you do decide to implement, make sure you do enough customer discovery to figure out how it relates to your market. * Except security. Always be thinking about security.

grantlmiller 10y ago
I appreciate your level response. You're correct that these features are not absolutely, always necessary for success. I would caution that even with a an incredibly compelling core feature set, you still have to negotiate yourself out of not providing these features. Even when you win you might be creating a maintenance nightmare for someone down the totem pole within your customer's org. Part of what we're trying to do with EnterpriseReady is show that many of the non-core (yet common among many enterprise customers) features 1) aren't that hard to understand 2) can be built really well in a way that will delight your users. * As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" - I genuinely hope that I did not do that. 100% - Always be thinking about security.
- clay_to_n 10y ago
  >* As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" - I genuinely hope that I did not do that. In my reading he was referring to negotiations that SaaS product companies have with customers; saying that sometimes customers will request features that "sound like a good idea" but aren't necessary or fully thought out.
- mnutt 10y ago
  I could have worded that better, I was referring to someone within the client organization adding on requirements arbitrarily.

theluketaylor 10y ago

I work in a heavily regulated industry and we cannot even consider a SaaS application until it does nearly all of these things. If an application doesn't have SAML, SIEM ready audit logs and RBAC it can't even be added to RFP consideration, let alone bid for our business. I have sat through a number of startup SaaS pitches where the product looks interesting and would solve one or more active business problems, but when I ask about roles or audit logs it hasn't even been considered and I cannot consider it any longer. One item lacking from the list is tenant isolation. We don't always require a fully isolated tenant (though we often do if customer data is going to be stored in the cloud), but we do require whatever isolation there is be fully documented and provided. I'm also noticing a trend among SaaS providers to have what they consider strong SLAs we find laughably weak. If your SEV1 SLA is more than 30 minute response time you're not ready to pitch me anything. This isn't beating up on the new guy; our internal business-critical applications all have 15 minute response requirements for the internal support teams.