Wednesday, January 27, 2010

The Basics of Software as a Service Pricing

It is pretty unanimous that software pricing is one of the hardest parts of a product manager's job. Whether it is an iPhone app or an enterprise software suite, pricing is frustrating to get right and has a major impact on the success or failure of your product. Unfortunately, nobody has come out with a simple, fill-in-the-blank spreadsheet, either.

I want to talk a little bit about software as a service (SaaS) pricing. The vast majority of applications being created, especially in the consumer market, fall into this category. Even many mobile applications tend to have a SaaS component associated with them.

To understand how to price software, it is good to get a handle on the economics behind it. Joel Spolsky's Camels and Rubber Duckies is a great article on the economics of software pricing. Eric Sink's Product Pricing Primer adds to those basics.

What I'm about to say is actually very basic. I had thought that it was common knowledge, but I recently worked with a company that did not have this basic understanding. As a result, I'm going to outline the basics of SaaS pricing.

Basic One: Pricing cannot be an afterthought

With traditional software delivery (e.g. CDs, DVDs, implementations1, or even downloads), you had a binary relationship with the customer. Either somebody purchased or they didn't. The bit may have flipped slowly with timed trials and sales cycles, but it was still a single bit.

The world of SaaS software has changed that. People expect tiered software, with useful functionality at every tier. While you don't have to decide how much a tier will cost right away, you do need to be designing those tiers into the product from the start.

Basic Two: Consumer applications need the Two F's

Free: A large chunk of your users will expect to never pay for anything. If you need large numbers of users for any reason (a social environment, viral marketing, whatever), you need to provide a free version of the application. If you can find a way to monetize these users (basic ads, affiliate programs, etc), great, but you have to provide a no-out-of-pocket, not-blinded-by-ads-or-other-garbage version of the application.

Functional: Providing a free version of your app that doesn't actually do anything useful is the same as not providing a free version. End user expectations have changed, thanks in large part to companies like Google who "give away" so many useful applications. Users will toss free applications that don't do anything. If people toss it, they aren't telling their friends about it or upgrading to the pay tiers.

Basic Three: Differentiate business from consumer

Business applications don't have to have the Two F's. Because of that, if your app is a business app, you want to make sure it is positioned as a business app.

Take a look at the signup page for 37 Signals' Base Camp product. Base Camp is a project management application, targeted at the SMB market. You can find a free single-project plan with very limited functionality, but you have to really hunt. If you didn't know it existed, you would likely miss it altogether.

Because it is people (who are consumers) who do business purchases, you have to make sure to make it clear that yours is a business product. If you confuse the buyer, she is likely to slip into consumer mode and think your app should be free.

Basic Four: Charge as quickly as possible

Only you can decide how quickly you can charge, but you want to charge as quickly as you can. 37 Signals didn't wait until they had a massive following to try to figure out how to "monetize" BaseCamp. They charged from day one.

It's about more than just getting revenue (as important as that is!). It's about ensuring that your users are attaching a value to your product. The longer your product is free, the more difficult it is to change users' perceptions and get them to pay later.

Basic Five: Test and measure, measure and test

Pricing is not static. Neither are the inputs that bring users to your application. Neither are a million other variables2. You should always be measuring and testing. Make sure you know what the impact is when you change your prices slightly, alter what features are available in the free version, or do anything else.

Eric Ries wrote a great article about what you should be measuring. Eric's Startup Lessons Learned blog is a great resource for figuring out what to measure, how to measure it, and what to do about what you've measured.

Basic Six: It isn't worth money just because you built it

The final basic is really an economics basic. Just because you've spent a lot of time and money building something doesn't mean it has value to your customers. It is easy for product managers and executives to think "this cost X dollars to make, so we have to charge X/N for it."

Unfortunately, that kind of thinking will not optimize your pricing and may drive away those all important users. Pricing is ultimately determined by the value the customer places on your software. Your business' viability is determined by whether you can produce the software at a price customers are willing to pay. Your job as the product manager is to ensure that value exists.


There you go. Six basic rules that will give you a foundation for how to price your SaaS application. Still no answer on whether it should be $9.95 per month or $12.95.


1. "Implementation" is just a fancy word enterprise software shops use when their software is so hard to install that their services team has to do it...and charge you for it.

2. Hence the name variables.

Image credit: David Neubert

Monday, January 25, 2010

From the Intrawebs - January 25

Another week without a real post. The Software Maven has been busy tuning his resume and working on how to productize a couple of interesting technologies.

If you are hiring a software product manager and like what you read here, shoot me an e-mail. After having spent some time in the consulting world, I'm looking to find a home again. Being able to play on different projects is fun, but I miss being able to dig into a project over time.

You can subscribe to the live feed of this list in your choice of feed readers. You can also follow @FromTheIntraWeb to get instant gratification.

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are theirs, not mine. I may or may not agree, but to be on this list I think their opinion is at least interesting.

Monday, January 18, 2010

From the Intrawebs - January 18

Happy Birthday, Mr. King! Today's From the Intrawebs is dedicated to the ideals of justice and equality that Martin Luther King, Jr. fought so bravely for (even if his birthday was really on the 15th).

You can subscribe to the live feed of this list in your choice of feed readers, or you can follow @FromTheIntraWeb to get instant gratification.

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

  • CrisisCommons::Haiti: Product camps have recently become popular methods of networking and learning. In response to the devastating earthquake in Haiti, an fascinating derivative has emerged: the Crisis Camp. This is an amazing way for the technology community to give back. Kudos to those who came up with the idea and organized the events!

  • Is An MBA Necessary For Product Managers?: As I ponder the question of whether I should pursue my MBA, this is valuable insight. The question will probably never be fully answered (at least not until product management is a regular MBA focus), so insights are all we have.

  • Is Dancing With Yourself Wrong For Product Mangers To Do?: This article brings up some good thinking points about a mature product. Unfortunately, it leaves it as an exercise to the reader on what to do. The "thinking points" are good enough for me to tag this in this week's From the Intrawebs, but I Would love to see more detail on this.

  • Bram Cohen: "Lawyers can’t tell you you can’t do something": Read the linked "Top 10 reasons why entrepreneurs hate lawyers", too. In all business deals, it is important to remember the lawyers are simply advisers. Your job is to make decisions.

  • When communities smother your product: This article really illustrates the value of using personaes in development. Your most vocal "good" customers are also usually in the power user realm. If all you do is listen to them, you will find yourself with a product that nobody can start using.

  • Social Media Tools for Product Marketers: A good introduction to social media tools for product marketers. If you are not already familiar with these tools, you REALLY need to be!

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are theirs, not mine. I may or may not agree, but to be on this list I think their opinion is at least interesting.

Monday, January 11, 2010

From the Intrawebs - January 11

Nothing like five out of six people in the house getting a stomach bug at the same time to make for a lame weekend. Today's From the Intrawebs is a little late as a result, and I didn't get much reading done over the weekend.

You can subscribe to the live feed of this list in your choice of feed readers. You can also follow @FromTheIntraWeb to get instant notification.
If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

  • Releasing Early Is Not Always Good? Heresy!: This is a good argument against the "release early and iterate quickly" philosophy. Worth the read on really consider what the minimum viable product is.

  • When Product Suckage Is Ok: A pointer to a response to a blog post. :) It really can't be emphasized enough that not every feature is equal in value. You should put as much effort in as you will reap value from.

  • If product managers are CEOs of their products, why aren’t more of them CEOs?: I like the focus on "Product CEO" being about influence and not about authority. I think very few product managers reign by authority, so focusing on leadership (as opposed to management) is critical to accomplishing anything.

  • Gall's Law: Something every product manager should keep in mind, especially when they sit down with the architect who wants to create a massive infrastructure to underly the product. To get to a working complex system, you have to start with a working simple system. The same probably applies to products as well.

  • What every mass marketer needs to learn from Groucho Marx: Trying to keep up with the market is hard; but as soon as you stop trying, you lose. Amazing the places you can learn valuable lessons.

  • Software product manager’s first 30 days at a new job...: Ever wanted the first 30 days at the new job check list? This is a pretty good one. First 30 days is about learning the business, and this gives some good direction for how to do that as well as some practical getting-oriented tasks.

  • A Better Decade for Product Management?: Who can help but like a post that is bullish on the future of product management?

  • Tough Times Call For You To Fire Your Customers: Another reason to ensure you are gathering good data about your customers and their usage of your product. Without that knowledge, you will never know who your good and bad customers are. Gut feel is never the answer.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are theirs, not mine. I may or may not agree, but to be on this list I think their opinion is at least interesting.

Tuesday, January 5, 2010

A Product in Trouble

AT&T Wireless is in trouble. Years of optimizing their business in favor of their shareholders over their customers has led to a customer revolt that is being noticed by the media. They are losing customers and, as a result, a critical partner is losing customers as well.

As a product manager, this is a worst-case situation: your product is sub-standard, customers are upset, partners are upset, and corporate strategy doesn't give you the resources you need to solve the problems. While a problem the magnitude of AT&T's may only be solvable at the executive level, it is (unfortunately) not uncommon for a product manager to be in a similar situation at a product level. You, Mr. Product Manager, need to fix it.

This is the time when you need to put all of your leadership training to work because it is going to take a lot of influencing to get everybody on board. Once you've psyched yourself up, it is time to roll up your sleeves and get to work!

In preparing for battle, I have always found that plans are useless but planning is indispensable. - Dwight D. Eisenhower

My experience with planning has been much like Ike's: Valuable to flesh out problems you might encounter and ways you might handle contingencies, but quickly becoming irrelevant once engaged on the field of battle. The value in planning is in determining what your capabilities are, what contingencies can be put in play, where the mine fields are, and, most importantly, what the end goal is.

The end goal is really what you are looking for here. What needs to change from where you are today and what will the positive and negative impacts of those changes be? For instance, if you are suffering from poor quality, spending time fixing defects will increase customer satisfaction and potentially reduce customer abandonment; however, it may also cause you to fall behind your competitors. It is important to recognize both the positive and the negative in order to paint a realistic picture. Doing so will give you the data to validate you are doing the right thing (we're not managing by gut feel, right?!) and adds credibility to the plan. That credibility, in turn, will help you get support from others.

Now that you've determined what the end goal is and mapped out a path to it, it's time to gather that support.

Outside the Product Team

Dealing with problems is products is never fun. It also interferes with strategic goals and can make the sales cycle more difficult as your competitors take a lead. Anything that hurts the sales cycle will not be viewed favorably by executives. If you don't handle these cases, you can find your plan being shot down before it has a chance to get off the ground. If things aren't bad enough that everybody is screaming "fix it" (and if they are, you should have started before now!), you need support to get this done.

Remember, the data you gathered illustrates why it is important, but most people still make decisions based on emotion. If your data is supporting this action, you can often find support for your objectives from either customer support or your account execs. While support is useful, if you can get your AE's on board, you have the ability to show how problems in your product are going to cause a hit on the bottom line as upgrades and additional purchases by existing customers goes down.

Support is gathered one person at a time. Get a bunch of people in a room and you'll go nowhere. Talk individually, and you can overcome resistance.

Inside the Product Team

Depending in your team, this can either be the easiest or the hardest part. Often, it is the latter.

It's easy when your team is sharp, follows good practices, is well managed, cooperates, and wants to put out a great, high quality product. Of course, if that were the case, you would probably not be in this situation.

I've seen QA teams who didn't understand the product they were testing. I've seen engineers who felt they knew what was best, no matter what the data said. I've seen sys admins who cared more about process and paperwork than about the customers using their web sites.

These are hard problems to solve; you could fill whole
books with ways to solve them; there is no way I'm going to try it in a single blog post. What you do need to do is polish off your leadership cape and get back to work. The product team must be convinced of the importance of reaching the end goal; this includes managers and contributors both!

Once everybody is convinced, you need to identify where the problems are. You will often get pointed in circles, indicating multiple problems (the QA team above also had an engineering team that was less than stellar at writing unit tests). Then you need to work with the respective managers to come up with a plan to resolve the problems. Finally, don't underestimate the impact of the "my team is perfect, everybody else sucks" attitude. That may be the hardest problem to fix.

Rework the Plan

By this point, you'll find many of your assumptions in the original plan were wrong (even if the end goal remains the same). Now it's time to update the plan based on the newly understood reality and start executing. You need to keep everybody focused and ensure you understand the priorities of things to be fixed.


As always, measure your actual results against what your expectations were. How did improving quality affect important metrics (whatever those are for your product)? If your expectations were wrong, why were they wrong?

Aside from the actual product impact, strive to make meaningful, long-term change. Not only should your product be better, but your product team should be better. Otherwise, you'll find yourself in the same situation in another three releases.

And you know you don't want to go through that again!

Image credit: Jim Girardi

Monday, January 4, 2010

From the Intrawebs - January 4

Welcome to a new year of From the Intrawebs! The holiday season is behind us and this year is looking way better than last year. Today's From the Intrawebs is short, but the quality is good enough to make up for the lack of quantity.

I believe having good data is critical to effectively managing a product, but what constitutes good data? Take a look at Eric Ries Why Vanity Metrics are Dangerous to understand why that question is important. Once you understand the question (hint: good data is actionable), you can start to figure out the answer for your product.

Here, also, are some great "top 10" blog posts that are worth checking out:

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

Friday, January 1, 2010

Happy New Year!

Just like with Thanksgiving, it is hard to have a blog and not make a New Years post. New Years posts tend to be one of two types: retrospective or aspirational. I'll focus on the latter.

My primary goal is to make my blog a better place for you. Here is how I hope to accomplish that:

Frequency: The last few weeks has seen a dip in quantity of posts. I want to keep a solid rythym going in posts with at least one new content post and one From the Intrawebs post a week. If you have any questions about product management or software development in general, feel free to send me a note via e-mail or Twitter.

Quality: Higher quantity is useless if the quality isn't worth reading. I spend a lot of time trying to gain product management knolwedge (from web sites, books, the PDMA's Visions journal, iTunesU, and anywhere else I can find). I want to more explicitly include and reference those sources to provide backing to the comments I make. While blogs will always be anecdotal and subjective, I would like to provide some weight to those anecdotes.

Voice: By the end of the year, I want to have identified my voice, so if you see a post, you'll know it's the Software Maven, even if my name isn't on the post. While that is most easily accomplished through humor (Hi, Cranky Product Manager! :), and I would certainly like to incorporate more humor, I want something different.

Interaction: I stepped outside of my comfort zone by having phone calls with people I respect for my Career Change series. I want to bring more of that kind of interaction into my blog. Again, ping me if you have ideas or would like to collaborate on something.

If you made it this far, thanks for reading. My blog has been an incredibly useful tool for myself over the last few years as I've organized my thoughts. As I move into the future and achieve these goals, I hope it becomes a valuable tool for you as well.

I hope 2010 is a happy, prosperous year for you! Happy New Year!