11 ms·

One great piece of pricing advice I received was that you can price the product based on the seniority of the person in the room. If you're meeting with a mid-l

One great piece of pricing advice I received was that you can price the product based on the seniority of the person in the room. If you're meeting with a mid-level manager of a medium-sized company, you shouldn't go crazy with the pricing. But if a senior executive is in the meeting, you can tell the deal is important enough for him/her to spend time on it, and you can price accordingly. This doesn't override other more concrete considerations, but when you're trying to price software (zero marginal cost) made by a startup (often no direct competitors/comparabales), it can be a useful factor.

hartator 3y ago
I would argue for the reverse: transparency in pricing and don’t try to haggle up depending on the business/person you have in front.
- dmbche 3y ago
  The point of the article is that it's very difficult to have an objective transparent answer. Client and seller are guessing the value, so trying to remain as loe as possible is just bad practice.
- gnicholas 3y ago
  That makes sense for mature businesses, but for a startup getting its first customers, or its first customers in a particular sector, you have no idea what your price should be. Should it be $10k per year, or $10k per month? Unless you're pricing on a cost-plus basis, you have no idea what the right order of magnitude is.
ijidak 3y ago
This is a great insight. In Enterprise sales, the speed of sales at a given price often varies by pay grade. If you want individual teams at large companies to be able to purchase the software, it needs to be at a certain price point. If the software only makes sense at levels higher up, the price point increases accordingly. Also, the higher you go up in the company, the longer a deal can take. Thus, price should reflect this as well. For example, if your software is of the nature that it requires approval of CEOs at large companies, your pricing will need to reflect the extra overhead -- e.g. the time and hand holding it takes to close the deal. That's why lower prices and faster onboarding is so valuable. Ideally you want your software to be adoptable at grassroots levels within a company. This reduces sales overhead and makes lower prices feasible. It's a feedback loop in both directions.
amelius 3y ago
So hire devs when they are young, and salesmen when they're old ... ?

hartator 3y ago

I would argue for the reverse: transparency in pricing and don’t try to haggle up depending on the business/person you have in front.

dmbche 3y ago
The point of the article is that it's very difficult to have an objective transparent answer. Client and seller are guessing the value, so trying to remain as loe as possible is just bad practice.
gnicholas 3y ago
That makes sense for mature businesses, but for a startup getting its first customers, or its first customers in a particular sector, you have no idea what your price should be. Should it be $10k per year, or $10k per month? Unless you're pricing on a cost-plus basis, you have no idea what the right order of magnitude is.

ijidak 3y ago

This is a great insight. In Enterprise sales, the speed of sales at a given price often varies by pay grade. If you want individual teams at large companies to be able to purchase the software, it needs to be at a certain price point. If the software only makes sense at levels higher up, the price point increases accordingly. Also, the higher you go up in the company, the longer a deal can take. Thus, price should reflect this as well. For example, if your software is of the nature that it requires approval of CEOs at large companies, your pricing will need to reflect the extra overhead -- e.g. the time and hand holding it takes to close the deal. That's why lower prices and faster onboarding is so valuable. Ideally you want your software to be adoptable at grassroots levels within a company. This reduces sales overhead and makes lower prices feasible. It's a feedback loop in both directions.

amelius 3y ago

So hire devs when they are young, and salesmen when they're old ... ?