Principal Product Manager, Legion Technologies

• 7+ years in product management (Senior) or 10+ years (Principal), including at least 2 years shipping LLM-backed features to external, paying users — not internal tools, proofs of concept, or hackathon projects
• Demonstrated hands-on capability of the kind described above. Expect to show your work
• Substantial enterprise B2B SaaS experience: multi-tenant architecture, role-based access control, audit trails, single sign-on, data residency, security review, and enterprise procurement. You should be able to anticipate what a customer's security questionnaire will ask about an LLM feature
• A record of taking an ambiguous, operationally complex domain problem through to a shipped product with demonstrated adoption — not only launch
• Evidence of staying with a product through implementation and owning its quality at release. We will ask about a release you delayed or stopped, what you found, and how you found it
• The judgment to recognize what current models cannot do reliably, and the willingness to say so when a room expects a different answer
• Comfort working inside a codebase. An engineering background is not required, but you should be able to read the code behind what you are specifying, run it locally, and open a pull request
• Strong written communication. Legion runs on documents, and candidates are evaluated substantially on how they write

Desirable

• Agent definition
• Determine what an agent is responsible for, which tools it may call, what it must escalate, what it must never do, and what a manager sees when it acts
• These decisions affect employee pay and legal compliance
• Much of this work is pre-launch, so you will shape the direction rather than inherit it
• Problem selection
• The hardest judgment in agentic product work is identifying which workflows suit an agent and which do not
• You will spend substantial time inside customer operations — district managers, store managers, labor operations, frontline employees — and return with a ranked, defensible view of where an agent creates measurable value and where it does not
• The human-in-the-loop contract
• Scheduling decisions affect income, childcare arrangements, and legal protections
• For each agent action you will define where autonomy is appropriate, the escalation thresholds, how a manager overrides the system, what is logged, and how a compliance team audits the outcome
• Legion treats this as a first-class design problem
• Build quality
• You are accountable for what ships, not for what was specified
• That means staying engaged through implementation: reviewing the build against the specification as it comes together, using the product yourself before anyone else is asked to, joining bug triage and design review, catching drift from intent while it is still cheap to correct, and holding a release when the quality is not there
• Our customers experience the build, not the document
• A well-written specification that produced a product managers do not trust is failed product work, and we assess it that way
• Evaluation
• Build and maintain the evaluation sets that determine whether an agent is ready to ship and whether it is degrading in production — writing the cases, reviewing failure traces, setting the pass criteria
• You will be the person who holds a release when the demonstration is persuasive and the evaluation is not
• Specifications
• Legion uses Functional Requirements Documents as its ground-truth specification layer; release notes, enablement material, and sales content are generated from maintained specifications rather than reconstructed from code or institutional memory
• Write FRDs that meet that standard and keep them accurate after release
• A specification is where the work begins, not where your responsibility ends
• Commercialization
• Partner with go-to-market on packaging, metering, pricing inputs, and field readiness
• Agentic products raise difficult commercial questions — what unit to meter, what a customer is paying for when software performs work a person previously did — and you will be expected to hold a considered position on them
• Design-partner delivery
• Lead agent deployments with large enterprise design partners: scoping the pilot, establishing success criteria before it begins, joining failure reviews, and determining what becomes generally available and what remains bespoke
• Legion is looking for a product manager who builds, rather than one who directs others who build. In a typical week, this role involves:
• Writing and iterating on prompts and system prompts directly, and explaining why a change improved a behavior
• Standing up a working prototype of a proposed agent — tool definitions, structured outputs, retries, guardrails — before engineering is asked to build anything
• Using agentic coding tools (Claude Code or equivalent) daily: prototyping, data analysis, specification work, and reading the codebase behind your specifications
• Reviewing an execution trace and diagnosing whether a failure originates in a tool description, a retrieval gap, a context-window constraint, an under-specified output schema, or a genuine model limitation
• Building and running evaluation sets, and interpreting the results without a data scientist to translate them
• Holding an informed position on retrieval design, tool-use patterns, structured output, model routing, latency and cost trade-offs, and multi-tenant safety in enterprise SaaS
• Opening pull requests against our codebase — a prototype, a prompt change, an evaluation fixture, a specification stub. Pushing code is permitted and actively encouraged for product managers who want to work that way. It is not a requirement of the role, and the same review standards apply to everyone
• Following model releases, agent frameworks, and protocol changes, and translating them into roadmap implications within days rather than quarters
• We recognize that this is a demanding technical bar for a product role. It reflects what the work actually requires
• So that candidates can assess fit early:
• This is an individual contributor role. There is no team to inherit and no management responsibility at present
• The role is accountable for what ships, not for what is specified. Writing the specification is a portion of the work, not the whole of it
• This is not an AI strategy or vendor-evaluation role. The work is product definition, prototyping, specification, evaluation, and delivery
• The role requires forming an independent point of view from operational research. Direction will not be handed down in detail
• The environment carries genuine ambiguity. The category is being defined as we work in it, and model capabilities shift underneath the roadmap