The first brand gets a platform. The second brand finds out what kind.
If the first was built as a set of reports, the second is a rebuild. If it was built as shared dimensions with tested feeds underneath, the second is new rows, new feeds, and a few new fact tables.
What one small pharma found
A small pharma we run commercial data for, with one rare-disease brand on the market, had fewer than a hundred patients on therapy and a second indication in phase III that would take it into the thousands. Its warehouse was about two years old. At most 40% of it could be reused for the new indication.
The first brand had a handful of patients per prescriber, so it ran on no claims data, no IQVIA or Symphony, and no formulary feed. Knowing where each enrolled patient stood today mattered more than a claims universe. A second indication with thousands of patients changes that calculation.
| Approved indication | What the second indication changed | |
|---|---|---|
| Patients on therapy | Fewer than a hundred | Into the thousands |
| Specialty pharmacy | Four files a day: patient status, dispense, inventory, demographics | No change recorded |
| CRM and HCP master | Veeva CRM for field activity, alignment, and goals; Veeva Network for the HCP master | No change recorded |
| Claims and physician reference | Not in scope | Scoped up front for the new indication rather than retrofitted later |
| IQVIA, Symphony, formulary | Not in scope | Not recorded as scoped |
Source: the small pharma case study. The existing feeds stay. The scope grows.
The useful result is what happened next. That team absorbed the second indication’s data work while monthly hours trended down. The reporting load went up and the run cost came down, because generated tests and automation absorbed the new datasets instead of a bigger bench.
Build the first brand so the second reuses it
The structure that makes a second brand cheap is interlinked stars: several fact tables sharing conformed dimensions for physician, payer, product, time, and territory. A second brand reuses every one of those dimensions. It adds products to the product dimension, prescribers to the physician dimension, and new fact tables for whatever feeds the new indication brings.
Two habits keep that true over time. Common pipeline pieces get saved and reused across projects, which is how a new vendor feed becomes a few days of work instead of a project. And logic that more than one person needs moves into the data layer. Celgene’s commercial insights team used that rule: if multiple people use a measure on a regular basis, push it into the data layer instead of rebuilding it in Tableau. Celgene ran hundreds of data sets through one unified star schema, covered by more than 20,000 automated tests. By Rajesh Gill’s account in the webinar, a new star took his team a couple of days to build.
A two-stage FITT architecture helps for a plainer reason. It runs raw to final with no intermediate layers to maintain, so a new feed lands in the raw stage and it gets tests from its first load.
Test the seams the second brand touches
The second brand doesn’t break its own reports first. It breaks the first brand’s, through the dimensions they share.
The product hierarchy is where it happens. Adding a brand means adding NDCs to the product hierarchy and the market basket definitions behind share. An NDC remapped from one market basket to another shifts both group totals, nothing errors, and every trend chart built on those groups is about to look wrong. An Aggregate Balance test against the prior delivery flags both groups the day it happens.
The physician dimension is next. If the new indication brings prescriber specialties your mapping hasn’t seen, unmapped specialties silently bucket into “other” and quietly shrink the target segment. And every new feed should arrive with tests generated from profiling, the same way the first brand’s feeds did, so coverage keeps up with the feed count without anyone hand-writing it.
The cost side of carrying a second product on the first one’s platform is on the in-market cost page. The engineering side comes down to one decision made during the first launch: whether you built reports, or built the dimensions the reports sit on.