SaaS vs Software for Vendors – Lesson #1: Product Management Is Not Just About Features & Benefits
Posted by Paul Chen, President, Managed Services
In my last post, I talked about a number of traditional software vendors are now entering (or considering entering) the growing SaaS market. I also noted that while the two models (SaaS and traditional software) appear similar on the surface, there are significant differences between the two business models that require you to approach them in very different ways. Today, I’m going to share one of the three key lessons I’ve learned about building a SaaS business, and explain why in my opinion, it’s critical to success.
Before founding Fortiva, I started a company called FloNetwork, a very early example of a SaaS company that offered an email marketing automation service (FloNetwork was ultimately purchased by DoubleClick). Back then, one of our bigger customers came to us with a specific product feature request. It was a fairly basic addition for us, and something that we could easily pull together to make the client happy – so we did. Soon, a lot of other customers wanted the same functionality, so one by one, we added it for them.
Before long, we found ourselves with an operational nightmare on our hands. Since we made the change on a case-by-case basis, any overall product upgrades or backend changes required us to individually check and make fixes to those customers that had the feature in place – and each fix was slightly different.
Looking back, we could have avoided this problem by following a few simple rules:
- Never offer “one-off” custom features
- All feature changes should be developed with scalability and large-scale adoption in mind
- Consider long-term support of any product changes
- The product scope doesn’t end “at shipment” – it encompasses the life of the solution, including all operational and support requirements
- Keep it simple
Unlike with traditional software, adding a feature is not simply a matter of identifying a customer need, building it, testing it, and deploying it. Instead, it requires a long-term approach that takes into consideration future support requirements, operational needs, scalability, and the potential impact on future product upgrades.
Ultimately, within a SaaS environment, the scope of all product management decisions should include the impact on the vendor – not just the impact on the customer.
Read more on the SaaS vs Software: Lessons Learned series
Part 1 - Part 2 - Part 3 - Part 4

Paul,
I definitely agree with your conclusion that PM is not just about features and benefits but also business impact. However, I would say that this is not just for SaaS providers, it is true for any product company.
Thx
Posted by: On SaaS | June 19, 2008 at 04:59 PM