Do your CI/MI models fit your business needs?

The goal of competitive intelligence analysis is to identify strengths and weaknesses of competitors, as well as potential threats and opportunities in the marketplace, to gain a competitive advantage. With market intelligence research we aim to better understand the market overall and make more informed decisions about product development, marketing, and other areas of operation.

A competitive intelligence (CI) or market intelligence (MI) model is a quantitative model of competitive and/or market performance, typically updated on a regular cadence (monthly, quarterly, semiannually, or annually). CI/MI models are built to provide data-centric insight into relative competitive performance and/or market dynamics.

Models can be as broad or specific as a CI/MI practitioner requires. You might have a model that tracks overall top-line quarterly and annual revenue and margin performance of a set of competitors that is used for reporting to your executive team. You may also have a detailed revenue and market sizing model that breaks down competitor revenue and estimated market size by industry vertical, geography, business line, and intersection of each, which is used by local market teams for competitive benchmarking and to set sales territory targets and AE quotas.

Models can be based on public data or non-public data. Models may be rooted in hard facts from 10-Qs and 10-Ks or extrapolated and estimated based on aggregation of multiple sources such as secondary research, macroeconomic data, unit data, interviews, and surveys (just to name a few).

That’s the beauty of models – they can expand and contract in scope and sourcing to accommodate the need of the moment.

What are competitive intelligence and market intelligence models?

When we think of models, we often think of financial performance and the tried-and-true P&L statement. This is undoubtedly one really important type of model. However, in practice, there are a number of different types of models that are used by CI / MI practitioners for different purposes. A deep dive on each type of model is beyond the scope of this post, but here’s a list of common models that we build for our research and/or are asked to build on a custom basis for our clients:

As-reported quarterly / annual competitive income statement and balance sheet models

• Industry-specific financial performance metrics (for example, in SaaS, CAC, CAC payback period, churn, expansion revenue, etc.)
• Line-of-business (reported and/or normalized) revenue and profit models
• Vertical and/or geographic revenue and profit models
• Attach and penetration rate models
• Product performance and reliability models
• Customer profiling models (number of customers, customers by account type, trajectory of customer growth and churn by customer type over time)
• Resource management models (headcount, onshore/offshore delivery leverage, utilization, attrition, pyramid structure, delivery process and operations, management span of control)
• Sales and GTM efficiency and productivity models (revenue per sales employee, sales coverage and pyramids, quota and territory modeling)
• Sales and GTM structure models (sales span of control, accounts per rep, reps per account, sales headcount)
• Price and discounting models
• Vendor revenue and profit forecasting models
• Total Addressable Market (TAM), SAM (Serviceable Available Market), and SOM (Serviceable Obtainable Market) Models
• Vendor market share models

Why build CI/MI models?

My colleague Allan Krans, leader of our cloud practice at TBR and expert practitioner in building models, wrote a great blog answering this question, so there’s no need to go deep on that question here. Models are critical for many reasons, and those reasons can vary with each and every type of model, as well as the specifics of a given project.

Overall, however, models are critical tools to help quantify an objective basis for competitive and market performance measurement. Models provide a fact-based orientation to align executives and stakeholders around when considering recurring and/or pressing strategic questions.

The ‘business need’ imperative

There’s a common saying in the world of statistics, usually attributed to statistician George Box, that says “all models are wrong, but some are useful”. Over my decade or so building financial models and delivering market research to large technology companies, I’ve heard versions of the same thing – “anybody can build a model and make assumptions in a spreadsheet” is a common refrain.

If we accept that models are by definition wrong to some degree, what makes any model “useful”? For us, that comes down nearly completely to how well the model is bult to support a business need. If a model can be used effectively to solve the business challenge and answer the questions it was designed to answer, it is successful and valuable. Otherwise, a model is just a bunch of numbers and assumptions in an Excel spreadsheet.

How to make your CI/MI models fit your business needs

There’s no one playbook or set of “hacks” that can help you build models that are actionable for addressing your business challenges. For that, only collaboration and iteration (read: hard work) will do. However, there are a number of key success factors that we believe can help ensure that a CI/MI modeling effort is aligned to your business needs. We explore each of those factors below.

• Don’t skimp on getting to the “why”: At the risk of stating the obvious, before any model is designed or built, you should spend as much time as is needed to deeply understand the business challenge or question at hand from multiple stakeholder perspectives. Ensure that all parties, including those building the model as well as those that will consume the outputs, can articulate, and agree on, the challenge that requires modeling insights, as well as the decisions that will be made based on those outputs. Define desired outcomes individually and align those to a single collective and holistic outcome for the exercise.
• Decompose the “why” into its key elements: The outcome of defining the “why” might be a complex and multi-faceted question statement – something like “Why is XYZ business unit gross margin declining?”. To translate that into an actionable project that could be addressed with a model or other solution, it’s important to decompose that question into its various sub-questions and scoping elements. A key part of this consideration is the level of granularity and validation that is needed in an answer to the question posed. Using our example, you need to decide on which competitors you are going to include in your benchmark, and how you will include them. Perhaps you need to evaluate the question and competitors you’re planning to study at a global level, or perhaps it’s a more granular investigation that involves five or seven key geographic markets, vertical and customer segment breakouts, and additional metrics. Maybe you need a quick answer for the past two calendar years, or perhaps you need a full quarterly breakdown for five years of historical data and two years of projected future data. Aim to take your high-level “why” and break it down into its fundamental elements and get agreement on those elements in addition to the top-level goal.
• Make sure a model is the right solution: Sometimes, a model can be a solution in search of a problem. It’s critical to pressure test the business challenge to ensure there is a true need for a modeling effort. Perhaps a set of customer quotes or pulling a PDF from a recent competitive presentation is all that a situation requires. As noted above, a key element of this is determining the level of validation and granularity that is needed to answer the question. Considerations to factor in at this stage are the audience that is consuming the modeling, importance and urgency of the question(s) posed, timeline (is it a one-time project need or something that should be tracked quarterly), and available budget and resources to deploy to answer the question.
• Establish an owner/SME: Lean on a RACI matrix here, or whatever version you use within your organization. There should be a single individual or team that is responsible for the modeling effort that you’ve designed. This person needs to serve as the SME for the modeling outputs, as well as the champion that ensures the model and accompanying insights are effectively and efficiently disseminated to those within the organization that need them to make decisions. Collaboration and ownership are critical to success.
• Define parameters and limitations: Behind every good question is another 100 questions. It’s important to set proper parameters on what will and won’t be delivered by the model you are creating, and what questions the model will and won’t answer. It’s equally important to set the context on how you are collecting the modeling information, and what level of validation the model corresponds to. For example, are you running a global survey of customers to inform an attach model? Or are you making top-down estimates based on publicly available 10-Q and 10-K data on services revenues and unit sales? This will clarify the business need and questions that are being addressed with your CI/MI modeling effort. This will also help condition stakeholders to proactively identify opportunities for new future CI/MI models when they arise, versus trying to shoehorn questions into existing models and processes.
• Socialize a framework before starting: Before you launch any modeling, start by building an empty model template in Excel. Populate with dummy data if you like. Create something that visualizes exactly what will be delivered as the output of your modeling effort. Now socialize that framework with the stakeholders that will consume and act on the modeling outputs and insights. This step will help align your team around business need and the outputs that will be generated to address that business need before the work starts, potentially saving you hours and hours of rework down the line.
• Start with an MVP to get the ball rolling: Let’s go back to our example company that is considering a competitive modeling effort to understand gross margin in a particular business line. If building for the first time, that company has a few options – they can build the “dream house” version of their model with tens of competitors, vertical, geographic, and customer segmentation, and multiple bottom-up sub-metrics. Or they could start with a leaner approach that aims to establish initial answers on competitive gross margins at a global level for the business unit in question. In most cases, the leaner approach is a better place to start. Why? The nature of business needs changes all the time, and hypotheses that inform the development of models change as a result. It’s often better to get something shipped first, answer initial questions, refine hypotheses, and build to greater complexity over time, versus taking on everything at once before building coalition and refining use cases for your model outputs.
• Purpose-build for iteration: Once you actually get started, don’t just dump a set of models on your busy stakeholders after six or eight weeks of data collection and building. Deliver results as quickly and iteratively as you can and seek feedback at each stage. This goes hand-in-hand with an MVP approach. Building a set of gross margin models on 10 competitors? Pick one or two to start with and ship initial models for those competitors in the first week or two. Present, distribute via multiple channels, gather feedback, and adjust the process for the rest of the program.
• Normalize at every stage of the process: This is a key foundation of all the CI/MI modeling that we do at TBR. To fit models to business needs, you need models that are easily compared to your business. The most obvious and apparent need for normalization is when designing a model structure. Let’s say, for example, that you are building a competitive line-of-business model for a particular business unit. It’s likely that you don’t exactly report revenues for that business unit the same exact way as your competitors. Before the first numbers are crunched in any modeling effort, great care must be taken to establish a strategy for normalizing results into your company’s view of the world (your business unit taxonomies, your definitions, etc.). Specific tactics for normalization are beyond the scope of this post, but are a foundational success factor for designing models that are consumable and actionable.
• Measure, debrief, and restart: Nothing is going to be a slam dunk out of the gate. To fit CI/MI models to business needs, you need to treat modeling as a continual process that ebbs and flows with the changing needs of your business. Define KPIs for your modeling effort and make sure to measure them frequently. Was the data used? How was it used? What decisions were made based off of the model and were they effective? Use this information to revisit your modeling program design, identify and implement optimizations, and restart the process for the next month, quarter, half-year, or year, depending on your chosen cadence.

Interested in learning more about how we build CI/MI models at TBR? Have a question about the approaches and methodologies we use to help our clients implement modeling programs that embody the above foundations? Contact us today to learn more!

A model is only as valuable as the validation, sourcing and trust that underly the numbers. In other parts of this series, we’ve talked about what a financial model is and how it can be used, but none of those things matter without trust in the data. At TBR, this fact plays into every step of working with clients on financial modeling engagements: upfront, during the modeling process, and in the final delivery of the models and our recommendations based on them. Here are some of the techniques we recommend for building trust in your financial models.