Hacker News new | past | comments | ask | show | jobs | submit login
Enterprise Ready SaaS Feature Guides (enterpriseready.io)
290 points by tortilla on Nov 22, 2016 | hide | past | web | favorite | 35 comments

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.

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.

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).

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.

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?

Ahh, now you're really getting into the world of B2E services!

They might just leave - but if it's a core service they need, it's a huge amount of effort to migrate users, data, implement a new system, rewrite all their process and documentation, helpdesk manuals, etc. They generally won't mind with general fixes and updates, but if you're changing existing workflows or features, or adding new capabilities in, they'll probably want control about how they roll that our to their users.

Enterprises generally don't sign up to SaaS services through a webform and a manager somewhere punching in their Amex (although it does happen sometimes). There'll be a proper contract, with lawyers, and negotiations, etc. There'll be clauses in the contract that most enterprises don't want and they'll try to negotiate away - for example, under what circumstances can the vendor (you) terminate the service? If the Enterprise has spent heaps of money to move onto your service, they'll want assurances that you can't terminate the contract because you feel like it - and if you do, that they can sue you for damages.

As you can see it's definitely a conscious decision that you'll need to make if you want to target these Enterprise customers - it's a big investment, and often (particularly in government or if your service is going to be a core platform) you'll get contracts that commit you to 5+ years of service, but the flipside is that now you've locked in 5+ years of revenue from that customer.

I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.

Thanks so much! I've been working on a side SaaS project which I intend to target primarily to Enterprise customers - where I expect to make money (like how Slack does, but it's nothing to do with Office Communication ofc). I've always been looking for details and generally most companies/devs don't like providing info.

You could do the same as many OSS projects - offer an up-to-date version and an LTS version, both with clear schedules. If the LTS is stable - nothing except security or crucial bug fixes - hopefully you won't lose much time supporting it.

The fun is the LTS users will want 95% of the bug fixes and 30% of the features only in the current version. Oh and each customer wants a different 30% of the features. So you need to build them a custom branch or they quit.

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

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?

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.

Thanks for clarifying. Text-replacement makes sense in that context, definitely related to both white label & internationalization.

RTL... most browsers have some sort of RTL support, correct? `dir="rtl"` (I'm not an expert on RTL... I'm confident that given a piece of paper with Hebrew text on it I will still rotate it 3 times before realizing that it is not upside-down English).

I'll get these all worked into the guide soon (or if you're feeling enterprisey... it's open source and we'd love contributions: https://github.com/enterpriseready/enterpriseready/tree/mast...)

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.

That definitively happens; it helps if your platform allows for dynamic translation (e.g. from the database), rather than static dictionaries.

Custom fields and easy branding are also "must have" in the enterprise world.

Custom fields makes sense... do you think those are part of making integrating with other apps easier? https://www.enterpriseready.io/features/integrations/

As for easy branding, do you think that only applies a "must have" if the application has some sort of end-customer/consumer facing interface (ie Zendesk, Readme.io etc)? Or do you think that is equally important for applications that are used exclusively internally by employees.

It's a plus for internal apps: there's always some "company first" person in the chain who wants to get brownie points by having their logo visible.

It's also very easy to implement, so why not?

Auditing remains the killer though, if you build it in from the beginning then it can be effectively free because of how it affects your architecture. If not it can become a big maintenance headache.

Not the OP, but I think they meant more inline with what is common in most enterprise CRM and CMS applications. Something like: https://trailhead.salesforce.com/en/data_modeling/creating_c...

> Custom fields makes sense... do you think those are part of making integrating with other apps easier

It's more about being consistent with other processes and applications that an enterprise already has. If your product is about generating reports, they'll want the button to say 'Generate TPS report' rather than 'Generate report'.

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

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.

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/ (we run a company that helps other companies do just that).

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.

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-f... is there additional detail you think we need to add to that section?

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.

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.

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.

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.

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.

>* 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.

I could have worded that better, I was referring to someone within the client organization adding on requirements arbitrarily.

Ha, makes sense... I didn't really take any offense.

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)

It is pretty interesting. Nice guide.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact