the growth stack, rebuilt: enabling product growth through ai-powered analytics engine

Filed under: AI in the funnel · Signal-driven outreach · The PM/PMM overlap

Welcome to growthstack.

growthstack starts from one premise: the stack a growth practitioner runs — the tools, joins, models, and loops that turn attention into adoption into retention — is being quietly rebuilt from the studs up by AI. The load-bearing kind. The joins nobody wants to maintain, the customer engagement emails nobody has time to personalize, the reply threads nobody reads all the way through, the product signals that used to die in a spreadsheet — that's the rebuild worth writing about.

This space will track that rebuild as it happens — the funnel, retention, the strange widening seam between product management and product marketing that AI is making impossible to ignore. All of it technical enough to be useful, honest enough to be worth the time.

This is the first one — how growth is now the new requirement for product managers. How I turned growth into a running engine. For real, not for a demo. Built and run solo: no data team, no automation engineer, no agency. One PM and a set of custom AI skills, from scratch.

The premise

The job: own a piece of product surface, own the number attached to it, close the gap between "customers who should be using this" and "customers who actually are."

For most of the last decade, and especially in Big Tech companies, that meant brokering — a request to a data team for a report, to marketing for a campaign, to sales ops for account matching, then hoping the compound latency across five orgs didn't eat the quarter. That model is dead. Or it should be.

What replaced it, built over the last few months: a live scoring engine, a joined customer intelligence dashboard, an automated outreach pipeline, and a signal channel back into the product — custom AI skills, tuned over weeks of use, running on their own schedule. They don't wait around.

This post is the technical version of how it works. Each subsequent post pulls one layer apart in more depth.

The funnel, stated plainly

The product in question has a classic upsell shape:

• A large installed base uses an adjacent surface (the "upstream" product).
• A subset of that base has a usage pattern that would obviously benefit from moving into this surface.
• Once they move, their consumption profile changes in a way that's good for both the customer and the platform.

The growth question is: of the tens of thousands of accounts in the installed base, which few hundred are prime opportunities this week? That's a ranking problem. Reports tell you what happened. Rankings tell you what to do next — and most "growth dashboards" are reports pretending to be rankings.

Layer 1: The intelligence dashboard

Ranking anything first required a joined view of the customer that didn't exist anywhere in the org. Every team held a slice. Nobody held the whole picture.

So I built the join myself. The intelligence dashboard is a single, live artifact that stitches together five different data models — each owned by a different team, shaped for a different purpose — into one customer-shaped view. It refreshes automatically, daily. Every section carries a provenance timestamp, and anything that fails to refresh visibly ages — a quiet signal not to trust it. Not a slide deck, not a static report. A running system.

Here's what it joins:

1. Product usage telemetry. The platform's own consumption model — active users, capacity units consumed, product adoption per account, per workload, per source type. The "what are they doing today" layer. It shows who's using what, at what intensity, on which underlying data sources.

2. Adjacent-surface connector telemetry. How the upstream product is being used at each account — which external database types they're connecting to, how much authoring and downstream consumption flows through each connector. This is the layer that identifies the pattern that matters: accounts already leaning heavily on external database connections that would benefit from being pulled into the platform's native pipeline.

3. This product's own usage telemetry. Adoption telemetry for the surface itself — who's already on it, how much they're syncing, which sources they've turned on, which they haven't. This is what makes the gap dimension of the ranking possible. Without it, outreach would fire at customers who already adopted six months ago.

4. Account ownership and coverage. The CSA/TAM assignment model — which internal owner is accountable for which account, what support agreement they're under, whether that assignment is active. This is the layer that makes outreach routable. Without it, every insight from the first three models dies on the ground because there's no one to tell.

5. Customer-reported issues, use cases, and interview history — the CAT integration. The fifth source — and the sharpest one — is the CAT customer issues model: the curated record of everything customers have actually said — reported problems, use cases they've described, interview transcripts, meeting recaps, the OneNote links back to the raw notes.

Before any outreach goes out, this is the layer that answers what they've already said, to whom, about what. It's the difference between a cold outreach and a warm one: has anyone from the org already talked to them? What did they ask about? What's blocking them? What use case did they describe six months ago that's worth referencing now?

Every draft leans on this layer. Every meeting starts with a scan of it. And — a retention thread worth its own post later — the same layer that de-risks acquisition also de-risks the save. Knowing what a customer already told you is most of the game once they're in the door.

What the joined view uniquely produces

None of these five sources natively join to each other. Each lives in a different team's system, with a different key, a different refresh cadence, a different access pattern. The dashboard resolves them on the primary account identifier, falls back to the tenant identifier when that's missing, and quietly flags any account where the join fails, for a closer look later.

The value isn't any single dimension — it's the combination. Filter to accounts with strong upstream intensity, no adoption of this product yet, an active internal owner, and a specific pain point raised in their last interview, and the list that comes back exists nowhere else in the org. Not with sellers, not with marketing, not with the data team. Only the PM sitting on the telemetry can build that join — so I did, because until then nobody had; the coordination cost across five teams had made it prohibitive for anyone else.

A recurring theme here: the joins that don't get built are almost never technical problems. They're org-chart problems. AI is what finally makes it cheap enough for one person to route around the org chart and build the join anyway.

On top of the joined layer, the dashboard renders three operational tabs:

Ingestion. How much data is flowing through the product, from which source types, into which downstream workloads. Every byte gets tracked from source, through OneLake, into the downstream artifacts that consume it — the whole data journey of every customer, where it starts, how it lands, where it flows once it's in the platform.

Connectivity. How the adjacent product is being used across the installed base — which external database connectors have the largest reach, which are growing fastest, where the largest downstream consumer bases sit. The upstream context that identifies which accounts are worth ranking in the first place.

Opportunities. The scored, tiered, filterable list of prime accounts, cross-referenced against verified owners and prior customer signal. The tab that opens every Monday.

Layer 2: The growth algorithm

Sitting on top of the joined data is the ranking. Every eligible account gets a score, refreshed daily, produced by a weighted composite of four dimensions:

Upstream intensity. How aggressively is this account already using the adjacent surface in the specific pattern that predicts fit? This carries the largest single weight, because behavioral signal beats demographic signal every time. An account with heavy, sustained upstream usage of the exact pattern that matters is far more valuable than an account that "should" fit based on size alone.

Account size — measured as capacity for growth rather than raw revenue. A very small account with perfect upstream intensity isn't a prime opportunity. Neither is a very large account with weak intensity. The score wants both.

Gap. How far is this account from the target state? An account already partially adopted gets less weight here, not more — the marginal opportunity is smaller. The dimension most naive scoring models get backwards.

Proximity to the broader platform. How close is the account to the rest of the ecosystem around the product? An account already deeply integrated into adjacent workloads has a shorter activation path. An account touching only one thin edge has a longer one.

Each dimension is normalized within its cohort so no single feature dominates. The weights are tunable — re-weighted twice already, as new conversion patterns showed up. That's the point of owning the score: it's a hypothesis, and every week of outreach is a test.

Once accounts are scored, they're tiered automatically — top tier (act this week), middle tier (warm, watch), exploratory tier (interesting, log for later). Tier assignment isn't static; accounts move between tiers as signal changes. When a middle-tier account crosses the promotion threshold, the engine promotes it, drafts an outreach, and puts it on the desk Monday morning without being asked.

There's also a source-type filter layered on the opportunity table. Accounts can be prime for different reasons — heavy on one source type versus another — and the outreach angle changes depending on which source is dominant. The filter segments the pipeline by category, so each outreach batch stays coherent instead of scattered. (This is where PM and PMM start to blur — a seam worth its own post later.)

Layer 3: Automated outreach with a human sender

The outreach loop is a separate AI skill that consumes the ranked cohort and produces one personalized draft per account, every Monday. The pipeline:

1. Pull the top-tier cohort from the scoring engine.
2. Look up the verified account owner under strict filters — active support agreement, verified contact record, non-vendor alias. No verified owner, no draft; the account gets skipped and flagged instead. (An early version of mine skipped this check and cost a bad email to the wrong person. The skill now hard-refuses without a verified match. Guardrails first, always.)
3. Pull account context — usage profile, dominant source types, prior interview notes from the CAT layer, prior product signals — from the joined data model.
4. Generate a personalized draft calibrated to what the account actually looks like: themes over numbers, a different opening for each recipient, a specific ask phrased to invite conversation rather than book a pitch meeting.
5. Stop. The skill doesn't send. Drafts land in a mailbox and wait for review.

Every draft gets read by hand. Some get sent as-is, some get edited, some get deleted. The AI carries the volume work — joins, lookups, first-pass copy. The judgment work stays put — tone, edge cases, the call on what actually goes out.

The design choice that matters most: the sender is always a person, from a real mailbox. Automation-sent email reads as automation-sent email in enterprise sales — dead on arrival. The AI-assisted version, sent by a human, lands like any other note from a PM. Worth its own post, and it's coming.

Layer 4: Reply tracking and re-engagement

The pipeline doesn't stop at send. A third skill runs daily against the inbox, scans replies, categorizes them (engaged, routing, silent, declined), and updates a live tracker. Silence past a threshold triggers a re-engagement draft. Engagement triggers a customer 360 pull — the joined view rendered for a single account — so the next conversation starts with the CAT history, the usage profile, and the connectivity picture already in hand.

The tracker isn't maintained by hand — it's a live artifact the engine keeps current on its own.

Layer 5: The loop back into product

This is the part that separates a growth PM from a growth marketer. Reading every reply to every draft the engine sends surfaces patterns fast: the same question across a dozen accounts, the same friction point stalling the same conversation, the same feature request landing from unrelated internal owners in the same week.

That signal is a product backlog written in the customer's own voice — and the shortest path from hearing it to acting on it runs straight through the PM who owns the surface it's about.

The last quarter of engine output: a shipped tutorial addressing the highest drop-off point in the activation funnel, a queue of error-messaging fixes now in the backlog, a working hypothesis about the next capability gap. Every one of those moves came from reading outreach replies, cross-referenced against CAT signals from the same accounts. That's the loop. That's the actual job.

What running this actually taught

A few observations from a few months of operation — the kind of thing growthstack will keep coming back to:

The join is the product. Every individual data source in the dashboard already existed — the value came from joining them. Growth practitioners undervalue joins because they're boring, cross team boundaries, and take a while, but the joined view is where the entire motion becomes possible.

Composite scores beat single-dimension filters, always. The first version was "customers with the highest upstream intensity" — it ranked a handful of very active, very small accounts at the top. Adding account size and gap into the mix produces a very different, much better top ten.

Normalization matters more than weight tuning. A week went into fiddling with weights before the real issue surfaced: the raw features weren't on comparable scales. Normalizing each dimension within its cohort mattered more than any weight change that came after.

Provenance earns its keep. Every number carries a timestamp of when it was last pulled; sections that fail to refresh visibly age. An untrustworthy dashboard is worse than no dashboard at all — it produces confident wrong decisions instead of uncertain slow ones.

Guardrails are the product. Every skill here carries more code in the "refuse to act" branch than in the "act" branch — the engine that refuses to draft against an unverified contact is worth more than the engine that drafts fast.

Automation compounds. Every new skill makes the next one cheaper — the lookup logic in outreach also feeds the customer 360, the tone rules built for one campaign generalize to the next. The judgment part of the loop — what to send, what to change, what to build next — doesn't compound the same way. That's the correct division of labor.

Where the growth stack is going

The growth practitioner job — PM, PMM, whatever the title on the badge — is on the verge of a real reshape: design the joins, own the score, read the replies, ship the product changes. The intermediate work — queries, drafts, trackers, follow-ups, refresh — gets delegated to a set of AI skills, self-authored and self-operated by the same person doing the judgment work.

No data team required to build the funnel. No marketing ops team required to run the outreach. What's required: a scoring hypothesis, a joined data model, an automation pipeline, guardrails that refuse to embarrass anyone, and the discipline to read every reply.

The rest compounds.

— growthstack