Most digital health companies have installed a product analytics tool but have almost no usable growth data behind it – PHI constraints, disconnected apps, and manual instrumentation mean each growth idea becomes an engineering ticket before it becomes a test. Growth engineering creates the tracking, flagging, and pipeline infrastructure a growth team needs to move. We build it from within your engineering org, not as a bolt-on tool that nobody maintains.
The Challenge
Event tracking exists only in name, and no one trusts the numbers enough to act on them
Digital health products typically span a patient app, a provider portal, and sometimes a separate clinician workflow tool, each instrumented at a different time by a different engineer with no shared taxonomy. PHI handling rules mean events get scrubbed inconsistently – some de-identified correctly, some dropped entirely, some leaking fields they shouldn't. When the VP Marketing asks how many patients completed onboarding last month, three dashboards give three different answers. Growth decisions built on data nobody trusts get second-guessed into inaction.
Every change rolls out to 100% of patients at once because feature-flagging infrastructure doesn't exist
In consumer SaaS, a broken flag rollout costs you a support ticket. In digital health, a change that reaches every patient simultaneously – a new onboarding flow, a changed medication reminder, a new consent screen – is a clinical-trust and safety exposure, not just a UX bug. Without a flagging system, teams either avoid changing anything (growth stalls) or ship everything to everyone (risk stacks up). Compliance and product end up in permanent conflict because the tooling to de-risk rollout doesn't exist yet.
A single A/B test takes a full engineering sprint, so the team runs almost no tests
Without a real experimentation pipeline – randomized assignment, exposure logging, a way to route variants without a manual code branch – every test idea becomes a bespoke build. Engineering has to hand-roll the split, hand-roll the logging, and hand-roll the analysis, and that work competes directly with the clinical or compliance roadmap for sprint capacity. Digital health companies routinely tell us they run two or three tests a year not because they lack ideas, but because each one costs a sprint they don't have.
Acquisition, product, and clinical outcome data sit in systems that have never communicated with one another
Marketing knows what channel brought a patient in. Product knows what that patient did in the app. Clinical or claims data knows whether the intervention actually worked. In most digital health companies these three sources sit in separate tools with no join key connecting them, so nobody can answer the question that actually matters: which acquisition channels bring patients who engage and improve, versus patients who sign up once and disappear. Growth strategy without that connection is a guess dressed up as a plan.
What We Do
We begin with an instrumentation audit, not a strategy deck. We pull the current event taxonomy from every surface – patient app, provider portal, marketing site – and compare what's really firing with what the team thinks is firing.
Using that audit, we create a tracking plan and event taxonomy built for a regulated product from day one – de-identified by default, consent-aware, and standardized across every app surface so a 'signup' has the same meaning in the patient app and provider portal.
For execution, we establish the feature-flagging and experimentation infrastructure that changes rollout from a binary ship/don't-ship choice into a controlled process – percentage rollouts, targeted cohorts, and a kill switch that requires no hotfix deploy. On top of that, we build the experimentation pipeline: randomized assignment, exposure logging, and a direct feed into whichever statistical approach the team uses to call a test.
For the more difficult challenge – joining acquisition, product, and outcomes data – we create the join layer: a growth data warehouse or reverse-ETL setup (based on what you already run) that connects channel-level acquisition data with in-product behavior and, when available, outcome or retention signals. That makes it possible to identify which channels attract patients who genuinely engage, rather than only patients who convert once.
Throughout the engagement, we embed with your engineering team instead of delivering a spec and vanishing. We pair during the build, document the architecture, and run the first few experiments through the new pipeline together, making the handoff a functioning system rather than a README no one reads.
What separates this from a marketing agency managing your <a href="/services/measurement/">measurement</a> stack is that we build infrastructure your engineers work with daily, not a marketing reporting dashboard. The work supports your broader <a href="/services/strategy/">growth strategy</a>, but it resides in your codebase and data warehouse, owned by your team well after the engagement is over.
What we deliver
- PHI-safe event taxonomy and tracking plan, consistent across patient app, provider portal, and marketing site
- Feature-flagging architecture with percentage rollouts, cohort targeting, and a rollback path that doesn't require a deploy
- Experimentation pipeline – randomized assignment, exposure logging, and a direct feed into your stats process
- Growth data warehouse or reverse-ETL layer joining acquisition, product, and outcome data on a shared key
- Architecture documentation and a run-through of the first live experiments with your engineering team
A growth team saying 'we don't have enough data to decide' almost never has a data issue – it has an infrastructure issue. In digital health, that infrastructure must be PHI-safe from the outset, because adding compliance to a tracking system afterward is slower and riskier than building it correctly the first time.
Our Methodology
We deliver growth engineering as a 90-day build sprint. Days 1 through 30 focus on the audit: comparing the actual event taxonomy with what's believed to exist, reviewing how current tracking handles PHI and consent, and finding the one or two infrastructure gaps currently blocking growth decisions. Days 30 through 60 cover the build: implementing the tracking plan, feature-flag infrastructure, and experimentation pipeline inside your existing stack, with your engineers pairing alongside us. Days 60 through 90 provide proof: together, we run the first flagged rollout and first pipeline-driven experiment end to end, then hand over working infrastructure with documentation your team can use without us.
Unlike a typical analytics or dev-tooling vendor, we don't sell a tool and disappear – we construct the specific pipeline required by your product and compliance posture, then stay embedded until your engineers are operating it themselves. Digital health infrastructure must address PHI handling and clinical-safety rollout risk in ways generic growth tooling does not, so generic playbooks cannot transfer without applying real engineering judgment to your particular product and patient population.
Our Process
The initial 30 days are diagnostic. We examine your current tracking, flagging (if any), and data infrastructure, then return with a concrete list of gaps ranked by what is truly blocking growth work versus what would simply be nice to have. You receive a candid assessment of how much of your 'we can't test that' issue is infrastructural rather than organizational.
Days 30 through 60 focus on building. We operate within your codebase and data stack – not in a parallel system – and pair directly with your engineers on tracking implementation, feature-flag configuration, and the experimentation pipeline. On your side, we require allocated engineering time (this project does not run entirely on our end), access to your existing analytics and data warehouse tools, and a product or engineering point person who owns the handoff.
During days 60 through 90, we demonstrate that the system works by putting real experiments through it – a flagged rollout, a tracked test, and a warehouse query joining acquisition data with product behavior for the first time. We evaluate whether the infrastructure performs in actual use, rather than only in a demo.
We hold a weekly working session with growth and engineering stakeholders, supported by async documentation throughout the build. Most engagements complete the full 90-day build before moving to a lighter advisory cadence, although some clients keep us embedded longer while scaling the pipeline to additional product surfaces.
- Trustworthy event data across every product surface
- Safer, faster feature rollouts via flagging instead of all-or-nothing ships
- Higher experiment velocity because tests no longer require a bespoke build
- Acquisition-to-outcome visibility that informs channel and budget decisions
If your digital health company needs growth engineering leadership, we should talk.
Expand your marketing team output with our experts
Let us take a custom approach to your growth goals by assembling and leading the best-in-class marketing team to support your next stage.
Frequently asked questions
What does a growth engineering engagement cost for a digital health company?
Pricing is based on the scope of the build – an engagement limited to a tracking plan is priced differently from a complete build covering tracking, flagging, and a data warehouse join layer. Most 90-day growth engineering sprints for businesses in the $5M-$100M ARR range cost $25K-$60K, depending on the number of product surfaces requiring instrumentation and how fragmented the current data stack is.
How soon will we see results from a growth engineering build?
Reliable tracking data is generally the first noticeable win, often arriving within the first 30-45 days after the audit is complete and the new taxonomy goes live. Feature-flagging infrastructure and the initial flagged rollout usually arrive by day 60.
How does your growth engineering team collaborate with our current engineers?
We pair with your engineering team directly instead of working separately and delivering a spec afterward. Your engineers participate in architecture decisions, while the code resides in your repo and follows your conventions rather than living in a separate system under our control.
What differentiates Winston Francois from an analytics vendor or marketing agency?
A marketing agency creates a reporting dashboard using whatever data is already available. An analytics vendor provides a tool and puts implementation in your team's hands.
How is ROI measured for a growth engineering engagement?
We first measure ROI through infrastructure – data trustworthiness (do figures reconcile between sources), rollout safety (the percentage of changes released behind a flag rather than all at once), and experiment velocity (tests completed per quarter before and after). Downstream, the result is faster, more informed growth decisions and less time between a hypothesis and a tested result, which we compare with the baseline established during the initial audit.
What kind of digital health company is best suited to this service?
This service suits companies around the $5M-$100M ARR range with an existing product engineering team but no dedicated growth engineering function – their growth or marketing team has ideas that repeatedly stall at 'we'd need an engineer for that.' It is not a good fit for pre-product-market-fit companies that are still validating the core product, because investing in infrastructure before knowing what to optimize is premature. We start with a strategy call and a walkthrough of your existing tracking and data stack.
