The Roles, Decoded

Founding product Data Scientist

What the company is

This archetype is an AI SaaS company — typically AI video, AI assistants, AI productivity. The product space is "AI tools that make a previously expensive workflow accessible." Such companies tend to be growing fast and the DS function is being established, not inherited.

What this role actually is

Read literally, this is a Data Scientist req. Read carefully, it's a founding product DS req. The first three responsibilities are infrastructure-coded:

• "Define and establish data/experimentation stack"
• "Partner with engineering on data quality, scalability, and deployment constraints"
• "Build best practices for data-driven decision-making"

That phrasing means there is no robust experimentation platform yet. There may not be a clean event-tracking schema. There almost certainly isn't a metric layer. You're hired to build the foundation, not run experiments on a mature stack.

The rest of the responsibilities are classical product DS: analyze datasets, define metrics, run A/B tests, build dashboards, translate analyses for stakeholders. The order matters — they listed infrastructure first.

What "real-world deployment constraints" implies

This phrase in the qualifications section is doing work. Read it as: "you'll need to discuss your analyses with engineers in a way that respects how the product is actually built". Concretely: if you propose a metric that requires logging an event the system doesn't emit, you need to be able to negotiate that with engineering, not just file a ticket.

The signal in "champion best practices"

This is cultural-leadership language. At a "first DS" role, you don't just do the analysis — you teach the rest of the company how to think about data. PMs will ask you "is this lift significant?" and you have to answer in a way that improves their next instinct, not just resolves the current question.

Lead Data Scientist — Analytics & Data Insights

What the enterprise-AI company is

This archetype is a frontier-model enterprise-AI company — trains and deploys large language models, sells API access and managed deployments to enterprises. Customer base is regulated industries building RAG, agents, and search on top of foundation models — banks, telcos, healthcare, governments. Competes with the major LLM labs on the enterprise side.

What this role actually is

The job title is "Lead Data Scientist" but the team is "Analytics & Data Insights." That's a deliberate framing. This isn't a model-training role on the research team. It's a business analytics leadership role sitting in the Agentic Platform org — close to product, sales, and finance, helping the company make GTM decisions about technology that's still being invented.

The responsibilities cluster into three buckets:

1. Experimentation programs: "A/B tests, multi-armed bandits, causal inference studies, that directly map to product and go-to-market decisions." The MAB + causal call-out is unusual — they're telling you the bar is "rigorous quasi-experimental design," not just two-sample t-tests.
2. Predictive models for the business: "forecasting, segmentation, propensity scoring, and opportunity sizing across the company's core business lines." These are sales/finance/marketing models — predicting which enterprise accounts will convert, sizing the API revenue from a customer segment, forecasting model usage.
3. Team leadership: "manage a team of analysts and data scientists. Set the technical bar, mentor aggressively, and create an environment where exceptional people do their best work."

What "act like an owner" implies

The JD says "no waiting around. You'll define analytical priorities, allocate resources, and push initiatives from question to production." Translation: you're not waiting for a roadmap. You're identifying which analytical bets matter most for the business and pushing your team toward them — including killing work that doesn't.

The signal in "shape strategy"

The line "your team's work will get built into products and implemented into strategy" is the punchline. The role sits close enough to leadership that good analytical work becomes the strategy, not just a report deck. That implies stakeholder altitude is partway up the org — you'll present to VPs and the C-suite.

The stacks, decoded

Both JDs list explicit tools. Here's what each one signals.

Founding-DS stack signals

Leadership-role stack signals

The shared spine

Strip away the level and the company and both roles converge on the same five-pillar bar:

1. SQL fluency at speed — window functions, cohorts, funnels, retention, gotchas. Both loops will test this.
2. Rigorous experimentation — A/B design from a fuzzy product question, sample size, peeking. Senior-IC JDs extend this into MABs and causal inference.
3. Predictive modeling for business decisions — forecasting, segmentation, propensity. Practical, not exotic.
4. Product metrics fluency — north star, leading vs lagging, guardrails. Both expect you to talk like a PM does.
5. Communication to non-technical stakeholders — both JDs say it explicitly. The work is only as good as the recommendation it produces.

Sections B, C, and the drill set of this guide all target this spine.

The seniority delta

Founding-DS roles are typically mid-level (3+ years). Analytics-leadership roles are senior IC + manager. The delta shows up in three places:

• Scope of ambiguity. Founding-DS JDs say "highly dynamic." Leadership-role JDs say "tackle problems that don't have textbook answers yet." Both want comfort with ambiguity, but the senior role wants someone who will operate at a level where the question itself is unclear, not just the answer.
• Team leadership. Founding-DS JDs want someone who collaborates and champions best practices. Leadership-role JDs want someone who manages a team, sets the technical bar, and mentors. This is the biggest single difference between the two loops — leadership loops will have at least one "tell me about leading a team" round; founding-DS loops probably won't.
• Methodological depth. Founding-DS JDs list A/B testing generically. Senior-IC JDs name "multi-armed bandits, causal inference studies" specifically. Expect a methods round at the senior level that goes deeper than two-sample tests.

Soft signals to expect

Both JDs lean into the same cultural patterns. Reading these in advance helps you not be caught off guard:

• "Real ownership" / "act like an owner." Both companies say this. They mean it. In interviews, frame your past work as decisions you owned, not tasks you were assigned.
• "Fast-paced" / "high-velocity." Both. The implicit question is: can you produce a defensible recommendation in days, not months?
• "Ambiguity" / "no textbook answers." Both. They're testing whether you reach for a textbook (bad) or for a framing of the problem (good) when stuck.
• "Lay the foundation" (founding-DS framing) / "build the foundational infrastructure" (leadership framing). Both archetypes signal that what exists today is incomplete. You're not optimizing a working system — you're building parts of it.

What to ask them

The questions you ask are part of the signal you send. A handful that land well in either loop:

• "What does the current experimentation infrastructure look like, and what's the biggest gap?" — Forces specificity. Lets them tell you what they actually need help with.
• "Walk me through a recent analysis that changed a product or GTM decision." — Gauges whether their analytical work has teeth or is decorative.
• "What's the one metric the team is most uncertain about, and why?" — Signals you think in terms of measurement uncertainty, not just lift.
• For analytics-leadership loops: "How does the analytics team partition work between embedded DS and central platform?" — Senior-level org question. Shows you've thought about structure.
• For founding-DS loops: "Who owns event-tracking schema decisions today? Where do those decisions live?" — Lets you find out if you'd be greenfielding or backfilling.
• "What does failure look like in this role at 90 days? At a year?" — Best generic question in the bank. Forces them to describe the role concretely.