Hacker News Reader

Comment by 101008 | Hacker News Reader

My problem with this advice of testing your pricing strategy is how to communicate this to actual customers. Maybe this isn't a thing in Europe or USA; but in third-world countries a change in the price it is important and something your customers want to know.

If I set my prices higher, I can't change it for my current customers. They will get mad. So I ahve to create a full logic on the backend for customers created after X date, etc. It is a mess.

If I set my prices lower (i.e., display lower prices on landing page, etc), my current customers will get mad at me if I don't change them for them too ("Why I am paying more than the price you are saying this costs?"), etc.

So for me, this strategy of A/B testing prices, find the right price, etc, has been always too complicated to implement. When I tried, I end up adding more problems to me to deal with, and at the end I couldn't analyze the trends I wanted it.

View on HN

One trick you can use is to figure out a set of product parameters that you can tweak into new combinations to create lots of pricing plans. They may be effectively identical to previous ones as far as your cost and engineering are concerned, but different enough that customers don’t feel someone is getting a different price for the same thing.

E.g. your previous “Medium Starter” plan included 10 foobags and up to 1.5 zoffobytes of data for a price of $19. Your new “Basic Plus” plan includes 15 foobags and 1.2 zoffobytes for $25.

I didnt buy a robot vacuum because of this. There was a crazy amount of different ones from the same company with different pricings. Maybe it is better now. But usually I want a product which fulfills my supposed needs for a reasonable price. Too many different products (especially from the same vendor) give me the certainty no matter which one I choose one or the other criterium will fail.

The advice is more applicable to SaaS products where users can easily switch between plans, and creating new combinations of the product parameters is free.

Assuming you don’t overdo it, having multiple plans for different types of users can actually help customers feel more confident that your company has the experience to understand their needs.

That’s a problem with product differentiation; not too many SKUs. I think you are referring to iRobot? I couldn’t understand the differences either.

But does the variety of MacBooks turn me away from buying a MacBook? No. Yet there are way more models!

Maintaining that book of past prices, who is on them, the discounts they negotiated, the feature formulation they had - its a nightmarish web of complexity even at large SaaS vendors.

I really can't imagine why. This seems like one of those self contained problems where some PricingService and a DB returns a number and deals with all the complexity internally. That seems like the logical place where you'd do A/B testing of prices and the like.

Maybe, but who's going to build that system when 110% of engineering is building customer features.

Much more likely that a ) engineering doesn't want to touch it ( for obvious reasons so b) sales/sales support maintains this in Excel or worse...

Nothing wrong with maintaining in Excel as long as a computer system can serve that data. At that point it's just a fancy lookup table.

Engineering != programming. People forget that choosing not to code is also an option.

One of the companies I worked for got acquired. The CTO of the bigger company decided to personally lead a large rewrite, including:

• replacing our Wordpress blog with something custom written, including building our own database migrator (you could manually data entry our few blog posts by copy and paste)

• Replace our Google Sheets based asset tracking with an overengineered backend. The frontend was never built due to a lack of FE and design resources and everyone continued to use Google Sheets.

• choose to delete some old sections of our app that still used jQuery, angering vocal customers.

What you're missing is thaton the sales side of things, most of these price discount or variation are only really included in the quotes and not on the crm itself.

This is primarily (imho) because most companies (whether SaaS or other) start their CRM journey with the basics and only end up with some sort of CPQ or quote to cash at a later stage.

The common way to solve this is to offer (either lifetime or limited-time) deals.

You have to maintain the logic, but you can offer lower prices to new customers (to some extent) without getting the current ones too mad.

Reply on news.ycombinator.com