The software industry has changed dramatically since the early days of only rewarding teams based solely on their ability to deliver working product ‘on-time.’ Today’s successful companies provide further rewards for the team’s ability to help customers build habitual use of the product over time.
Traditionally in software product management, the primary responsibility is to develop the product and deliver a completed functional feature for the customer. The SaaS product manager’s responsibilities include connecting user pain points and customer issues related to software usage directly back to their subscription (or revenue) model.
This guide provides detailed definitions of the typical workflow, business responsibilities, and key metrics that characterize this working relationship.
Summary
The primary function of a SaaS product manager is not only to build the software, but also to be accountable for the viability of the subscription business. It is typical for a software product manager to create connections between customer pain points and problems, the technical delivery team that creates the product, and the recurring subscription, or revenue, associated with the product.
The software that the product manager takes from initial product discovery through to long-term account expansion will successfully balance the user experience with operational costs and market positioning. A SaaS product management focus requires a greater emphasis on the continual customer retention, product usage, and lifetime customer value metrics.
Moving from a Traditional to a SaaS Product Manager
Most traditional product manager positions allow for finite launch events. Researching the market, building the software, selling it, and moving on to the next release/version are the traditional ways of product management.
With the advent of SaaS, however, the lifecycle of the product never truly ends. A subscription-based software product must continue to prove its worth to the customer month after month.
How a SaaS Product Manager Takes Commercial Responsibility
The most significant change in this role is the shift from simply managing the timeline of a product release to being commercially responsible for the product throughout its entire subscription lifecycle. The expectation is that once the product has been brought online, the SaaS product manager will assume an ongoing commercial responsibility for its continued functionality and success.
Managing the underlying cost of serving all users, the complexity of multi-tenancy, and your user base's financial health, API limits, feature gating, and enterprise plan packaging are all decisions for which you are responsible.
A Continuous Delivery Model
While traditional hardware/products are shipped infrequently, or in large batches—subscription software is continuously delivered. With this constant state of flux, a continuous focus on both reliability and support costs and also on visible improvements is extremely important.
In this environment, shipping a fast but broken feature can result in immediate spikes in support ticket volume and increased churn risks—both significantly affecting net revenue retention.
Core Responsibilities of a SaaS Product Manager
Those who operate in this type of environment must establish an operating pace unlike any other. The best-performing practitioners start by collecting concrete evidence—not merely talking to a user about their experience, but rather collecting evidence of a user's actual results.
Understanding Market Problems
Each cycle begins with a combination of qualitative and quantitative evidence—drawing data from three feedback loops. These loops consist of:
Direct interviews with customers, usability sessions.
Quantitative measurements of a decrease in specific workflow completion.
Negative comments from lost enterprise sales opportunities.
The objective is to clearly identify: the specific user problem; a user's existing workaround; and what effect not correcting this problem will have on the user’s business. A diagnosis completed on the basis of data will prevent a team from becoming a simple "order taker" for noisy enterprise clients.
Prioritizing Projects with Limited Resources
Scoring competing initiatives must be based on hard evidence—not contrasting the volume of your company's executives. A reasonable framework for evaluating competing initiatives includes determining the number of users affected, the estimated impact on the retention/expansion rate; the estimated engineering effort; and the strategic importance of the initiative.
At first glance, a custom export feature may seem worth a lot of priority effort (even though it may seem like a low level). If the custom export only benefits three customers and has high ongoing maintenance (three or more), the priority score will be reduced significantly.
Working with Cross-Functional Teams
Building something incorrectly is still considered failure, even if it is done with great efficiency. Before committing all the engineering resources and building a product, designers and developers should validate the idea using clickable prototypes, concierge testing and design-partner programs.
Once validated, have the product engineering team check with the marketing team to ensure the product is safe to use and will not break when it launches; provide the sales team with the buyer-facing value proposition; and inform the customer success teams of what to do to help onboard users.
Measure Adoption and Not Delivery
Just because you launched a feature does not mean it is successful. For a saas product manager, measuring the level of success relates to how many customers have already adopted the product. To get a full measurement of product adoption, you will need to aggressively track the following:
Customer exposure and initial discovery of a feature.
The customer's first successful use and the time taken to receive value from the use of a feature.
Customer repeated usage of the feature for 30 days in a row.
For instance, if you launch an anticipated release and only 5% of your customer base takes advantage of it, you are not finished. You must close the feedback loop with customers, find out where customers stopped using your product, and modify the user interface until users are able to complete the intended workflow.
Key Metrics That Help You Grow
To effectively manage a recurring business model, you will need to measure and keep track of the right metrics. If you have no metrics to track, you may find that your product has been bloated and is no longer profitable.
Monthly and Annual Recurring Revenue (MRR and ARR)
The MRR and ARR figures provide a financial foundation of your subscription business; they give a customer revenue forecast against which sales teams can generate new revenue, product strategy decisions will dictate if that revenue remains or grows.
Churn Rate and Net Revenue Retention (NRR)
Churn Rate is the number of customers that stop using your product/service during a specific time frame; Net Revenue Retention (NRR) is likely the most important metric for your business. NRR measures how much revenue you can grow from your existing customer base by taking into account the revenue generated from your existing customers at the time of subscription (the start of their subscription), the revenue generated from customer additions, the revenue lost from customer churn, and the total number of subscribers at the time of subscription.
Best-in-class enterprise companies generally target an NRR above 100% because they are generating revenue growth from their existing customers even if no new customers signed up during a specific period.
Cost to Acquire Customers and Payback
Customer Acquisition Cost (CAC) represents the total sales and marketing expense to gain one new customer. The CAC Payback Period represents how long it will take for a customer's monthly subscription payments to fully pay back the initial CAC for that specific customer.
If a customer onboards with a lengthy or complex onboarding experience, they may quit before they even pay you back for your CAC expense, resulting in a loss in profit margin.
Real-World Examples for a SaaS Product Manager
Theoretical frameworks are important to the success of your SaaS business; however, actual value to your business is created when you experience operational pressure during stressful moments of day-to-day operations.
How to Fix Low Initial Activation Rates
"Most of your new users sign up but do not perform their first meaningful action." This is a common occurrence. Instead of building a lot of new features, the appropriate way to respond would be to segment the activation rate by acquisition source and analyze the actual onboarding sessions for all new users.
Once you have reviewed those sessions, you will be able to identify where users are dropping off and begin testing shorter paths to value and then tracking subsequent cohort retention rates. Activation is the most critical step in building a long-term retention rate.
How to Fix High Monthly Churn Rates
You are continually shipping updates; however, your retention rate continues to decline. You need to assess the relationship between the release activity and the support volume, reliability incidents, and expectations that were established as part of the initial sales cycle.
In most cases, the challenge is not that there is inadequate functionality; instead, there are frequently slow times to value, rising numbers of bugs, or an inability to perform the most critical tasks that a buyer has hired the software to accomplish.
How to Navigate Complex Packaging Changes
When the executive team decides to move a commonly used integration to the higher-priced premium tier, you will have to manage the fallout. Navigating existing entitlement rules, defining grandfathering criteria for early adopters, establishing usage levels, and facilitating communication around migration of customers from one subscription environment to another are all part of the mitigation process.
In determining the potential for expansion, you will weigh the immediate risk of alienating a loyal customer base against the long-term opportunity for increased revenue from an expanded solution offering.
Working in Different Subscription Types
A software's day-to-day workflow can change drastically based on the target audience for that software and the specific sales channels used.
Differences Between Product-Led Growth and Enterprise Sales
In a product-led growth model, software must sell itself. As the saas product manager, a significant amount of your time is spent on facilitating self-service onboarding, creating viral sharing loops, and developing automated paths to upgrade. There is little human involvement.
The dynamic of selling into enterprises, however, is different. When selling into enterprises, you have many stakeholders to consider: the economic buyer, the IT administrator responsible for security, and ultimately, the daily user. You must satisfy the needs of each of these three very different groups to avoid churn.
Understanding the Product Owner Role
In the majority of teams, there is often confusion around what constitutes strategic management versus what constitutes project tracking. For a product owner, the focus is primarily on the agile development process: managing the product backlog, writing user stories, and running sprint planning.
The larger management function looks outward. The saas product manager is responsible for market research, pricing strategy, and commercially acceptable outcomes. While some product managers do combine these three responsibilities, separating them allows one to concentrate on building the product correctly and one to concentrate on building the correct product.
Tools for a Modern Workflow
There are essential systems necessary for effective operation to perform market research, manage and track customer data, and complete data analysis.
User Research and Discovery Tools
Before starting to create the first line of code, research (user discovery) must be performed to verify an idea. The research is completed by speaking directly to users, observing users interact with the system in context, and performing an analysis of customer support tickets.
Some tools that assist with this process include continuous feedback portals and Jobs-to-be-Done (JTBD) research models. The purpose of these projects is to isolate the difference between what users say they want from the tasks they are trying to accomplish.
Product Roadmaps and Tracking Tools
A product roadmap is a strategic document, not a timeline of expected delivery dates. It contains trade-offs, and strategic themes are assigned scores, which are then compared to determine their respective level of importance. Engineering, design and marketing teams all use the same source of truth (through delivery tracking software) to convert the strategic themes into technical sprints to maintain organized progress for all involved parties.
Analytics and Data Tools
The continuous delivery of modern products relies exclusively on analytics. You can track what users are doing through cohort analysis and funnel completion and product feature adoption. Analytics can identify where users are struggling with your product; this information allows you to close the feedback loop and quickly iterate based on the actual experience of your users.
Final Thoughts: Connecting Software Code to Revenue
Ultimately, the bridge between technical execution and business success is the role of the saas product manager. If a highly sophisticated technical platform does not activate any users, it will eventually collapse under the burden of carrying its customer acquisition costs.
Conversely, a basic platform that is aggressively sold will have an insurmountable level of customer attrition. To create success, we need to convert our validated evidence of value into software decisions that create enhanced daily experiences for users while generating predictable, recurring revenues for the business. The most successful professionals in this space do more than just write code. They create and maintain customer behaviours that produce profit.
Common Questions and Roadblocks
What is the best way to balance pressures to deliver the enterprise sales team’s roadmap?
The nature of a sales team is to aggressively sell and close deals immediately; therefore, they will always want custom features. We must investigate the workflow necessary to fulfil their request. Is the request related to compliance, reporting, or procurement? How many accounts also need this solution? If the solution is specific to one account and could not serve multiple segments, or requires a significant amount of custom maintenance, we should push back by presenting any data we have regarding support load and implementation expenses.
Why do we not see the velocity of our feature shipment translating into account expansions?
Shipping speed alone does not equal value. If the rate of shipping for updates continues to be quick, but there are no increases in the rate of account upgrade, it is likely that we are developing features that are not meaningful, and therefore do not create any improvement in the customer's workflow. We need to begin measuring volume of output (shipping activity) and also the amount of discovery made, along with the amount of repeat usage of features. We should ensure that our marketing and customer success teams are fully equipped to promote in-app awareness; otherwise, any hidden features will not produce any revenues.
When should engineering resources and time be used to address technical debt vs visible user improvements?
When the gross margins of a product become threatened by increasing levels of existing bug frequency, platform maintenance should take precedence over visible user developments. The way we justify the delay of any visible progress is by connecting our combination of efforts related to engine maintenance with our risk of business continuity: increasing volume of support tickets, degrading site performance (e.g., page load times) resulting in drop-offs, and critical enterprise security concerns. A well-maintained infrastructure is a core component of any subscription-based service.
