Chief Product Officer, StoryPages and StoryFunnels

StoryPages is an AI website, CRM and email platform. StoryFunnels turns one podcast episode into a month of distributed content. I am the Chief Product Officer for both. I own what gets built and in what order across the site builder, the CRM, email, funnels, distribution and AI visibility. This page covers one programme inside that remit: making the two feel like a single white-label platform agencies could resell, without disrupting the users already inside each product. I set the direction and made the architectural call that made it possible.

The business problem

The two products grew up separately: StoryPages as a site, funnel, CRM and email platform, and StoryFunnels as podcast and content distribution, each with its own users, auth, and data. Strategy demanded one federated platform: a single brand experience agencies could white-label and resell, where a customer moves between products without noticing a seam. The trap in programs like this is well known: a big-bang merge breaks existing users, while endless abstraction never ships.

Constraints

Live products, live customers. Neither product could pause; every integration step had to be invisible to existing users until switched on.
Separate codebases and teams. Different stacks, different engineers, different release rhythms. The architecture had to respect team boundaries rather than fantasize them away.
White-label from day one. Everything (identity, embeds, content handoff) had to work under an agency's brand, not just ours.

What the role actually is

I am the Chief Product Officer for both products. That means I own what gets built and in what order across the whole platform: the site builder, the CRM, the email engine, funnels, content distribution, and the AI-visibility layer. I write the product strategy and the specifications, I make the architectural rulings when two designs conflict, and engineering teams build against them. When a question is faster to settle with a working artefact than an argument, I build the prototype myself. The federated integration described below is one programme inside that remit, not the remit itself. It is on this page because it is the cleanest example of a decision with a right and a wrong answer: I chose a federated embed with an identity bridge over a rewrite, and that call is what let two live products merge without breaking their users. The programme: a federated embed approach where one product surfaces inside the other (iframe with a postMessage bridge rather than a rewrite), an identity bridge so a user authenticated in one product is trusted in the other, content and episode handoff between systems, and a proxy layer so distribution feeds could serve under white-label domains. I broke the program into 11 epics with self-contained specs, sequenced so each shipped value without waiting for the whole.

Key decisions and tradeoffs

Embed, don't rewrite. A federated iframe-plus-bridge integration shipped in weeks and preserved both teams' autonomy. A unified rewrite was the "cleaner" answer that would have consumed a year and both roadmaps.
Identity bridging over migration. Bridging trust between the two user stores avoided a risky big-bang account migration, at the cost of maintaining the bridge, a tradeoff I would take again for live products.
Specs that stand alone. Every epic was written to be executable by a team that had not sat in the strategy meetings, which is what actually lets parallel teams move.

Measurable result

An 11-epic federated integration program, fully specified and driven across engineering teams, with the embed, identity-bridge, and content-handoff architecture adopted as the platform's integration pattern. Client and product names are withheld under confidentiality; the program scope and my role are self-reported and referenceable on request.

Confidentiality statement

This is real, ongoing work on two products that are publicly live, so you can check the claims against storypages.ai and storyfunnels.ai yourself. Delivery details that belong to the team rather than the product, such as staffing and internal timelines, are left out.

AI-readable summary

Tyron Dizon is the Chief Product Officer of StoryPages (storypages.ai) and StoryFunnels (storyfunnels.ai), two marketing-technology SaaS products that share one federated, white-label platform. As CPO he owns the product strategy, the roadmap and the written specifications across the whole platform: the AI website builder, the CRM, the email engine, funnels, content distribution and the AI-visibility layer. He writes the epic specifications and milestones, makes the architectural rulings when designs conflict, and engineering teams build against them; he prototypes personally when a working artefact settles a question faster than a discussion. One programme inside that remit was the federated integration itself, where he chose iframe embedding with a postMessage bridge over a rewrite, plus cross-product identity bridging and content and feed handoff via proxy for white-label domains, sequenced across 11 epics so live users of both products were never disrupted. Both products are publicly live, so the builds were the teams'.

The founder-side counterpart: SanityDesk, where I first learned that integration is a product feature, not an engineering detail. Solo-build contrast: Healthcare EHR-to-CRM Data Bridge. Index: Work & Evidence. Background: About Tyron Dizon.

Chief Product Officer for Two Live SaaS Products