SaaS companies consider customer retention and minimized churn rate to be a life or death matter. In my last post, I wrote about the importance of the Product itself to that retention metric–making sure that once a customer is onboarded, the product actually meets their core needs.
While that is true, Product can have just as strong of an impact on customer acquisition as it does on customer retention.
How does SaaS Product Strategy Impact Growth?
SaaS in the freemium B2C world offers product managers lots of opportunity to influence conversion rate.
Spotify recently announced it reached 60 million active users, 25% of which are paying customers. Back in May, the number was 40 million, also with 25% paid.
How does Spotify’s feature set contribute to both the number of active users, and the number of paid users? MIT Sloan MBA student Victoria Young offers this analysis of factors by which features can be evaluated to project their impact on growth:
- Engagement Levels
- Switching Costs
- Partnership Multiplier
- Network Effects
Young evaluates several impactful features across each factor and lists the metrics that can be used to evaluate success of each feature. She further explains:
Spotify has increased engagement and switching costs through the creation of several key features: personal playlists, saved songs, featured playlists, and personal radio stations. Making it seamless and easy to “save” music on the service, Spotify removed as much friction as possible for driving up switching costs for it users. If you’ve got 20 playlists and 1000 songs saved on Spotify, deleting your account and starting a new one becomes exponentially less desirable.
This is how product leaders need to think, whether in startup or enterprise, when building products for B2C.
Joel York wrote about this in “Eleven Secrets of SaaS Product Design” — a great read for SaaS product managers:
Great SaaS product management professionals don’t simply specify features and functions; they create online experiences that satisfy business, professional and personal needs. And in the course of satisfying those needs, they drive revenue growth by pushing the three fundamental SaaS growth levers: customer acquisition, customer lifetime value and customer network effects.
How do I make my product more sticky? How do I motivate casual users to become regular users, and offer enough value for them to become paying customers? How do I enable them to encourage their friends to participate?
Long cited as a successful example of the Freemium business model, Evernote finally won me over a couple of years ago. As predicted, I started finding more and more ways to use the service, which meant I was storing more and more data in the service.
Evernote’s product vision required prioritization of capabilities that increased engagement levels. Users love being able to search the text of PDFs. Offline access is handy for reading in remote locations. And access from multiple devices is classic cloud computing.
Impacting Acquisition in the Enterprise
But how does this apply to enterprise B2B SaaS offerings, often purchased via RFP and through a lengthy sales cycle? Especially as buyers perform much of the research phase of their purchases prior to the vendor ever knowing there is an opportunity?
Here are a few thoughts on how Product influences acquisition with enterprise products:
- Solve the core problem compellingly. Once the dotted lines are all signed, is the user’s problem solved well? If so, a couple of things happen:
- First, churn goes down because your customer is successful.
- Second, you open up the opportunity for second-order revenue. Second order revenue is when a champion moves to another organization and hires your product again, or refers you to others with the same problem. In tightly connected markets, this referral business can be mandatory.
- Branded public content. Any content your app creates that can be accessed publicly should subtly encourage viewers to learn more about your offering. Even if 95% of your offering is behind a firewall, the 5% that isn’t might just be the glimpse a prospect needs to get hooked. It might even be worth prioritizing work to create public content that can be branded.
- Mobile access. Does your enterprise offering need a mobile app? Yes. Whether or not it’s addressing the core “must have” workflows or “just” a dashboard for executives, mobile is no longer an option. The impact on acquisition is that by having a presence in the app store, you may be able to support your company’s brand awareness efforts.
- Consumer-like User Experience. The more consumers become accustomed to smooth, targeted user experience in the apps they use personally, the more they demand similar experiences in their work applications. And what’s more, they know what to look for. The UX may not bring eyeballs to your website, but once you’re in consideration, it may be something that helps you win the deal.
- Trials or Standalone Apps. Free trials can be beneficial to compete against companies with more traditional sales cycles. Alternately, enterprise SaaS companies are also creating utilities, ROI calculators, and other small standalone apps to build interest in the full offering–sometimes creating data that can be used in the full offering!
- Complexity and Customization. Enterprise buyers often put high value on customization. Frequently enterprises try to get the most value for their dollar by implementing a single product into many departments. This puts varying demands on the product, which may best be met by a product that is highly configurable to the needs of the various groups that will be using it.
- Enterprise Level Features. Just because you’re SaaS doesn’t mean you can ignore the things enterprise buyers have come to expect. Scalability, security and reliability, including uptime SLA’s, need to be baked into your design. Onboarding is another concern, and this often overlaps pricing as you may have several pricing tiers that need to be segmented within the product. The need for enterprise-level features was called out in an article on enterprise SaaS on The Next Web by Leitersdorf and Schreiber:
SaaS products that fail to offer enterprise-grade features, like high reliability, integration with other enterprise products, enhanced security and customer support, are simply not adopted by large customers. These features take time and money to develop.
For early stage startups, the considerations are plentiful, and so is the work. I found an interesting passage in a post by the venture capital firm Venrock, advising against biting off too much too soon:
Those that allow themselves to be pulled thin in multiple directions find they serve no segment particularly well and have cost structures that are unsustainable. Better to nail one of the three basic models and let the market pull you emphatically up or down market as a means of successful expansion. When are you ready to broaden?
Immature products with incomplete feature sets are difficult to sell to a single segment, but even tougher to sell to multiple. Every segment has different needs that are ranked differently, and it can be nearly impossible to satisfy them all.
This impacts not only early startups with limited development resources, but really large companies as well. While the large company may have more resources for development, there is risk in developing too much of the solution before getting feedback from real customers.
Customer Lifetime Value (CLV) and Network Effect
Let’s talk a little about the other 2 levers mentioned in Joel York’s quote above.
Customer Lifetime Value increases as the average length of customer tenure increases, that part is obvious. A big lever to manage that tenure is customer success, which attempts to maintain that relationship and satisfaction over as long a period of time as possible.
Your product strategy can be adjusted to encourage clients to spend more per month during their tenure. Think of subtle ways to build awareness among users of the other offerings they’re not currently using, whether you have them already or not. A couple of thoughts:
- Maybe instead of hiding menu items for unpurchased components, you could simply disable them instead.
- Perhaps you could implement a button to test interest in performing a task; track metrics on button clicks to gauge interest prior to building a feature or product to address the need.
Network effect is an attribute that fits some products more naturally than others.
If you’re in a security related market, or the steward of sensitive information, it may be out of character for you to embed sharing tools (social media, email, etc) that could be harnessed to build awareness outside of the client organization.
The impact can be significant if it’s done in a tasteful and cohesive fashion, so it’s worth some thought.
I read this parable by Fred Wilson because of my history in dental practice management software, but the lesson is about the network effect:
We saw the cloud coming but did not want to invest in commodity software delivered in the cloud. So we asked ourselves, “what will provide defensibility” and the answer we came to was networks of users, transactions, or data inside the software. We felt that if an entrepreneur could include something other than features and functions in their software, something that was not a commodity, then their software would be more defensible.
How can you make your offering more defensible by taking advantage of the network effect?
There has to be a better way than jumping in with both feet and trying to build everything the enterprise will need quickly, with limited resources.
In an interesting post on The Next Web, Leitersdorf and Schreiber advocate a SaaS business strategy that flows in lock-step with a product strategy for developing an enterprise application from scratch:
The key to reaching enterprises is surprisingly via SMBs….
SMBs are the perfect initial customers for many reasons…..these mid-market customers provide invaluable feedback that can help the SaaS company improve the product, prioritize features development and increase value to its current and future customers.
The authors spend a good bit of time on the evolution of an early stage low-touch sales process with the high-touch methods required to sell into the enterprise. This approach also resonated with me from a product management standpoint because it advocates a rational way to approach product feature set.
For companies building an enterprise product from the ground up, especially within an established market, I’ve often argued for a 2-phase approach: Phase 1 is building a product that can win over single teams or small companies; Phase 2 is building a product that can satisfy the enterprise.
Why do I consider those as phases that happen in sequence? Two reasons:
- Frequently, the features required to satisfy single teams or small companies are a subset of those required to satisfy the enterprise.
- It’s impossible to build all the features required for both markets at the same time, and you probably don’t want to wait.
Building a single product that can support multiple teams requires deliberate effort, even if they’re accessing the same work product. Product functionality will need to grow: Workflows become more complex; data access may require more granular permission structures and segmentation features, as volume will go up significantly once more than a small team is involved.
By applying strong segmentation from the beginning–including both the specific competency or group within the enterprise you wish to sell to, as well as limiting by size–you can narrow the scope of features necessary to win deals. This early success may provide time to build the enterprise capabilities (security, scalability, etc) that future buyers will require, along with the product functionality impact described above.
All of this suggests a rational product strategy that lines up with a predictable business/growth strategy: build out the core features that will be required of a small installation of your product first. This may involve some mix of must-have features and delighters, but should all focus on single teams and small companies. Leitersdorf and Schreiber finish my thought in their post:
The early revenues can then be reinvested in the product by hiring more developers and adding the missing functionality that large enterprises will expect to see in future versions.
The art is in determining when you should start selling the enterprise customers, to get in front of the lengthy sales cycle while still ensuring success once they implement the growing product.
But it’s not all roses. There may be reasons this won’t work for you. Perhaps selling to small companies won’t give you the revenue you need to meet your growth targets. Maybe you don’t want to wait to sell to the larges. If you’re an established company, you have a ready roster of larger companies to sell your products to.
It’s worth considering that if any of those conditions are true, and you sell to enterprise out of the gate, you may be forced to make more investments in R&D than you might otherwise. One scenario where this plays out is after escalating enterprise features (scalability, backup, security, authentication, etc) ahead of product functionality only to find that the missing product functionality causes customer success issues.
SaaS Product Strategy Should Support Business Strategy
It’s conceivable that the business may find that building and maintaining the product functionality and enterprise capabilities required is too expensive, and to support that cost structure you must price beyond the resources of small businesses. Nothing says you have to keep supporting small business customers forever. I read about this example in the previously cited post by Venrock:
Aria Systems is a SaaS subscription billing provider that serves large enterprises and has found that to truly handle the needs of core business units within Fortune 500 customers requires a field sales team, sophisticated product feature sets, high touch support, and price points that can sustain such service levels. Aria has left the opposite end of the market, serving small developers with an inexpensive and simple online billing service, to competitors that are better tuned to the broad low-end of the market…
Considered in progression, this suggests a longer term approach of building an offering for small businesses, evolving the offering over time to support enterprise customers, and then eventually leaving that small business market for other vendors.
Whether or not you choose to evolve your business in that fashion, there is a larger point to be made:
Strategies are like staircases. Product strategy needs to support business strategy.
This is particularly important for sales-driven organizations, where the business may be more headstrong about its actions and assumptions than an engineering-driven one.
Are you selling to enterprises out of the gate? Better make sure the enterprise requirements are accounted for–both those the business is already aware of, and those the business hasn’t yet considered.
How many “delighters” do you require to go to market? To what depth do you need to build the mandatory features? What is the rest of your business expecting?
Ask these questions as early as possible!
You’ll find yourself in a world of hurt if you lay out a roadmap to satisfy small businesses and single teams first, while the sales and marketing organization is going after enterprises. In that case, hopefully someone will notice before it’s too late.
Thoughts? How else can SaaS product strategy support early stage growth business strategy?