MODULE 02 · ICP & SEGMENTATION

One Product, Multiple ICPs

One product can solve different problems for different accounts, but that does not mean every use deserves its own ICP. This guide shows how to split distinct buying systems while preserving one coherent product strategy in practical B2B execution planning.

DEFINITION

What is this about?

Create multiple ICPs for one product when the application, commercial relationship, qualification requirements, buying path, or service obligations are materially different. Keep accounts in one ICP when those differences only change wording or minor preferences. Each ICP branch should have its own hard gates, evidence rules, value hypothesis, and validation sample, while shared product facts remain controlled in one source.

KEY TAKEAWAYS

  1. Split ICPs when the buying system changes, not whenever a new industry appears.
  2. Application and relationship type are stronger branch points than generic personas.
  3. Shared product facts should remain consistent across every ICP branch.
  4. Prevent double counting with account-location-application relationship records.
  5. Choose one primary branch for execution and bound the others as tests.

Who this guide is for

This guide is for teams selling a product that appears relevant to several industries, applications, or channel paths. It is particularly useful when the same component can be designed into equipment, sold through distribution, installed by an integrator, and purchased directly by an operating facility.

Contents

1 Recognize the multiple-ICP problem 2 Separate product truth from ICP hypotheses 3 Apply the five split tests 4 Build an ICP branch map 5 Prevent overlap and double counting 6 Choose a primary branch 7 Use the branch worksheet 8 Illustrative example 9 Common mistakes 10 What this does not mean 11 Common questions 12 Sources and methodology

1. Recognize the multiple-ICP problem

One product may travel through several economic systems. A corrosion-resistant enclosure could be specified by an engineering contractor, integrated by an equipment OEM, stocked by a distributor, and operated at a water-treatment facility. The physical product may be unchanged, but the source of demand, qualification evidence, commercial terms, and post-sale obligations are different. Broad industry statistics can reveal possible contexts without defining those systems. The Bureau of Economic Analysis publishes input-output accounts that describe relationships among industries and commodities. BEA - Input-Output Accounts Those flows do not prove that a named account has a relevant application or buys through a particular relationship. At the opposite extreme, creating an ICP for every industry, country, or marketing message produces dozens of profiles that cannot be governed. The right question is: Does this group require a materially different account qualification and commercial decision? If yes, it may be a separate ICP. If not, it is probably a filter, subsegment, or message variation within an existing ICP.

2. Separate product truth from ICP hypotheses

Maintain two distinct records. Product truth contains facts that should not change by segment:

• technical specifications and tolerances;

• supported environments and exclusions;

• certifications and documented compliance;

• manufacturing, lead-time, and customization boundaries;

• warranty and service policy;

• approved claims and evidence. ICP hypothesis explains how those facts connect to one buying system:

• account unit and application;

• commercial relationship;

• operating problem and alternative;

• qualification and access conditions;

• buying path and support obligations;

• evidence states and disconfirming criteria. This separation prevents a team from quietly changing product claims to make each segment look attractive. It also allows one verified product fact to support several branches without copying and drifting. Official industry codes belong in discovery, not product truth. The Census Bureau states that NAICS groups establishments according to their economic activities for statistical use. U.S. Census Bureau - NAICS Two establishments with the same code may still have different equipment, processes, standards, ownership, and buying models.

3. Apply the five split tests

SellersGPT recommends five tests. A material difference in one critical test, or a coordinated difference across several, can justify a branch. Split test Keep together when Split when Application The same function, conditions, and consequence apply The product performs a different function or faces different hard constraints Relationship The account plays the same OEM, distributor, end-user, or contractor role The transaction role changes buying economics or responsibility Qualification The same technical and commercial gates apply Approval, validation, certification, or documentation changes materially Buying path The same organizational process can move the purchase Project, design-in, stock, site maintenance, or central procurement follows a distinct path Fulfillment Delivery, support, warranty, and lifecycle obligations are comparable The branch requires a different service footprint, inventory model, or risk boundary Do not split merely because:

• two industries use different terminology for the same process;

• company size changes but the operating and buying system does not;

• a contact has a different title;

• one geography requires localized copy but no material commercial change;

• a campaign needs a more specific message. Conversely, do not merge an OEM design-in motion and a replacement purchase at an end-user plant simply because the product SKU is identical.

4. Build an ICP branch map

Begin with application, then relationship. Use a tree rather than a flat list: 1 Product function: What job can the offer perform? 2 Application environment: Where and under what constraints? 3 Relationship: Who integrates, resells, operates, or delivers it? 4 Buying motion: Design-in, stock, replacement, retrofit, expansion, or project? 5 Access and service: Can the path be reached and supported? Create a branch only when it has a distinct decision record. Each record should contain:

• inclusion and exclusion criteria;

• hard gates and unknown or contradicted dependencies;

• minimum evidence required;

• named account unit;

• value hypothesis and alternative;

• relationship-specific obligations;

• a bounded validation plan;

• an owner and review date. Use the collection-wide evidence states on material branch fields: confirmed_fit, confirmed_non_fit, contradicted when accepted sources materially conflict, and unknown when the required claim has not been established. Use not_applicable only with a reason. A failed criterion is confirmed_non_fit, not contradicted. First-party evidence helps validate branches. Public-company reports and other filings available through EDGAR may describe products, segments, facilities, capital programs, customers, and risks. U.S. Securities and Exchange Commission - Search Filings Preserve the filing date and the exact entity or segment; do not infer that every subsidiary shares the reported application. Project branches can use procurement evidence where appropriate. SAM.gov contract opportunities include notices such as solicitations and awards from federal contracting offices. SAM.gov - Contract Opportunities A notice may confirm a project requirement or party role, but it does not prove recurring demand beyond that procurement.

5. Prevent overlap and double counting

A company can validly appear in several branches. The solution is not to forbid overlap; it is to count and govern the correct unit. Use this composite record: ICP branch record = parent + entity/site + application + relationship + buying motion Then distinguish three counts:

• Unique parents: corporate groups represented.

• Unique operating units: entities, establishments, facilities, or project sites evaluated.

• Qualified branch records: application-relationship combinations that pass their gates. Never sum branch records and call the result “companies” unless they are mutually exclusive and deduplicated at company level. If a plant has both a replacement use and a new-build project, it may create two buying-motion records but remains one plant. Add overlap fields:

• competing or complementary branch;

• account owner;

• channel-conflict state;

• contact-policy state;

• latest evidence date;

• permitted next action. This lets one coherent account plan replace several uncoordinated campaigns.

6. Choose a primary branch

Multiple ICPs do not require simultaneous full execution. SellersGPT recommends one primary branch and a limited number of explicit tests. Apply hard gates first:

• product and application compatibility;

• mandatory qualification feasibility;

• legal and commercial permissibility;

• delivery and support serviceability;

• unresolved channel conflict. Then compare viable branches on five decision criteria: evidence strength, repeatability, accessibility, economic compatibility, and learning value. Score each 0-4 only after defining anchors. Keep unknowns separate; do not assign them a midpoint. A weighted score is a ranking aid, not a forecast. It cannot override a hard gate. The selected branch should also have a clear reason for being primary, a fixed initial account sample, and a date for review. Secondary branches receive one of three states:

• Bounded test: a small evidence or account validation task.

• Watch: monitor a named trigger or dependency.

• Park: no work until a stated condition changes. This preserves opportunity without fragmenting the operating team.

7. Use the branch worksheet

Field Branch A Branch B Branch C Product function Application and conditions Account unit Relationship type Buying motion Hard gates Evidence state confirmed_fit / confirmed_non_fit / contradicted / unknown / reasoned not_applicable Support obligation Overlap rule Disconfirming condition Decision state Primary / test / watch / park If two columns are materially identical after completion, merge them and retain the difference as a tag or message field. If one column contains several contradictory buying paths, split it.

8. Illustrative example

Illustrative example - explicitly fictional. Meridian Sensing, a fictional supplier of vibration sensors, begins with 80 application-relationship branch records derived from 76 unique operating units. Four operating units appear in both the end-user and integrator branches. Research identifies three possible branches: Branch Reviewed records confirmed_fit: all branch gates pass unknown or contradicted confirmed_non_fit Pump OEM design-in 28 12 9 7 End-user predictive maintenance 34 10 14 10 Integrator retrofit projects 18 7 5 6 Total branch records 80 29 28 23 The confirmed-fit shares are 12 / 28 = 42.9%, 10 / 34 = 29.4%, and 7 / 18 = 38.9%. These denominators are branch records, not markets. The 29 confirmed-fit branch records are not predicted leads or customers. All four overlapping operating units have one end-user branch record and one integrator branch record, and all eight of those branch records pass their respective gate sets. The starting reconciliation is 80 branch records - 4 duplicated operating-unit appearances = 76 unique operating units. Because the same four operating units are duplicated inside the confirmed-fit set, deduplication gives 29 confirmed-fit branch records - 4 duplicate operating-unit appearances = 25 unique confirmed-fit operating units. The team preserves both branch records for buying-path coordination but reports both counts. The OEM branch becomes primary because the same design function, documentation set, and lifecycle support model recur across the 12 passing records. The integrator branch receives a seven-account bounded test tied to named projects. The end-user branch remains in verification until local service cost and installed-alternative evidence are resolved. This is a focus decision, not a forecast that OEMs will respond or buy.

9. Common mistakes

• Building one ICP per industry code without testing the buying system.

• Keeping incompatible OEM, distributor, end-user, and project motions in one profile.

• Copying product claims and allowing them to drift by branch.

• Counting applications, sites, and parents as if they were the same unit.

• Launching every plausible branch at once.

• Using engagement as proof that a branch fits.

• Treating an unknown dependency as an average score.

• Splitting only by contact title and duplicating outreach to the same account.

10. What this does not mean

Multiple ICPs do not mean multiple products, separate brands, or unrelated sales teams. They are controlled hypotheses about distinct account and buying systems. One branch can contain several messages, and one product can retain a single technical source of truth. The method does not prove market size, intent, response, opportunity, or revenue. It does not authorize simultaneous contact with overlapping records, and it does not resolve contract, channel, warranty, or product-compliance obligations. Those require explicit operational review.

11. Common questions

How many ICPs should one product have? There is no universal number. Use the fewest branches that preserve materially different applications, relationships, gates, and buying paths. If the team cannot govern and test a branch, it is not yet an operational ICP. Is geography a reason to create a new ICP? Only when it changes material conditions such as application, regulation, channel structure, serviceability, procurement, or evidence rules. Translation alone is usually not enough. Can one account belong to multiple ICPs? Yes, if distinct locations, applications, relationships, or buying motions are evidenced. Store separate branch records and coordinate them through one account graph. Should secondary ICPs receive outreach? Only under a bounded plan with ownership, exclusions, and a learning objective. “Secondary” is not permission for an uncoordinated broad campaign. When should two branches be merged? Merge when the application, relationship, hard gates, buying path, and fulfillment obligations no longer create materially different decisions.

12. Sources and methodology

The split tests, branch map, overlap rule, states, worksheet, and prioritization method are SellersGPT editorial tools. Official sources provide industry, interindustry, company-disclosure, and procurement context only; none is treated as automatic fit or intent. 1 ICP03-BEA-IO - U.S. Bureau of Economic Analysis, “Input-Output Accounts Data.” https://www.bea.gov/data/industries/input-output-accounts-data Accessed August 24, 2026. 2 ICP03-CENSUS-NAICS - U.S. Census Bureau, “North American Industry Classification System.” https://www.census.gov/naics/ Accessed August 24, 2026. 3 ICP03-SEC-EDGAR - U.S. Securities and Exchange Commission, “Search Filings.” https://www.sec.gov/search-filings Accessed August 24, 2026. 4 ICP03-SAM-OPPORTUNITIES - SAM.gov, “Contract Opportunities.” https://sam.gov/opportunities Accessed August 24, 2026.

Sources and Methodology

  1. bea.gov: One Product, Multiple ICPs(2026-09-09, accessed 2026-09-09)
  2. census.gov: One Product, Multiple ICPs(2026-09-09, accessed 2026-09-09)
  3. sec.gov: One Product, Multiple ICPs(2026-09-09, accessed 2026-09-09)
  4. sam.gov: One Product, Multiple ICPs(2026-09-09, accessed 2026-09-09)

Methodology

This article separates cited official or first-party facts from SellersGPT calculations, examples, frameworks, and recommendations. Source links and scope are retained from the publication pack.

Limitations

This material supports planning and decision-making. It is not legal, financial, regulatory, or performance advice, and it does not guarantee leads, meetings, customers, revenue, or return on investment.

Ready to Build Your B2B Sales Pipeline?

Explore SellersGPT

Research your market, compare GTM approaches, and learn how qualified B2B pipeline is built.