Ah, I somewhat misunderstood your previous comment, my apologies. This could certainly be clearer in documentation and the priceops.org presentation, I'll take the note on that and think about how to make it more clear.
When we say "change prices", we're not necessarily suggesting "change prices for each customer/transaction, based on demand/time/demographics/etc" in an aggressive yield management approach. In fact, doing this too aggressively in SaaS products (even being too blatant or careless with A/B testing prices and plans) can lead to customer backlash. See for example common reactions to online games selling virtual goods for different prices in different locales. I'm not saying it's never a viable tactic, but it is not a silver bullet, as you point out.
However, it is the case that:
1. Your product will change over time (you keep adding features, decide to focus on some or abandon others, etc.)
2. Your target market may change (features formerly thought of as "pro" become expected at the "basic" level, for example.)
3. Your competitors will change (new entrants to the space, existing players changing their offerings, thus changing customer expectations of your product.)
4. Thus, you're very unlikely to pick the "correct" price and packaging on day 1, and it's virtually impossible to predict what will be "correct" in the future.
So, being able to adjust prices without refactoring your entire application and company is really essential, as many SaaS companies learn the hard way, and as is shown in the resources I shared in my previous comment. Eventually, your prices and packaging will most likely have to change (or at least, changing them will be beneficial, even if not existentially necessary), and making that easy is very valuable.
When we say "change prices", we're not necessarily suggesting "change prices for each customer/transaction, based on demand/time/demographics/etc" in an aggressive yield management approach. In fact, doing this too aggressively in SaaS products (even being too blatant or careless with A/B testing prices and plans) can lead to customer backlash. See for example common reactions to online games selling virtual goods for different prices in different locales. I'm not saying it's never a viable tactic, but it is not a silver bullet, as you point out.
However, it is the case that:
1. Your product will change over time (you keep adding features, decide to focus on some or abandon others, etc.)
2. Your target market may change (features formerly thought of as "pro" become expected at the "basic" level, for example.)
3. Your competitors will change (new entrants to the space, existing players changing their offerings, thus changing customer expectations of your product.)
4. Thus, you're very unlikely to pick the "correct" price and packaging on day 1, and it's virtually impossible to predict what will be "correct" in the future.
So, being able to adjust prices without refactoring your entire application and company is really essential, as many SaaS companies learn the hard way, and as is shown in the resources I shared in my previous comment. Eventually, your prices and packaging will most likely have to change (or at least, changing them will be beneficial, even if not existentially necessary), and making that easy is very valuable.