1) We probably need another term for the type of SaaS product the PM was working on here. My gut is that it's a semi-customizable solution and her company has very few customers with huge ACV. Enterprise SaaS, from my understanding, is very similar to traditional SaaS since very few products are hosted on the customer's own servers nowadays, but refers to solutions that have long sales cycles, large contract values, and tons of users at the very large company (think Jira or Salesforce). While the challenges are different, you generally don't have such unique requirements that would force PM's to basically execute on a list of features since the core functionality is extendable to all types of customers.
2) In the case where you are truly customizing software, I agree with a lot of what you wrote here. HOWEVER you're only thinking about the challenges PMs face at the start of the relationship with the customer. SaaS is lucrative because the LTV is very large since there's a ton of lock in. This is where outcomes-based roadmaps do come into play. You can sell the idea of operational efficiency, cost savings, more sales prospects, etc. but when it comes to the customer thinking abut renewing their contract, if you're unable to actually drive any of these value adds, you're not going to retain the customer.
1. Agree on a better term. What should this be called, this "semi-customizable solution". Enterprise-services SaaS? Customized enterprise SaaS? Something else?
2. I think you're talking about what happens during renewal, in that if you just "follow what the large customer demands", but it doesn't actually create enough value, the customer will abandon.
More specifically, I think you're pointing out that sometimes, what the customer demands in terms of features in these large ACV contracts aren't the features that drive "value". So, what to do here? You have to meet the contractual requirements (i.e., demands); that's one type of ask. But I think you're saying you also need to still figure out the "value-add" as well, and that side of the brain, you want outcome-based roadmaps?
So, two types of roadmaps, one project-based and one outcome-based?
I suppose it matters what the nature of the contract / relationship is. If the customer is 100% driving feature definitions, you're essentially a dev shop with a set of core functionality that you have right out of the box. If this is the case, you're not even talking about product management, you're more of a technical project manager imo, so everything is just pure project and dates driven.
If this is not the case, then I think what you're saying makes sense.
Couple thoughts here:
1) We probably need another term for the type of SaaS product the PM was working on here. My gut is that it's a semi-customizable solution and her company has very few customers with huge ACV. Enterprise SaaS, from my understanding, is very similar to traditional SaaS since very few products are hosted on the customer's own servers nowadays, but refers to solutions that have long sales cycles, large contract values, and tons of users at the very large company (think Jira or Salesforce). While the challenges are different, you generally don't have such unique requirements that would force PM's to basically execute on a list of features since the core functionality is extendable to all types of customers.
2) In the case where you are truly customizing software, I agree with a lot of what you wrote here. HOWEVER you're only thinking about the challenges PMs face at the start of the relationship with the customer. SaaS is lucrative because the LTV is very large since there's a ton of lock in. This is where outcomes-based roadmaps do come into play. You can sell the idea of operational efficiency, cost savings, more sales prospects, etc. but when it comes to the customer thinking abut renewing their contract, if you're unable to actually drive any of these value adds, you're not going to retain the customer.
1. Agree on a better term. What should this be called, this "semi-customizable solution". Enterprise-services SaaS? Customized enterprise SaaS? Something else?
2. I think you're talking about what happens during renewal, in that if you just "follow what the large customer demands", but it doesn't actually create enough value, the customer will abandon.
More specifically, I think you're pointing out that sometimes, what the customer demands in terms of features in these large ACV contracts aren't the features that drive "value". So, what to do here? You have to meet the contractual requirements (i.e., demands); that's one type of ask. But I think you're saying you also need to still figure out the "value-add" as well, and that side of the brain, you want outcome-based roadmaps?
So, two types of roadmaps, one project-based and one outcome-based?
I suppose it matters what the nature of the contract / relationship is. If the customer is 100% driving feature definitions, you're essentially a dev shop with a set of core functionality that you have right out of the box. If this is the case, you're not even talking about product management, you're more of a technical project manager imo, so everything is just pure project and dates driven.
If this is not the case, then I think what you're saying makes sense.