I’ve spent 22 years bridging development and growth. Here’s how I’d put that to work at MotherDuck.
Walk through my first move
I rapidly prototyped new products at an industrial design firm for its owner, who later went on to found Boxabl.
I ran community and marketing for massively multiplayer games as social media and YouTube emerged. I drove large alpha, beta and prerelease testing programs, incorporating livestreaming before Twitch was Twitch.
At Small Improvements, I worked across conversion, self-serve onboarding and retention. Growing without a marketing budget meant working on what happened after someone arrived, as well as getting them there.
At US Park Pass, I kept trying to make bidding respond to contribution margin: BeProfit, Triple Whale, Google Sheets, scripts and offline uploads.
In February 2026, I began developing USPP peak-performance with Claude Code. It was an internal tool built on BigQuery and Google Cloud, with LLM analysis. It sent conversion restatements to Google Ads through its API, updating previously reported conversion values with the actual contribution margin value the individual order generated.
At Small Improvements, an HR software company, I was employee nine. I owned inbound sales, onboarding, training and rollout. During my four years there, the company grew from fewer than 100 to 650+ paying customers and from under $1 million to $7 million in annual recurring revenue. Those are company growth figures over my tenure, not results attributable to one person.
I co-founded and ran US Park Pass with a small team, reaching $8 million in annual sales at peak and shipping 500,000+ orders over the life of the business. I built the systems behind the marketing, storefront, fulfillment and shipping, including a 450,000-person email program contributing 25% of revenue.
MotherDuck’s Growth Marketing role brings those threads together: rapid prototyping, self-serve growth, and work that helps Marketing Ops and Sales act on evidence. That’s what excites me. I directed this build with agents helping develop the statistics, SQL and interface. I’m sharpening my experiment-design skills as we go, with the assumptions and evidence open to inspect.
One of my first questions: where would I put the next growth experiment? Start with history, weigh one useful offer, and leave with a test proposal and a next move for every result.
Invented account history, explicit what-if assumptions, and a workflow you can run in MotherDuck. The separate stack demo includes one real Clay enrichment.
I’d start by making more of the demand we already have. Work backward from activation and qualified demand through our website and onboarding email: where do people get stuck, and what help could move them forward? Improving that path can make future external and paid campaigns more productive.
That’s why I’d inspect account and trial history in MotherDuck first. History helps choose where to test; a new experiment tells us whether the change helps. Walk through one onboarding example, change the assumptions, and see what I’d do next.
A synthetic historical sample. The what-if model is a planning exercise, not a measured campaign result.
Opening the historical sample…
An analyst has started querying their own data. Could an onboarding offer tailored to their work help them get further and reveal a useful Sales opportunity?
“You’ve got your data in. Want help turning this into something your team can use?”
Use the existing onboarding email opportunity to offer relevant help. An explicit Sales request gets priority; other eligible trial accounts can still receive a useful invitation.
Product activity gives us a reason to investigate what help might be useful. A stated need makes the offer more specific; the response helps us learn whether a Sales conversation belongs next.
This is the same habit I brought to profit-based bidding: follow the attractive signal through to the outcome that matters.
The replay selects accounts eligible for the existing onboarding email program, with company fit and an own-data query recorded by day 3. Stated needs and evaluation intent guide the offer; a separate Sales opt-in is not required. Qualification is measured afterward.
Inspect the saved historical replayTry an upside assumption, then check two things: is the gain worth pursuing, and can the team handle the review?
Assumed benefit and total review effort across this audience. Passing both checks means worth investigating, not proven to work.
Next, carry your goal and capacity into a test proposal. Agree the smallest worthwhile improvement before calculating how many accounts and how much time the test needs.
Have Jev read the notes and help choose a useful next step: product help, a team-evaluation offer, or a priority Sales response. Then measure whether that preparation saves review time.
Opening the saved Jev review…
These account notes and email-program statuses are invented; the Jev calls are real. A proposed action is still subject to Ops review. Qualification is an outcome to establish later.
This demo uses Jev through Vercel AI Gateway. The reusable MotherDuck template asks the same questions with native prompt_jev() in your own account; that path is prepared, not executed here. Human review-time savings have not been measured.
I’d first review rejected briefs and speak with trial teams. If a useful invitation is the missing step, here’s the test I’d take to Marketing Ops and Sales.
For eligible accounts, compare the current onboarding email with the tailored help offer above. Assign accounts before the offer; keep the same contact opportunities and product help.
More accounts qualified by day 28 of the trial: company fit, a validated team use case and an agreed next step. Use the same review criteria in both groups.
Protect product activation, respect opt-outs, and stay within Sales capacity. Marketing Ops owns email eligibility, targeting and suppression; Sales records acceptance or rejection and why.
This is a proposal. Baseline, minimum worthwhile effect, sample size, enrollment window and stop rules must be agreed before assignment. The old demo’s 4,000 per group does not carry over.
These are future decision paths, not results inferred from the historical sample.
That’s one play. I’d love to talk about the opportunities you’re seeing at MotherDuck.
Leave your name and email, and I’ll get back to you soon. A little context is welcome, too.
Prefer email? james@jamesdnichols.com. Or call or text if easier: (571) 205-8958.
Give Marketing Ops the field map and read-only SQL. Replay the audience against your own history in MotherDuck, then use the returned counts to weigh the play and plan a test.
Your account data stays in your environment. This page does not accept customer-data uploads. Mapping and validation come before a usable result.
A decision only matters once it reaches the people running campaigns and working leads. This is the path a qualifying account would take from task evidence to a Sales review and back to the warehouse. Enrichment adds company facts. It can’t create intent.
SQL picks accounts using only evidence available at the time.
Check audience eligibility, dated evidence and suppression rules.
Add public company facts that are missing.
Accept or reject with a reason; the outcome returns to the warehouse.
What actually ran: one real company enrichment, on a domain I own, with test intent I supplied. A test-queue review agent rejected it because real company fit, a team use case and an agreed next step were missing. No real SQA, no prospect messages, no campaign.
This earlier handoff used supplied fixture intent. The Jev review above is a separate rehearsal with its own statements and saved model calls.
Checking the native integration receipts…
Take this first slice into your MotherDuck account. Use your agent to find the trial audience worth investigating, the gaps worth fixing, and the next test worth running.
Connect the tools below, then copy the history prompt to get started.
Duck Yeah supplies the templates. MotherDuck gives your agent access to your data. If either is already connected, verify its tools before adding it again.
Claude Code: add each missing connection, then open /mcp and authenticate MotherDuck.
claude mcp add --transport http duck-yeah https://jamesdnichols.com/duck-yeah/mcp/ claude mcp add --transport http MotherDuck https://api.motherduck.com/mcp
Claude: find MotherDuck under Customize → Connectors. Add Duck Yeah as a custom connector using the endpoint above, where your plan allows it.
Codex: install the official MotherDuck plugin, start a new chat and verify database access. Add Duck Yeah as a remote HTTP MCP server in your client’s MCP settings.
For other clients and connection options, use MotherDuck’s current setup guide. For a database-enforced read-only connection, use its read-only token instructions. A client instruction to use SELECTs does not change database permissions.
If the records cannot reconstruct eligibility and fit at day 3, start with a data-gap report and a capture plan. Today’s account properties cannot fill in that history.
Start with the field map and gaps. Then compare who would have been included with what happened later, and give Ops and Sales a concrete next test.
The replay uses plain SQL without native AI calls. MotherDuck compute and your agent’s normal usage limits apply.
Duck Yeah receives only your chosen analysis cutoff. Your schema, queries and account records stay in the tools you connect to your own environment.
Use this when reading account notes is the bottleneck. Begin with a small, mixed batch and measure whether the prepared review helps the person making the call.
Native Jev is a billed AI preview. It needs an eligible MotherDuck organization with AI functions enabled in a supported region. Check current availability and usage terms before inference.
A SELECT with prompt_jev makes model calls. It does not send emails or update your CRM. Read the review workflow guide.
To challenge the invented example first, ask your agent to call get_history_plan. That tool returns the saved demonstration; the history prompt above retrieves the reusable template for your data.
The first two versions worked technically, but asked too much of the reader. I kept the useful pieces and rebuilt around a decision Marketing Ops and Sales could use.
“We didn’t make an outcome that had any meaningful value to any one particular user.”
My review of the first version.
I started with an evidence board: public research, fast queries and working integrations. I could inspect the information, but still couldn’t tell a growth operator which opportunity to pursue. I changed the brief: help someone choose a useful next move.
Then I built an experiment lab. Readers could inspect the rules and judge four simulated results, but had to do too much interpretation before finding the point. I kept the analysis and moved the lab here.
What changed: the main walkthrough starts with account history, weighs a useful offer, and ends with what we would try next. The method supports that decision.
These were my reviews of the product, not measured campaign losses.
An archived exercise with four simulated endings, an 8,000-account plan and its original targeting assumptions. It shows the approach I moved away from; the walkthrough above contains the current onboarding play.
Opening the frozen protocol and saved query results…
Imagine an analyst using DuckDB who wants teammates to use recurring analysis. This separate statistical exercise compares general onboarding with help matched to that task. Both groups get two messages, on days 1 and 3. Its fixed assumptions are available below; use the first-week walkthrough above for the current play.
Who: first trials at SaaS companies with 1–200 employees that say they use DuckDB and need to share recurring analysis.
General onboarding on days 1 and 3, with an optional help link.
The same two touches, matched to the stated task. Sales follows up only when there is evidence of a team evaluation and the account opts in.
Reading the historical scenario…
Every case is scored 28 days after the last trial enters. This baseline is invented; my first step in the role would be to query real history before choosing a priority or a sample size.
These modeled accounts test the decision, not the pipeline: no Sales invitations went out and no enrichment ran on them. The account handoff shown earlier is a separate demonstration.
The line shows a 95% confidence interval: differences compatible with these results under the statistical method. Crossing zero means the test has not established an improvement.
Denominator: every assigned eligible account. Treatment minus control. Newcombe 95% confidence interval.
Step ratios are descriptive; the primary outcome keeps the full randomized denominator.
Cohort curves retain accounts that never activate. Do not infer speed from converters alone.
These segment cuts were specified in advance but remain descriptive. Modeled costs are distinct from actual query and model charges.
What do you tell Marketing Ops and Sales?
The packet carries your call, the next steps for each team, the locked plan, saved rows, SQL, the scenario seed and the open questions.
A browser download contains published synthetic evidence only.
My work is the bridge: connect the business question, the technical analysis and the team that acts on it. This demonstration shows that approach; its simulated outcomes are not past pipeline results.
The first version’s record is preserved, including its earlier assumptions and decisions.
Open the dated journey recordThe first test of this page is whether it helped you identify a useful next move and understand how to investigate it.
Only anonymous interaction types and button feedback are recorded. Your decision text is not collected. Page activity is not activation, qualification, or revenue.
I’d love to bring this approach to MotherDuck. Let’s talk about the role and what we’d test first.
Leave your name and email, and I’ll get back to you soon. A little context is welcome, too.
Prefer email? james@jamesdnichols.com. Or call or text if easier: (571) 205-8958.