Decide what gets built next for teams whose data has to be right, and cut scope down to something that ships.
Our customers are building AI products where a wrong value is not an embarrassment but a harm: a missed allergen, an exercise that aggravates an injury, a drug interaction not flagged. They do not need another vector database. They need to be able to say, with evidence, why a value is what it is.
This role decides what we build next for them. That means talking to those teams, understanding the field that actually has to be right, and turning it into slices an engineer can start on Monday, including the acceptance criteria for what must fail closed and what must be provable from a receipt.
The scarce skill here is saying no. The product surface wants to widen constantly (more input formats, more connectors, more knobs) and most of that should wait until the current slice is honest.
What you'd do
- Talk to teams building on safety-critical catalogs and turn what you hear into slices an engineer can start on Monday
- Own the pipeline end to end as a product: inputs, contracts, curation, release, the deployed tool and its security settings
- Write the acceptance criteria, including what must fail closed and what must be provable from a receipt
- Say no to work that widens the surface before the current slice is honest
- Keep the public roadmap and the site accurate about what is built versus what is planned
What we need
- Four or more years in product, at least some of it on a technical or developer-facing product
- You can read an API contract and hold your own in a design discussion with engineers
- You write specs that are specific enough to argue with, including the edge cases
- You have killed or cut a feature you liked, and can explain the call
- Comfortable enough with SQL to answer your own questions about usage
Nice to have, not required
- Background in data quality, catalog management, search or retrieval
- You have worked with a regulated customer and survived a security review
- You have written developer documentation people actually used
How we work
- Small team, thin slices, shipped weekly. Nothing sits on a branch for a month.
- Reviews are real. Every feature ships with its tests, and a bug found in review is cheaper than one found by a customer.
- Safety-critical means the boring answer usually wins: fail closed, keep the receipt, don't guess.
- We only claim what ships. That applies to the product, the roadmap and the offer letter.
How hiring works
- 1 A 30-minute call about something you've built and what was hard about it.
- 2 A working session on a real problem from this codebase. You can drive, or we can pair.
- 3 A conversation about how you make decisions when the evidence is thin.
- 4 References, then an offer. We aim to answer within a week at every stage.
#J-18808-Ljbffr
