4 ms·

You're treating your customers with enormous disrespect. If your chosen example is really Sun Access Manager, why don't you expect the developers using it to un

by nknight 15y ago

You're treating your customers with enormous disrespect. If your chosen example is really Sun Access Manager, why don't you expect the developers using it to understand how it works? You're assuming we're morons. Absolute drooling morons, judging from the documentation I can find for Access Manager, which shows a product that is orders of magnitude simpler than a few others I've dealt with, and I'm having no trouble understanding how it works.

bmelton 15y ago
Again, I disagree. I don't think you're a moron. But the developers generally aren't the same people that pay for the software, especially not in the size of the organizations we're selling to. If you're a 10, 20, 250 person company, you're probably not buying our product. If you're a 30,000 person company, you're in our market. If you're in a 30,000 person company, I almost guarantee that the 'developer' implementing the product isn't the same person as the guy writing us our check. I'm willing to bet there are at least two layers in the org chart between those people, if not more. In the size of these organizations, there are enterprise architecture counsels, change control boards, executive steering committees. We need to document to those individuals how we're going to help them further their missions and operating objectives for the years to come. We're going to show how our products can be leveraged to maximize the efforts they're already undertaking. The change control boards are going to want to see white papers that document what effect our application is going to have on the existing environment. They're going to want to know exactly what ports and protocols need to be exposed for things to work. They're going to need to know what kind of load balancing techniques will work best for our product. They're going to need to know how much storage allocation to expect at years 1, 2 and 5. These aren't things we expect anyone to know, and they change from version to version. These are the things that we know, and not even necessarily one guy in our group knows them, we need a few people in our team to explain these questions and more.

by nknight 15y ago

bmelton 15y ago

Again, I disagree. I don't think you're a moron. But the developers generally aren't the same people that pay for the software, especially not in the size of the organizations we're selling to. If you're a 10, 20, 250 person company, you're probably not buying our product. If you're a 30,000 person company, you're in our market. If you're in a 30,000 person company, I almost guarantee that the 'developer' implementing the product isn't the same person as the guy writing us our check. I'm willing to bet there are at least two layers in the org chart between those people, if not more. In the size of these organizations, there are enterprise architecture counsels, change control boards, executive steering committees. We need to document to those individuals how we're going to help them further their missions and operating objectives for the years to come. We're going to show how our products can be leveraged to maximize the efforts they're already undertaking. The change control boards are going to want to see white papers that document what effect our application is going to have on the existing environment. They're going to want to know exactly what ports and protocols need to be exposed for things to work. They're going to need to know what kind of load balancing techniques will work best for our product. They're going to need to know how much storage allocation to expect at years 1, 2 and 5. These aren't things we expect anyone to know, and they change from version to version. These are the things that we know, and not even necessarily one guy in our group knows them, we need a few people in our team to explain these questions and more.