Why outcomes-based product roadmaps don't work for enterprise B2B products.
How you can modernize waterfall software development.
Last week, I was advising a B2B enterprise product manager. In the quest to become more “agile” (i.e., add flexibility), her company has implemented some aspects of agile into the software development processes (e.g., sprint development). Yet, their product discovery processes were still top-down and inflexible. Because their product is for large enterprise customers, who have specific requirements, she had a hard time extending the principles of agile development beyond engineering. She recognized that she was practicing agilefall, given that requirements were defined in long, 80-page documents that took weeks to draft and weeks more to comprehend.
It wasn’t working. She knew it, but she didn’t know how to change for the better. She’s not alone in facing these issues.
Many companies, in an effort to be more innovative and flexible, continue to jump on the wagon of agile when it comes to software development. Yet, in doing so, they forget that agile is a principle. This principle is absolutely the best And when it comes to B2B enterprise products, sometimes, we product managers mistakenly jump on the bandwagon of innovation and flexibility when none is needed.
Why B2B enterprise software have trouble implementing agile?
Your customers aren’t that agile. When it comes to large customers, being flexible isn’t always their strong suit. Large companies are like cruise ships, difficult to turn. While companies may say they want flexibility, the reality is that most large enterprises want dependability, reliability, and performance. Unless you happen to be working with part of the enterprise that’s intentionally trying new things, the reality is that most enterprise customers aren’t looking for the newest and riskiest solutions.
Your company rewards for hitting output goals. Rewarding for outcomes is risky and difficult to measure. Thus, many enterprise software customers have contracts that reward for hitting milestones (i.e., deadlines) and are punished when missed. This type of incentive is then echoed inside your company where people are praised for hitting deadlines or punished vice versa. A symptom is if you see people always sandbag dates by adding extra buffers.
Promises to customers are made by people without consulting with people who have to execute. This is where sales, product, or leaders make promises to complete a sale without sufficient buy-in from those that have to execute. While it can depend on the situation, if your company has never turned away a customer, you likely have this issue.
Your company lacks people or processes that encourage creative thinking. This can be a by-product of the first 3 issues, but if you are constantly experiencing the first 3, you’re likely encouraging people to develop skills that kill creativity. Constant deadlines, the aim of output goals, and relegating people to execution roles only destroy the skills of creativity.
How to solve this problem?
“Solving” depends on what outcome you’re seeking. Thus below, I’m going to write some techniques that start easy but progressively become harder.
Change project “due dates”
Use date ranges instead of a single date (e.g., project will be completed between 10/15 - 11/10). A range of date changes how someone things about the expectation.
Identify the top 3 - 5 projects that have hard-commitment dates and only have due dates for those projects.
Move some project dates to monthly or quarterly; have some projects with no due date.
Change how to meet “due dates”
Commit to only meeting XX% of projects’ due dates (e.g., 3 out of 5 projects will be complete before date).
Separate commitments of done for hard-commitment dates versus all other projects. (e.g., we’ll hit all hard-commitment dates, but all others, are more general targets. This still means you should report on if the other dates are ever hit or abandoned).
Replace project due dates with a business metric
Change how to communicate product and project roadmaps
Simply project roadmaps by lumping all projects that don’t have a hard-commitment date into one or two categories.
Create separate documents for communicating product versus project roadmaps. Note that not all product roadmaps will have project roadmaps. Read: “Supplementing product roadmaps with project roadmap.”
Create separate product roadmaps for large enterprise customers vs. non-enterprise customers.
Change how product requirement documents are written
Complement your large, detailed PRD with the backwards written press-release and FAQ. Use it to write everything in simple, plain English.
Identify the 5-7 most critical functional requirements by the enterprise customer or anything that’s contractually obligated.
Have the product manager and engineering leader sign-off on the contract with a customer before development begins. Given them the power to veto a customer per quarter.
While these are all tips or tricks, I’ll end with the point that sometimes, it isn’t always necessary to be agile. In other words, we shouldn’t always give unlimited flexibility.
There is a cost associated with flexibility. This flexibility is requested because sometimes we are uncertain when building software. This uncertainty means what we build might not work. Thus, we should be flexible and react to failure, hopefully, learn from it.
But often, if we had spent more time thinking about the problem, we could reduce our uncertainty without building anything. In managing B2B enterprise software customers, this means we don’t ask our customers enough tough questions to understand their wants and needs. Instead, we jump from assumptions to conclusions and a product to address uncertainty or indecision. If only we had pushed to better understand, pushing our customers to define or jointly identify what’s acceptable. Instead, using the building process as a way to manage uncertainty and that’s why agile isn’t right.
Additional reading
Agile Bridge Building (for those that want to read what happens if we adopted agile when building a bridge)
Are you working on a B2B enterprise product or know someone? If so, leave a comment to share your war stories.
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.