Our Customer Led Growth Operating Engine: Insights to Execution

darrin

18 Dec 2025 — 7 min read

Note: This article is a narrative version of an internal deck I assembled to walk through the JTBD / Insight engine with the Token of Trust team in about an hour. I describe how this was done or do one yourself here: How I Used Code + Warp.dev (AI) to Turn a Requirements Doc + Code into a Detailed Slideshow and KB Article in About an Hour.

The goal for this article is to show how the code our Operational Development team owns connects directly to our Jobs To Be Done (JTBDs), Insights, and the 2024 Operating Engine.

It’s also a reference you can come back to after the all‑hands and a place to link the recording and the slide deck.

Why this engine exists

Our operating model says we should:

Start with a clear set of JTBDs (what we’ve explicitly signed up to do for customers).
Continuously collect Insights from real conversations and usage.
Use those Insights to improve our JTBDs, product decisions, and operations.

In practice, a huge amount of that signal lives in:

Sales and onboarding conversations (Avoma / Pipedrive)
Support and success conversations (Freescout / Helpscout)
Internal notes and product feedback (ProductBoard)

The JTBD / Insight engine in the tot-ops repo which is the system that:

Turns noisy, unstructured conversations into a prioritized, JTBD‑aligned backlog of opportunities, risks, and learnings.

That’s what this article explains.

JTBDs and Insights: shared language

Before we talk about code, we need a shared vocabulary.

JTBDs (Jobs To Be Done)

JTBDs are the jobs we’ve explicitly committed to help customers accomplish. They define the edges of what we do and don’t do. They’re cataloged in ProductBoard and grouped into products or product families.

In this context, a JTBD entry typically has:

A product / theme (e.g., “Shopify Integration”, “Compliance and Legal Logic”),
A breadcrumb (where it sits in the hierarchy),
A specific job statement (the “thing” the customer is trying to achieve),
Links and metadata inside ProductBoard.

Insights

An Insight is not just a quote. It’s:

A note from a real conversation (Avoma, Freescout, etc.),
Plus structure (tags, customer metadata like segment, MRR, sentiment, recency),
Plus interpretation (what type of signal it is and which JTBD(s) it supports or challenges).

You can think of an Insight as:

A specific, scored piece of evidence about how well we are or aren’t fulfilling a particular JTBD for a particular customer right now.

The engine’s job is to turn raw notes into these Insights, and to map them back to the JTBDs we’ve already committed to.

End-to-end data flow

At a high level, the data flow looks like this:

Conversations & deals
Avoma calls, Freescout and Helpscout threads, and Pipedrive deals capture what prospects and customers say in their own words.
Notes & prospect sheets
- Conversations become ProductBoard notes with tags, origin, and links back to the original threads.
- Pipedrive deals are reflected into Google Sheets like Prospects and Activity Logs, including an Escalation Type field (e.g. High Prospect).
Engines & observers
- The JTBD/Insight engine runs over ProductBoard notes using observers like:
  - JTBDFinder (maps note → JTBDs),
  - TestimonialDetector, ObjectionDetector, CrossSellDetector, UpSellDetector.
- Pipedrive observers run over filtered Pipedrive deals (e.g. high‑value, recently Closed Won) to create onboarding tasks and track follow‑through.
Scoring & escalation
- Notes and features are scored based on customer value, sentiment, recency, and JTBD.
- EscalationRouter writes structured rows into Google Sheets and, where appropriate, creates Trello cards for specific opportunity types.
Decisions & planning
- Product, Ops, Success, and Sales use:
  - JTBD‑level scores,
  - Lists of objections, testimonials, cross‑sell/upsell opportunities,
  - Pipedrive‑driven “Delight Opportunities” (DOs),
- to choose epics and deliverables that actually move business value.

The rest of the article zooms into the important pieces of this flow.

How Avoma, Freescout & Pipedrive feed the engine

Conversations → ProductBoard notes

When a customer or prospect interacts with us through Avoma (calls), Freescout/Helpscout (support), or other channels, we capture:

The raw text of what they said,
Metadata: who they are, which account, what product or feature they’re touching,
Our own notes and tags.

These are turned into ProductBoard notes, which become the primary input to the JTBD/Insight engine.

Pipedrive → High‑value prospect monitoring

In parallel, we integrate with Pipedrive via:

The Prospects Google Sheet (including Escalation Type, e.g. High Prospect),
The Activity Logs Sheet (deal movements like Closed Won, Active (Paid)),
A scheduled job (fetchWonDealsV2) that:
- Reads Prospects and Activity Logs,
- Filters for High Prospect deals that recently moved into target stages (Closed Won, Active (Paid)),
- Fetches those deals from Pipedrive,
- Runs Pipedrive observers (e.g. trelloWonObserverV2).

Those observers then:

Create onboarding Trello cards with a rich summary and checklists,
Update rows in the Prospects sheet (marking deals as Closed, linking Trello cards, recording timestamps),
Make sure high‑value wins don’t fall through the cracks.

In other words, Pipedrive gives us a structured “who is high value and just converted?” signal that we can combine with conversation‑level Insights from Avoma/Freescout.

What the engine can do today

With the current code and configuration, the engine already gives us a lot of leverage:

Auto‑classify customer conversations
Notes from Avoma/Freescout/ProductBoard are run through detectors that flag:
- Objections,
- Testimonials,
- Cross‑sell opportunities,
- Upsell opportunities,
- JTBD matches.
Track which JTBDs show up most in the field
We can see which JTBDs:
- Are mentioned most often,
- Skew positive vs negative in sentiment,
- Cluster around specific segments or products.
Score opportunities by revenue impact
Note scoring uses:High‑value, recent, negative notes rise to the top as urgent fixes; positive ones can be harvested for testimonials or DRs (Delight Results).
- Customer value (e.g. MRR, active vs inactive),
- Importance (how central the note is),
- Sentiment (VADER scores adjusted),
- Recency (fresh notes get more weight).
Route signals to the right teams automatically
EscalationRouter writes different opportunity types to different places, for example:
- Objections → Trello lanes for Sales/Success to handle,
- Testimonials → Marketing/Success lists,
- JTBD matches / gaps → Sheets that Product can review when prioritizing work.
Connect ProductBoard features to real evidence
Confirmed matches in Sheets are pushed back to ProductBoard so each JTBD/feature can show:
- Which notes support it,
- Which notes contradict or challenge it,
- How strongly those notes are scored.

That’s the concrete “today” value the engine provides to the business.

Where we’re going next

This foundation unlocks several “next step” improvements that align with the Operating Engine:

Segment‑specific JTBD views
For example:
- “Top JTBD gaps for high‑MRR cannabis retailers,”
- “Most common objections for PLG Shopify merchants.”
Automated weekly reports
Lightweight, recurring views like:
- “Top 5 JTBDs mentioned this week and their sentiment trend,”
- “New high‑value objections by product.”
Cross‑system correlation
Link signals across the lifecycle:
- Avoma (pre‑sale) → Freescout (post‑sale) → Churn or expansion outcomes,
- So we can see which JTBD breakdowns actually lead to lost deals or lost accounts.
Tighter ProductBoard integration
As scoring stabilizes, we can:
- Auto‑update JTBD impact scores based on new validated Insights,
- Queue proposed JTBDs (with evidence attached) for Product to review,
- Use the Related JTBDs field on epics and deliverables to enforce better linkage from work back to customer reality.

These are deliberately incremental: we can roll them out one at a time without rewriting the system.

Role-specific notes and common questions

The engine touches multiple disciplines. Here are some of the key questions that came up from each role and how this work answers them.

For Scrum Masters

What business outcomes should this move?
Three big ones:

Better JTBD‑based prioritization (we’re working on the right things),
Faster visibility/response to recurring objections and issues,
Stronger linkage between customer conversations and ProductBoard.

How does this map into epics and deliverables?
This engine is the inspiration for the Related JTBDs field:

Each epic/deliverable should declare one or more related JTBDs.
Insights give us real evidence that a given JTBD is hot, painful, or driving testimonials.
That creates stronger accountability that we’re choosing work that moves value, not just clearing tickets.

What does “Done” look like for changes to this engine?
A change is done when:

Code + tests are merged,
Dry‑runs pass on representative data,
Golden‑set outputs haven’t regressed,
It’s deployed to the relevant operational job,
That job’s status is monitored (on the Ops Status Board) and failures produce a Trello card on the Ops board.

For QA

What behaviours must never break?

Notes must be fetched correctly (no corruption/duplication),
The same input should classify and score consistently,
Confirmed matches in Sheets must update ProductBoard correctly,
Misconfiguration should at worst create noisy/missing rows in Sheets/Trello, not damage JTBD definitions.

How do we test around external APIs and LLMs?

Use stubs/mocks for ProductBoard, Google Sheets, and OpenAI in most unit tests,
Reserve sandbox environments and a small test dataset for end‑to‑end tests,
When LLMs are involved, assert on structure and behaviour, not exact wording (e.g. “we went down the suggestion path and got a score above threshold”).

For Ops Dev

Where should I start in the code if I want to understand this engine?

src/node/matchInsights.js – CLI entry point for matching notes to JTBDs,
src/node/modules/productBoard/jtbdMatcher.js – matching + scoring,
src/modules/observers/jbtd/run-notes-engine-v2.js – orchestrates note fetching and JTBD observers,
src/core/EscalationRouter.js – writes to Google Sheets and Trello.

How do Avoma, Freescout, and Pipedrive show up technically?

Avoma/Freescout/Helpscout → ProductBoard notes with tags/origin,
Pipedrive deals → synced into Prospects / Activity Logs Sheets and then into observers that create onboarding cards and update those Sheets.

How do we add new detectors or new sources safely?

New conversational sources should first write good ProductBoard notes or rows in the relevant Sheets.
New detectors should be added as Observers (modeled on existing ones), wired via config, and covered by fixtures and integration tests before being allowed to escalate into production Sheets/Trello.

Closing thoughts

The JTBD / Insight engine is not just a reporting tool. It’s the connective tissue between our daily conversations, our JTBD commitments, and the work we choose to do next.

As we improve its scoring and coverage, it will increasingly:

Answer “What should we work on next?” with data,
Keep us honest about which JTBDs we’re really serving well or poorly,
Support the “Related JTBDs” field on epics and deliverables with real evidence.

This article should give you enough context to read the deck, watch the recording, and see where your role fits into that larger picture.