there can't be product growth without ecosystem growth.

Filed under: The join is the product · Customer journey mapping · Portfolio-scale growth

The first growthstack post was about the growth engine built for one product — a joined intelligence dashboard, a scoring algorithm, an outreach loop, and a signal channel back into the product. It worked. It also exposed the limit of thinking about growth one product at a time.

A single-product engine, however sharp, is answering the wrong question the moment a customer's actual behavior spans more than one product — which, on a platform, is almost always true. A senior leader accountable for the entire data integration portfolio asked the obvious next question:

Can this cover everything the portfolio owns, not just one piece of it?

The answer took a few months. This is what got built — and the harder lesson underneath it: there's no such thing as growing one product in isolation. Either the customer's entire stack and ecosystem gets analyzed, or the view is a slice pretending to be the whole picture.

The scope problem

The first engine was aimed at a single product. Its data model, its scoring, its outreach loop — all shaped around one wedge. Scaling that pattern to a whole portfolio isn't a bigger version of the same job. It's a different job, because the customer stops experiencing your products as a set of independent surfaces and starts experiencing them as a journey through a data platform. The moment you're looking at the portfolio, the unit of analysis has to become the customer, not the product.

Optimize one product's funnel in isolation and the ceiling isn't the product's own flaws — it's everything upstream and downstream of it that a single-product view can't see. That reframe is the entire post.

Why the obvious version doesn't work

The obvious way to build a portfolio-scale customer dashboard is to stack each product's telemetry side by side, throw a product filter on top, and ship it. "Here are your Mirroring numbers. Here are your Copy Job numbers. Here are your Dataflow numbers. Here's Data Pipelines. Here's Airflow. Filter by product."

This produces a dashboard nobody uses.

Customers don't experience data integration as a menu of products. They experience it as a journey: their data starts somewhere, gets pulled into the platform, lands in a workspace, gets transformed, gets orchestrated on a schedule, and shows up in a downstream artifact that a human or a model actually consumes. Every product in the portfolio touches a stage of that journey. Product-scoped tabs make sense to the PM. Journey-scoped views make sense to CSAs, sellers, leaders, and the customer's own architects.

If the portfolio view is going to be operational — actually used, not shelved — it has to be organized around the customer rather than the org chart.

Let's take some of my work on Microsoft Fabric's Data Integration Team for example.

The 6-stage journey

The dashboard is built around six stages of the customer's data journey, in order:

1. Sources — where the customer's data starts. External databases, SaaS systems, on-prem systems, files.
2. Ingestion — how it gets into the platform. Mirroring, Copy Job, Pipeline Copy, connectors.
3. Workspaces — where it lands. Which workspaces, at what grain, with what activity level and what team behind them.
4. Transformation — how it gets shaped. Dataflows, dbt in Fabric, notebooks.
5. Orchestration — how it stays fresh. Data Pipelines, Apache Airflow, scheduled refresh.
6. Downstream — what actually consumes it. Reports, semantic models, warehouses, ML workloads.

Every product in the portfolio slots into one of these six stages. Every customer's journey is a path through the stages, with strong sections, weak sections, and — critically — gaps.

The gaps are the growth surface. Every stage a customer runs on a competitor or a manual process is a stage the portfolio has a product for. A "sources heavy, ingestion weak" account is a mirroring conversation waiting to happen. "Ingestion strong, transformation manual" is a dataflow conversation. A full journey with a weak downstream is a warehouse expansion. The dashboard makes the shape of the opportunity visible for every account at a glance, in the same view.

The joined data underneath

The portfolio scale forced the join to grow, but the pattern held. The dashboard stitches together:

Adjacent-platform connector telemetry — the same upstream-connector data that anchored the mirroring engine, now doing double duty as the "where does the customer's data actually start" layer.

Multi-product usage telemetry — Mirroring, Copy Job, Pipeline Copy, Dataflow Gen2, dbt in Fabric, Data Pipelines, Apache Airflow. Seven measurement models, one joined customer view.

Downstream consumption telemetry — where the data lands once it's in the platform, in what workload mix.

Workspace-grain activity — the "which teams inside the customer are actually building on us" layer. Without workspace grain, every customer looks like a monolith. With it, adoption reads as real or vestigial.

Account ownership and coverage — the same CSA/TAM verification layer as the mirroring engine, now scoped to the largest enterprise accounts across the portfolio.

Customer-reported issues and interview history — the CAT layer, joined across every product in the portfolio, so a friction point raised six months ago shows up on the exact journey stage it's really about.

Falloff detection — customers whose activity dropped month over month, surfaced as their own cohort on top of the ranked view.

The refresh pipeline walks sixteen ordered steps to assemble it all, each with wall-clock timeouts and exponential backoff. Any step can be resumed independently. Every section carries a provenance timestamp. Sections that fail to refresh visibly age instead of quietly overwriting with stale data. Provenance earns its keep — the lesson ports.

The two views on top

The joined data supports two operational modes:

The ranked customer view. Every account, ordered by opportunity, filterable by area, expandable into the 6-stage journey with per-stage CSA/TAM context and friction signals. This is the view a CSA opens to plan a customer conversation. It's also the view that opens before every whiteglove architectural engagement.

The exec visuals. The adoption funnel from source to downstream. The scatter of customer size against journey completeness. The workload mix showing which stages are most-lit across the portfolio. This is the view a leader opens to answer "how is the portfolio doing" without drilling into named accounts.

Both views run off the same joined data. Both refresh automatically. Neither is a static export.

Auto-generated plays

The most useful layer above the 6-stage journey is what this system calls plays — one-line, rule-based recommendations for each customer that read directly off the shape of their journey. "Heavy sources, weak ingestion — Mirroring candidate." "Strong ingestion, weak transformation — Dataflow Gen2 candidate." "Full journey lit, thin downstream — Fabric warehouse expansion." "Journey lit, activity fell off last month — retention check."

These aren't AI-magic. They're rules over the joined data. But because the joined data exists, refreshes daily, and is trustworthy, the plays land in front of the right CSA on the same morning the signal fires. A recommendation nobody has to compute is a recommendation that actually gets acted on. That single principle is doing more work in this dashboard than any individual data model.

Why the customer-facing muscle is the point

The dashboard is not the deliverable. The deliverable is what happens in front of a customer because the dashboard exists.

Before it existed, walking into a whiteglove architectural engagement with a major enterprise account meant hours of prep — pulling six different reports, opening interview notes in OneNote, guessing at where the customer's real friction lived. Now every one of those conversations opens with the customer's own journey lit up on a single card: which stages are strong, what friction the customer already raised, which stage of their journey a competitor currently owns — all of it known before sitting down. The conversation starts from "I already know your estate" instead of "tell me about your architecture."

That difference is the entire commercial argument for the joined view. The dashboard's job is to make every customer-facing hour count more. Every architect walkthrough, every CSA sync, every leadership review — they all get faster and sharper because the shape of the customer is already in the room.

What building this at portfolio scale taught

Three things stood out.

One: the pattern generalizes. The construction from the single-product engine — joined data model, provenance discipline, ranked customer view, auto-generated plays — held up on a portfolio that's an order of magnitude wider. The pipeline is longer. The join is denser. The pattern is the same. The small version was never a throwaway — it was the prototype for the larger one.

Two: journey framing beats product framing every time. The moment the dashboard was reorganized around the customer's data journey instead of the org's product taxonomy, every conversation about it got faster. Leaders stopped asking "what do the numbers mean." They started asking "who's in stage 4 without us."

Three: the Customer Analytics layer scales up, not down. Joining customer-reported issues against seven products instead of one made the friction map denser, not sparser. A customer complaining about orchestration in an interview six months ago now surfaces on the orchestration stage of their journey. That signal was previously trapped in a notes page nobody had time to open.

Where this goes next

Two things are queued.

The first is a churn-risk score layered on top of the falloff cohort — turning journey shape into a retention signal, not just an acquisition one. A customer whose downstream stage went cold two weeks after activation is a different kind of risk than one whose ingestion stage is atrophying because their team reorganized. Both are risks. Neither is currently detected fast enough.

The second is a product-team routing layer. Every play generated by the dashboard should land in the queue of the PM whose surface it recommends. A "Mirroring candidate" play should show up in the mirroring PM's Monday queue. A "Dataflow candidate" play should show up in the dataflow PM's queue. The portfolio-scale engine should feed every individual PM's outreach engine, not sit above them like a poster.

No product on this platform grows in isolation. Every product is a stage in someone's journey through every other product. Miss the ecosystem view and the growth motion is optimizing a room while the house is what the customer's actually walking through.

That's the point of a stack. Each layer feeds the next.

Next growthstack post: the operating system built for the connectivity substrate under Power BI, Excel, and Fabric — and why an internal dashboard is a growth asset if you build it right.

— growthstack