Outcome Roadmaps are all about focusing on the work that directly ties to driving results that your Product Strategy defines as important. However, anyone that has worked on software products knows not everything that we do aligns with some predefined plan. This is ok and to be expected.
The Outcome Roadmap is really a time horizon way of looking at the Product Backlog. However, for teams following Scrum or similar practices, you will note that the Product Backlog should contain everything that is known to be needed in the product.
Specific Outcomes are not the only things known to be needed in a product. Here are the types of things that are commonly known to be needed.
-
Outcomes
-
Features (Committed or Otherwise)
-
Bugs
Most of our work in the Product Backlog will fit into these three groups but it is entirely possible that you may identify an additional grouping.
Features on the Outcome Roadmap
Why include Features in the Product Backlog? If we define Features as the functionality that solves a problem or addresses a need, it would appear that Features should be defined only as a result of the Product Discovery work on desired Outcomes.
While this is true in theory, in practice we sometimes need to manage Features in the backlog in order to support broad business objectives.
Possible reasons for prescribed features in the Product Backlog include:
-
Strategic Customer Commitment
-
High Customer Demand
-
Partner Planning Need
-
Regulatory Requirement
-
Other Market Necessity
The next sections will dissect each of these reasons.
Strategic Customer Commitment
The most common sign that a product is being led by sales and not driven by product strategy is a high number of committed features on the roadmap. This type of commitment overhang is difficult to get yourself out of and product organizations should work hard to not allow themselves to get into such a situation, to begin with.
That extreme is not what I am going to describe here. It is reasonable to expect that within enterprise software, some strategic customers may request specific features to be added to the product from time to time. Sometimes it does make sense for a business to respond to these requests with a commitment to deliver but these should be limited and intentional decisions.
Decisions to commit to a feature should be aligned with the product vision and rare.
Considerations: Strategic, Specificity, and Strength.
Customers (or prospects) may be deemed Strategic because they have outsized market influence, provide significant sales references, or represent a beachhead to a new desirable customer segment — all criteria that should support the business strategy. If a customer does not fit into the definition of Strategic, then you should never make a feature commitment uniquely for them. By definition, only a small percentage of your customers should be considered strategic.
Features may have different degrees of Specificity of acceptable design. Some features are defined in great detail by the customer and others would be accepted by addressing the underlying requirements. On the extreme, you may be able to reframe the “feature” as a desired Outcome with the customer agreeing to any option that addresses the ultimate desired Outcome.
Due to these variations, it is critical not to treat all Feature Commitments as equivalent constraints to the Product Discovery process.
The Strength of the commitment is the final constraint that needs to be considered. Some commitments are written into a contract with a fixed deadline and some are loosely implied through a sales process, with a range in between. Once again, it is very important to understand and track the strength of the commitment to a strategic customer — not treating them all equally.
Frequently, we can find that perceived commitments that arise during a sales process may result from a series of miscommunications. Another common source of miscommunication is in sharing prototypes with customers that are then perceived to create delivery commitments.
Product Management needs to work hard with all parties in the organization to prevent such weak commitments and actively pursue approaches to undo expectations early so that constraints to business agility are not set in stone.
When there are hard commitments made, these constraints need to be communicated within the Product Team and tracked. I have witnessed many instances where a hard commitment, eventually becomes unimportant to a customer or could be rendered moot with the passage of time. When this happens, Product Managers must be able to rapidly free the team from this constraint.
Example Features:
-
Integration to Dropbox – A strategic customer that has invested heavily in standardizing document storage with Dropbox demands a commitment to support seamless integration within your workflow tool before signing their annual renewal agreement.
-
AWS deployment support – As a startup, you focus on Azure deployment infrastructure but a strategic prospect will only signup if you commit to AWS in the next 12 months.
High Customer Demand
Unlike a commitment to a specific strategic customer, sometimes a significant group of customers a demanding the same feature. In some cases, I have witnessed customers band together under the expectation that they will create more leverage influencing a roadmap by finding their shared needs.
Frequently, this self-organizing community of users with shared needs can be a huge benefit. Still, they often suffer from dictating solutions (features) to product organizations. Great product organizations find a way to leverage these shared demands in their product discovery work and shift the discussion toward desired Outcomes.
Still, there will be times, when the best tactic will be to commit to addressing their requests in order to demonstrate that you are listening to them. The best such commitments will not be tied to a hard deadline or bound be a specific feature definition.
Prioritizing some of these in the Product Backlog will drive a perception that you are actively listening to the market.
Example Features:
-
Two-factor Authentication using SMS – Multiple enterprises may get together and push for this feature if lacking in an enterprise application.
-
Job Requisition EEO Report – Multiple large firms may demand that LinkedIn provide a report to show they are complying with EEO requirements in their job listings to reduce their manual reporting burden.
-
Usage Report – Multiple customers may request a specific report around how their employees are using an employee benefits system that currently makes it very difficult to ascertain ROI on. Without this, they threaten to drop the service.
Partner Planning Need
Now more than ever, enterprise software is reliant on networks of related products and service offerings. This is in addition to old models of OEM based technology partnerships that are still a significant part of both cloud and on-premises software products.
At times partnerships require shared investments to deliver integrated value to the end customers. It is a rare partnership that works closely together to perform Product Discovery work as if part of a single solution team. Instead, partners agree to integration specifications and delivery timelines.
You may choose not to work with partners unwilling to perform discovery work together but that will be severely limit your partnering opportunities. As such, it is both pragmatic and reasonable to create aligned plans that will get the product to market.
Example Features:
-
Inventory Check API – A local merchant working with a logistics partner. As part of the partnership, you agree to enable their software to query your inventory for their system to validate item availability. Both ends of the integration need to be complete before the whole solution can launch to their customers.
-
Brandable User Interface – You have agreed to white-label your reporting services to allow a diverse set of software markets to benefit from them. Before a big vendor will work with you, you must coordinate on specific branding elements they can control when embedding your UI into their experience.
Regulatory Requirement
Whether your product is operating squarely in a highly regulated market, directly supporting regulatory compliance needs, or neither of those — there are times when most software products will be under the pressure to meet prescriptive regulatory requirements.
In most cases, your product will be at a significant disadvantage if it does not address the requirements within a time frame. In some cases, your product will cease to be viable if you do not comply.
If the regulatory requirement is not prescriptive in nature, then it may be considered a time-constrained desired outcome. For those regulations that are highly prescriptive, the product team will treat it as Feature, with the only question left of how best to deliver on it.
Example Features:
-
GDPR Compliant – For products intended for use in the EU and EEA, due to the potential liability and penalties, businesses there require this support.
-
IRS 2020 Tax Code Updates – For applications, like tax preparation software, that organizations rely on for critical business functions, if you do not include this feature in a timely manner, you will not have customers.
-
Prevent Money Transfers to Sanctioned Countries – If you have a payment service or other product that can initiate international payments, it must have the capability to prevent payments to a continuously updated list of sanctioned countries.
Other Market Necessity
At times there are significant requirements tied to your product strategy that are table stakes for your market. Often this may be related to supporting popular third party technology within your market. Other times, it may be industry standards for compliance or operations to be considered a viable option.
These Features are not commitments and as such, teams are free to attempt to reframe the problem in search of better alternative solutions. However, frequently this can be a waste of Product Discovery time and would not create a differentiation advantage to solve it in a different way.
Example Features:
-
PCI Compliant – If you are in the payment card processing ecosystem, merchants will not buy your product unless it is compliant with industry-standard PCI-DSS.
-
Internet Explorer support – Back in 2010, if you built your end-user application on Chrome and it was not supported on Internet Explorer you could not sell it to the majority of businesses that only allowed IE by employees. It was a non-starter.
-
Data Backup and Recovery – If your software stores business data, it will not be long before you must include this fundamental risk management feature.
Product Discovery Implications
All items that have been prioritized in the Product Backlog should be collaboratively discussed and vetted by the Product Team – not just the desired Outcome items.
Depending on the group the backlog item fits into there should be a general agreement on (1) how much validation is required and (2) what artifacts should come out of the validation process. This will make the discovery work of each item more efficient.
The overarching goal is to prepare items for the Development Track before Sprint Planning takes place.
Product Discovery work should be ongoing in parallel to the Development track. The time it takes to conduct discovery and validate an item will vary. Bugs tend to require minimal discovery work, while desired Outcomes can take weeks. Features tend to fall somewhere in the middle.
The important concept to note is that regardless of the grouping or source, items in the Product Backlog should be going through a discovery process.
Conclusion
While Outcome Roadmaps are essential to focus the team around what matters. It is realistic and practical to accept (committed) features into the backlog from time-to-time. These should be minimized and still need to be validated before rushing into Development.
As product leaders, we need to be careful not to hold too fast to best practices when reality dictates otherwise.