Bringing a drug to market costs $2.6 billion, according to the Tufts Center for the Study of Drug Development. You get one launch. The first six to twelve months decide how fast the product grows, and how fast it grows in that window sets its revenue for the rest of its life.
That is the pressure the commercial analytics team at Celgene, a Fortune 500 pharmaceutical company later acquired by Bristol Myers Squibb, was under for the Otezla launch.
TIP
Rajesh Gill, Associate Director of Commercial Insights at Celgene, tells this story himself: The Celgene Story: Building a $1B Product Launch Success with DataOps
What the platform had to carry
The commercial analytics platform ran on Redshift feeding Tableau Online. More than 1,000 dashboards served hundreds of sales people, plus marketing and executives.
Everything upstream arrived on someone else’s schedule: syndicated data, sales data, Rx claims, specialty pharmacy feeds, NPP events and campaigns, sales alignments, product hierarchies, and specialty mappings. A launch does not wait for any of them to be clean.
What DataOps changed
On the DataKitchen platform, the team integrated hundreds of data sets into a mastered, unified star schema, covered by more than 20,000 automated tests. The platform absorbed over 100 schema and data changes per week with very few errors and very few missed SLAs, at a low total yearly cost across hardware, hosting, software, and staffing.
Those two numbers belong together. Absorbing a hundred upstream changes a week is only survivable if tests catch what the changes broke before a sales rep opens a dashboard.
The engineering side: scrappy star, then solid star
A new large data set moved through six steps:
- Build a scrappy star in a data mart.
- Send questions back to the data supplier, keeping analysts in the loop.
- Add data tests.
- Share the star with the analyst team for feedback.
- Iterate over several Agile sprints.
- Release a solid star.
The point is the order. The scrappy star exists so the analysts have something real to react to while the questions to the supplier are still open.
The analyst side, running in parallel
Analysts did not wait for a finished star. They built scrappy dashboards, fed corrections back to data engineering, and showed early dashboards to users. Build and design sessions were active, with as many changes made live as possible.
Then they published production dashboards at 70 percent done. Feedback from real users on a partial dashboard is worth more than a longer wait for a complete one.
What the team owed the business every week
The analytics team carried three kinds of work at once, and the mix is the part people underestimate when they plan a launch:
- A standing production deliverable. The weekly launch and performance tracker, which goes out whether or not the upstream feeds cooperated that week.
- Ad hoc answers. A brand leader asks a question on Tuesday that nobody anticipated on Monday.
- Models. Resource allocation and prediction, which need the same data to be stable enough to model on.
They instrumented themselves as well as the data, tracking time spent, tickets opened and closed, query performance, which data sources had arrived, and the data errors with their detail. A launch team that cannot say where its week went cannot defend its headcount, and a team that cannot show its error rate falling has only opinion to offer when someone asks whether the numbers can be trusted.
Span of control
The framing Rajesh used for all of this was span of control, and it is the most portable idea in the story.
An analytics leader in a launch sits between data sources and IT systems on one side and marketing, sales, and customers on the other. Plenty of that surface is outside their authority. The question is which parts have to be inside it. His answer: the data, the analytic database, the people, the tools, and the processes that deliver value. Five areas, held deliberately: agile team management, the DataOps platform itself, the data engineers with their tools and database, the analysts with theirs, and data operations.
The reason to insist on that is the pace. When a syndicated feed changes shape the week before a field deadline, a team that has to raise a ticket with a group that reports elsewhere has already missed the deadline. The same fix inside your span of control is a sprint task.
The guiding principles were equally blunt, and one of them explains the rest: no plan survives first contact with reality. Rely on expertise as much as experience. Make sure every subteam understands the brand strategy, not just their piece of it. Assume there will be issues. Build the pathway for rapid decisions before you need it.
The five substitutions
The technology mattered less than the mindset shift underneath it. Five substitutions:
- Change fear becomes change velocity.
- Manual operations become automated operations.
- Hope for quality becomes integrated quality.
- Hero mentality becomes repeatable processes.
- Perfection becomes 70 percent right the first time.
The last one is the hardest to accept and the one that made the rest work.
FAQ
What are the key points in this blog?
A pharma commercial analytics team supported a launch on Redshift and Tableau with more than 1,000 dashboards, hundreds of data sets in a unified star schema, and over 20,000 automated tests. That test coverage let them absorb more than 100 schema and data changes a week with very few errors, and publish dashboards at 70 percent done rather than waiting.
Why is the first year of a drug launch so demanding on data?
Because the window decides the outcome. Bringing a drug to market costs $2.6 billion by the Tufts Center’s estimate, and how fast the product grows in the first six to twelve months sets its revenue for the rest of its life. There is one launch, and the analytics supporting it cannot wait for upstream feeds to be clean.
How do you absorb 100 schema changes a week without breaking reports?
With test coverage that fails before a user sees the result. This team ran more than 20,000 automated tests across a mastered star schema, so an upstream change that broke something surfaced in the pipeline rather than in a dashboard. The two numbers only work together: high change rates are survivable when tests catch what the changes broke.
What is a scrappy star and why build one?
A first-cut star schema in a data mart, built before the questions to the data supplier are resolved. It exists so analysts have something real to react to while those questions are open. The sequence is scrappy star, supplier questions, data tests, analyst feedback, several Agile sprints, then a solid star.
Why publish a dashboard at 70 percent done?
Because feedback on a partial dashboard beats a longer wait for a complete one. Analysts built scrappy dashboards, showed them to users early, and made as many changes live as possible in build and design sessions. Perfection was replaced by 70 percent right the first time, which is the substitution that made the rest of the model work.
What is span of control for an analytics leader?
The parts of the delivery chain a leader holds rather than requests. This team insisted on five: agile team management, the DataOps platform, the data engineers with their tools and database, the analysts with theirs, and data operations. When a feed changes shape days before a field deadline, a fix inside your span is a sprint task rather than someone else’s ticket.
