What Is an IDC ProductScape? How Vendors Should Prepare

A vendor can spend weeks preparing for an IDC study and still answer the wrong question. An IDC ProductScape is about the capabilities of an offering in a defined market. A polished company story will not settle whether a particular function is fully available, partly available, delivered by a partner, on the roadmap or unsupported.

For a technology company, the useful question is not simply, “Are we in the report?” It is: Are we in scope, and can we substantiate what this product does for the buyers the study addresses? That is where the preparation starts.

What is an IDC ProductScape?

An IDC ProductScape compares specified product or service functionality across offerings in a market. IDC describes five capability statuses: fully supported, partially supported, partner provided, roadmap and not supported. The resulting view helps buyers examine particular requirements. Those categories are not a league table, and inclusion is not an award.

Read the market and offering definition before reading the chart. A company may sell a broad platform, while the study examines one part of it. “Supported” can also depend on the version, deployment model, region or configuration available to the buyer. A roadmap item is a different proposition from a feature customers can use today.

Consider a vendor whose platform connects to a third-party service. Marketing calls the combined workflow “native”. Product management knows that customers need a separate partner agreement and implementation. In a capability comparison, that distinction matters. The answer needs to describe how the function is delivered, not just whether a sales demonstration can show it working.

How is it different from an IDC MarketScape?

IDC says a MarketScape evaluates an offering and its vendor against capabilities and strategy, then positions vendors in a defined market. A ProductScape concentrates on the status of specified functionality. Both can be relevant to the same company, but a feature inventory cannot do the work of a broader vendor assessment, and a strong MarketScape narrative cannot prove every product claim.

Some research programmes have both outputs. Do not assume that one invitation, questionnaire or deadline covers both. Establish what the analyst team plans to publish, which offering it is examining and what each submission needs to demonstrate.

Why might a vendor be absent?

Start with the study’s inclusion criteria rather than treating absence as a mistake. The market definition may exclude the offering. The vendor may fall short of a threshold, or the research team may lack sufficient information about a relevant product. The intake may already have closed. Those are different problems, and they call for different next steps.

This is where an ongoing analyst relationship earns its keep. It gives the team a chance to establish fit while the research is being planned, clarify what evidence will matter and record a clear answer. It does not confer a right to inclusion or change IDC’s judgement.

What should you prepare?

Build a capability record for the exact offering under review. For each material claim, capture its current status, the version and conditions in which it works, the evidence, and the person who can validate it. Product management should own the feature truth. Engineering or solution teams should be able to demonstrate it. Partner and customer teams should test claims that depend on integrations or real deployments. AR should keep the submission and the analyst’s questions together.

For example, “available” is too vague if a feature works only for enterprise customers in one region. “Roadmap” needs a different explanation from “partially supported”. If a capability depends on a partner, identify that dependency and who delivers what. This discipline protects the vendor as much as it helps the analyst: the aim is an accurate comparison, not the maximum number of boxes marked full support.

Before committing resources, confirm the scope, eligibility, research contact, intake and evidence deadlines with the IDC team. A projected publication date is not necessarily the date by which a vendor must provide information. If a product release falls during the process, ask how IDC will treat it rather than assuming the new feature will be included.

What happens when the study is published?

Compare the published view with the product available at the study’s reference point. A genuine gap may call for product work, clearer partner documentation or better evidence next time. A subsequent release does not retroactively change the earlier comparison; it belongs in a later analyst conversation.

Keep marketing claims within IDC’s permissions rules. IDC allows an included vendor to say it was included in a ProductScape, but says the results must not be presented as recognition, ranking or a comparison with named competitors. Use of ProductScape slides requires an excerpt purchase, and IDC does not allow a press release focused on announcing inclusion. Check the current permissions process before reusing research content or graphics externally.

Where Kea helps

Kea makes the research opportunity a managed decision. We track the relevant agenda, test whether the client’s offering fits the study, establish the participation route and timing with the research team, and give the client a clear go or no-go view. If it is a fit, we coordinate product, partner and customer evidence, keep claims tied to proof and make sure questions are answered before the window closes.

If the answer is “not this study”, that is still useful. We record why, what would need to change and which analyst conversation should happen next. If the vendor is included, we help product, sales and marketing use the finding accurately and keep the relationship current as the offering changes.

That is the practical value of Analyst Relations here: knowing which research matters early enough to act, and having the evidence to represent the product as it actually is.