3 ms·

I love this site. Change Management is a super important one that often gets missed. Enterprise customers will have strict workflows around migrating changes fr

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?
    - NeutronBoy 10y ago
      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.
      - grantlmiller 10y ago
        I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.
      - ohstopitu 10y ago
        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.
      - deleted 10y ago
        [deleted]
- icebraining 10y ago
  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.
  - brianwawok 10y ago
    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.

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?
  - NeutronBoy 10y ago
    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.
    - grantlmiller 10y ago
      I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.
    - ohstopitu 10y ago
      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.
    - deleted 10y ago
      [deleted]
icebraining 10y ago
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.
- brianwawok 10y ago
  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.