Let’s be honest, getting an SEO or marketing initiative on the product & engineering roadmap - and in turn the resources to execute it - can be a struggle for many marketing teams. But it’s all about proving the value of the ask to the business.
That’s where a product management business case comes in. Developing this type of stakeholder-friendly assessment of value is a big part of why SEO product managers are so crucial to prioritization-focused decision-making, roadmapping, and sprint planning (and not just for engineers!).
Onboarding the business case framework can help cross-functional teams better communicate the concept, value, and considerations backing a request for new digital products or functionality. It’s invaluable to Marketing teams - and especially stakeholders like tech SEOs - who require dev resources to fulfill critical objectives, but experience difficulty in advocating for and securing a commitment.
In this article, we’ll outline how to build a business case for new features or functionality, the type of research and analysis behind each component, and where the final output fits into roadmapping and prioritization. Plus, we’ll send you off with a <product business case template> you can take and make your own.
In the simplest sense, a business case for product development conveys the opportunity a new feature or functionality presents in alignment with user needs and high-level organizational goals. The level of detail it provides is more in line with an executive summary.
Generally, a business case is developed for the most viable solution(s) coming out of the brainstorming and ideation stage of the product management process. (i.e. Alternatives have been considered, the best opportunities were vetted, and viable asks are now brought to the table.)
The value of the initiative to the business isn’t determined by any one measure or component of the business case. It’s a holistic assessment of value based on all of the components considered together. There may be sizable research or analysis that goes into determining the various components of a business case, and that research will vary based on the type of request.
However, the output is generally simplified and standardized in such a way that makes it possible to compare cases and easily gauge their value respective to the business. This makes it easier for leadership and product managers to prioritize work in the roadmap and ensure resources are going to what’s most impactful.
Creating a business case is standard in the development process for Product & Engineering teams, but it’s a discipline that isn’t commonly adopted by cross-functional teams like Marketing & SEO. Without this documentation, it’s difficult to speak the same language, convey value, and build traction around initiatives that cross-functional stakeholders champion.
Because of this, marketing teams who struggle to advocate for dev resources often feel bogged down in manual processes and imperfect workarounds. The business case is an opportunity to showcase how automation and scale will drive more value!
The goal of a business case framework for product managers is to standardize the format for easy consideration and prioritization by leadership. Usually, a new product business case template should include the following key elements:
Elements included in a business case
We’ll get into each of these below as we share how to write a business case for a new product — including the “behind-the-scenes” work that’s required to arrive at the answers.
Developing a business case in product management is a matter of working with relevant stakeholders to accurately document the considerations and data (both qualitative and quantitative) that support and summarize an initiative’s business value. As a stakeholder vying for space in the roadmap, Marketing and SEO need to do this for their own initiatives using the same processes.
While arriving at some of these insights and metrics isn’t an exact science, there are guidelines that can help PMs collect and document the most helpful context — even when it’s a bit of a gray area, like forecasting revenue for SEO optimizations.
Below, we’ll dive into how to gather information for each element, who to work with to get it (let your stakeholders make life easier!), and how it translates into the business case template.
Along the way, we’ll use the example of an SEO initiative to show how to communicate value when it’s a little more complex. Specifically, we’ll craft a business case for an eCommerce company considering adding structured data to its product detail pages (PDPs).
This one’s pretty straightforward: describe the function or feature as clearly and concisely as possible to communicate the concept. Think of it as an “elevator pitch,” so to speak — no need to get into the granularities or reveal the secret sauce just yet!
Here’s how we could write the summary for our example use case:
What is the opportunity that developing this solution presents for our users and/or the business? To identify the opportunity, look to quantitative and qualitative data relevant to the issue. This can include, first-party data (internal reporting, user testing), secondary data (industry benchmarks), and third-party data from tools.
For example, if your internal reporting shows a large disparity between the number of users who add items to their cart and the number of completed transactions, there could be an opportunity to improve the checkout process. One way to understand the size of the opportunity would be to look to industry benchmarks for a sense of standard user behavior.
Different opportunities will be associated with different events and key metrics, which will often include custom events outlined and implemented as part of the business’s measurement plan.
Note: The opportunity in the business case is framed in the positive (rather than a negative statement - aka “not” language), as this perspective is more likely to generate buy-in amongst decision-makers. This is why we position it as an “opportunity” vs. a “problem.”
Going back to our example use case of structured data implementation, things get a little interesting...
Google has said that structured data isn’t a direct ranking factor, so an SEO product manager’s business case needs to connect the dots for Engineering & Product teams.
A big part of that will be sourcing the supporting metrics from the SEO or Marketing stakeholder. To construct the narrative, you could look to metrics like:
All of these inputs could support positioning the opportunity in our business case something like:
Increase qualified organic shoppers landing on our product pages by enabling organic search results to appear in more places with richer information.
Developing new functionality always comes with inherent risks, and those risks should weigh into the prioritization process. Understanding the risks involves working with stakeholders like Marketing, UX, and Engineering to gather their expertise and foresight.
It’s important to assess both sides of risk:
Doing the work AND not doing the work both pose risks, and risk should be considered using both perspectives!
The risks of doing the work can include factors like the impact on user behavior or potential technical issues. The business case doesn’t outline how to mitigate the risks, which happens later once the work is in the roadmap. However, those measures could be part of the research that goes into the business case to make sure the initiative is viable.
On the flip side, the risks of not doing the work will usually fall back to a missed opportunity or disadvantage that impacts progress against business objectives.
To outline the risks of structured data implementation, a PM would want to work with:
Here’s how we might write out the risk section of our example business case:
Before any development takes place, stakeholders want to be sure they can determine the impact once work is out in the wild. Did we make the right choice with our resources, based on how we affected key metrics?
At a fundamental level, this involves selecting the right KPIs and setting goals and benchmarks for each of them. But KPIs are really just one piece of quantifying value, which is determined by looking at the components of the business case holistically in the context of business goals and objectives.
The same metrics that you may have used to identify the problem are likely some of the key performance indicators given precedence in measuring impact. They are tiered as primary and secondary KPIs in the business case.
For our structured data example, some of the metrics we used to outline the issue are great for gauging success:
Here’s how it might appear in our business case:
At the end of the day, the initiative is only valuable to the org if it supports the larger business strategy and objectives. And driving success for the business at large likely boils down to more than one objective, some of which may matter more within the strategy.
These objectives could include things like:
The wording may differ between organizations, so the section should align with the language and goals used internally.
When scoring the initiative against each of these objectives, we use a scale of 1-5 to create a scorecard. The scoring measures how well-aligned an initiative is with the business strategy compared to other initiatives.
Looking at the roadmap as a whole, there should ideally be balance in the objectives you are working towards with regard to the business cases included. (e.g. If the strategic focus is all revenue growth all the time, internal operations will become less and less efficient and competitors could create a better customer experience to win market share.).
This is really a thought exercise at heart, and cross-functional stakeholders will often have the best understanding:
Here’s how we might score our example initiative:
Just because an initiative is aligned with the objective to increase revenue doesn’t mean that it’s going to drive substantial revenue.
Accurately forecasting the revenue potential of an initiative is critical in helping product stakeholders compare the value of requests in the pipeline. (i.e. two initiatives that score the same in concept, could yield very different material results.)
How straightforward it is to forecast revenue will vary from one initiative to the next. For example, quantifying the revenue impact of cart functionality that will increase the checkout rate by 5% is pretty easy:
[(current checkout rate x 1.05) x # carts with products added in period x avg. transaction $] compared to revenue from the same period
Quantifying the revenue impact of our structured data example is just as possible but a little more nuanced.
Example for Use Case
Since an organic click is further removed from a transaction than the checkout process, connecting the dots will take some problem-solving:
We would end up with the following equation:
Revenue increase = [[(current CTR x predicted increase) x PDP URL impressions for period] - actual clicks for period] x avg. revenue for organic session landing on PDP
Which would help us get to the number that informs the scoring in the business case:
So an initiative seems like it might be really lucrative — great! The thing is, it’s only as valuable to the business as the amount of resources it will take to get there. After all, there’s a difference between driving revenue and driving profitability.
Product roadmaps prioritize the initiatives that provide the most value with the least effort to make the most of resources. While this can and should be an approximation, it should also be informed by the stakeholders executing the work and carrying out ongoing work or maintenance, as they’re the ones who truly understand the level of effort (LOE).
Across business cases, LOE is communicated on a standardized scale. Further down the road, if a request makes it into the roadmap, it will be broken into tickets with deliverables, milestones, more refined resource allocation, etc.
For the business case, we’re really just looking to help high-level stakeholders understand if the work is more in line with a 100M dash, a mile, a 5k, or a marathon.
Unless the SEO stakeholder is moonlighting as a developer (and even if they are) working with the dev team will be the best way to understand LOE for our structured data use case.
To get there, it’s important to approach them as a good partner by helping them understand the work, scale, and key requirements. For our example, the foundational requirements would be something along the lines of:
Here’s how insights around LOE from our stakeholders would get scored in the business case:
In an organization where several large opportunities are in front of the team at any given moment, it’s likely that some will present similar levels of value. Which of these requests makes it into the next roadmap or sprint is in part informed by urgency.
A request is only as urgent as the story that supports it. Much like outlining the problem, justifying elevated urgency can require a level of creative problem-solving coupled with research and analysis.
Since structured data is considered an optimization, it falls into the camp of requests that take a little extra leg work. This is an area where the stakeholder advocating for the work can help draw the dotted line from insights to urgency.
For instance, many sites that haven’t optimized around featured snippets have seen organic traffic fall for key product terms, despite maintaining relatively strong SERP rankings.
Since organic traffic is often a significant source of revenue in the marketing strategy, identifying this traffic loss and tying it to sources impacted by structured data could make a strong case for urgency. The SEO stakeholder might direct us to the Free Merchant Center Listings and Featured Snippets reports in Google Search Console to confirm the story.
Looking at the competitive landscape can also help make the case if other sites have implemented structured data, as they will likely win richer, more enticing results and placements on the SERP over time (if they aren’t already). In this case, the visual difference between your organic result and one from a competitor with structured data would be one piece of support in your research.
Here’s how we’d convey urgency in the business case for our example:
With all of these components in hand - thanks to collaboration with stakeholders, research, analysis, and a little creativity - it’s time to bring them into the product management business template. Each of the items in the template is an important factor in determining business value and the easiest path to achieving business goals.
Together, these elements create a standardized output that makes it possible to gauge the business value of very different initiatives against one another. They give SEOs and marketers a powerful tool to clearly communicate the “why” in a way that leadership, product, and engineering will understand.
Take a look for yourself! Here’s the product management business case example we created together in this article:
We’ve created a template in the same format you can download, adapt, and use for your own business cases. And as always, our Product Management Services are here to help connect the dots, data, and stakeholders.
Home Search DataDigital Market IntelligenceOpinionated SEO Opinions Social Impact Careers Products Testimonials FeaturedIndustriesResourcesContact
