The SaaS bowtie, from Winning by Design, draws the customer journey as two funnels joined at the sale. The left side narrows from awareness to a signed deal. The right side widens again through onboarding, adoption and expansion, because in recurring revenue most of a customer's value arrives after they sign. Teams that adopt it usually find they measure the left side carefully and the right side barely at all.
How it works
Every stage on the bowtie has a conversion rate to the next. On the right side those stages are product behaviour, not sales activity: did the customer onboard, did usage spread beyond the first team, did they expand. Pipeline stages live in the CRM, where a salesperson updates them by hand. Adoption stages live in event data, where nobody updates anything by hand, and a break goes unnoticed until the numbers disagree with billing.
Dave Boyce's Freemium uses a variant he calls the PLG Bowtie, with activation and First Impact placed before payment rather than after it (Ch 3). In a product-led company the right-hand behaviours happen first. The events under them become the foundation for the whole shape instead of an after-sale report.
What it assumes your events already do
| Event | What the framework uses it for | What it reports when the event breaks |
|---|---|---|
Activation or First Impact eventfirst_report_shared | Onboarding: the first stage after the knot. | An onboarding redesign that changes the event makes every new customer look stuck, or makes stuck ones look onboarded. |
Core value actionreport_viewed | Adoption. | Adoption reported from one platform's events misses customers who moved to another. |
Invite sent and acceptedinvite_sent, invite_accepted | Spread inside the account. | Seats added through an admin bulk import never fire the invite event, so spread looks stalled. |
User-to-account joinaccount_id on every event | Ties adoption to the account the CRM and billing know. | Sub-workspaces with their own IDs split one customer into several small ones. |
Plan changeplan_changed | Expansion and renewal. | Expansion bought outside the tracked flow appears in billing and nowhere else. |
Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.
The expansion finance saw first
Illustrative example. The company and the figures are invented to show the mechanism.
A customer success team reports adoption from a usage event per workspace. A product change lets enterprise customers create sub-workspaces, and events from them carry the child ID instead of the parent account. Adoption for the largest customers appears to halve.
Finance, meanwhile, sees those same accounts expanding. For a quarter the two teams bring contradicting bowties to the board, and both are reading their own data correctly.
Checks before you trust it
- Map each right-hand stage to a named event before drawing the bowtie, and mark stages with no event as unmeasured.
- Check that adoption and expansion events roll up to the account ID the CRM uses.
- Compare product-reported expansion with billing every month; a widening gap is a tracking question.
- Give the right side an owner as clear as the sales leader who owns the left.
Check the events under it
Before SaaS bowtie goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.