JRD Systems
Website:
jrdsi.com
Company:
https://www.linkedin.com/company/jrd-systems
Seniority: Mid-Senior level
Industries: IT Services and IT Consulting
Job details:
Business Analyst, Product
Sections below drop into the standard job description template.
About the role
We are building a new AI-native software product for behavioral health practices. It automates the operational coordination work that practices currently spread across spreadsheets, personal phones, and consumer messaging apps, and it works alongside a practice's existing clinical system rather than replacing it. The product is in active build with a design partner engaged.
This is not a requirements-gathering role. There is no client who already knows what they want, and we are not looking for someone to translate a stakeholder's wish list into tickets. You will be the person on this team who is hardest to fool: you find out what is actually true about how these practices work, you design cheap tests for the things we are only guessing about, and you make sure every item on the roadmap carries a visible evidence status.
What you will do
- Own the evidence layer: maintain the map of validated opportunities, candidate solutions, and open assumptions behind every active outcome.
- Tag every roadmap item with its evidence status: validated with a customer, partially evidenced, or untested assumption. Keep that tagging honest when it is inconvenient.
- Run the standing weekly discovery sessions with our design partner alongside the rest of the product team. Recruit participants, prepare the question, capture the session, and publish synthesis within a day.
- Turn our riskiest guesses into the cheapest test that could disprove them. Most should require no engineering time: manual message tests, wizard-of-oz workflows, pricing conversations, concierge runs of a workflow we have not built.
- Report results plainly, including the ones that kill an idea we like. Killing an idea early is a completed piece of work here, not a failure.
- Document current-state workflows at real practices, end to end, from the first referral through scheduling, documentation, and the billing handoff.
- Quantify the friction. Touches per referral, days from first contact to first delivered service, cancellation-to-rebook rate, hours per week lost to administrative chasing. These become our outcome baselines and our business case.
- Analyze the integration surface of the clinical systems we connect to: available objects, field-level coverage, rate limits, authentication model, and what our architecture can and cannot rely on.
- Maintain the data dictionary and field mapping between our product and connected source systems, and be precise about where the boundary sits.
- Write the artifacts that follow the evidence: user stories, acceptance criteria, edge cases, state diagrams, and test scenarios, produced once we know what is true rather than before.
- Handle compliance analysis for anything touching protected health information, including the audit-trail requirements behind a model where AI drafts and a licensed clinician attests.
- Define the metric behind each quarterly outcome, baseline it with the design partner before we commit to it, and report movement weekly. Percent-complete is not a metric we use.
What this role does not include
- Writing requirements ahead of evidence, or owning a scope document that gets frozen and signed.
- Acting as the translation layer between the customer and engineering. Engineers and designers attend discovery sessions directly; your job is to make those sessions sharper, not to replace them.
- Project management, status reporting, or running the sprint.
Required
- Four or more years as a business analyst, product analyst, or equivalent, including work on a product where the answer was genuinely unknown at the start.
- You have mapped how work actually gets done inside a complex, regulated, or multi-party operation, and found the friction that the org chart does not show.
- You have run customer interviews yourself, not just read the notes. You can tell the difference between what someone says they do and what they actually do.
- Comfort with APIs and data models. You can read API documentation, reason about field-level mapping, and hold your own in an architecture conversation without being an engineer.
- Analytical range from a spreadsheet to a SQL query. You are expected to produce numbers, not request them.
- Writing that is short, specific, and honest. Most of your output is written, and much of it will be read by people who were not in the room.
- Appetite for an unfamiliar domain. We do not expect you to arrive knowing this one. We do expect you to know it better than anyone else here within six months, and to enjoy that.
Strong plus
- Healthcare experience of any kind: provider operations, revenue cycle, prior authorization, payer workflows, or clinical software.
- Direct exposure to behavioral health, autism services, or pediatric therapy, whether as an analyst, a practice operator, or a clinician.
- Hands-on experience with an EHR or practice management platform, from either side of the implementation.
- Experience in another regulated or high-stakes operational domain: insurance, financial services, logistics, or public sector.
- Familiarity with continuous discovery as Teresa Torres describes it, or the product operating model as Marty Cagan describes it.
- Experience at a company creating a new category rather than competing in an established one.
How we work
- The product team is a trio: product, design, and engineering, working the same problem at the same time. You sit inside that trio, not adjacent to it.
- There is a standing weekly session with our design partner. It does not get cancelled for being inconvenient.
- We commit to an outcome each quarter and ship at least every two weeks. Scope is what we trade; the outcome is what we hold.
- PHI governance is strict and non-negotiable. Protected health information does not move through tools without a BAA in place.
- The product is funded with a committed multi-year engineering investment. This role is early enough to shape how the product team works, not just what it builds.
First ninety days
- Days 1 to 30: learn the domain fast and sit in on every design partner session. Produce a current-state workflow map that a practice manager would recognize as accurate. Baseline three operational metrics.
- Days 31 to 60: run four assumption tests without consuming engineering time, and publish what each one changed. Add an evidence-status column to the existing roadmap and fill it in.
- Days 61 to 90: own the opportunity map for one quarterly outcome end to end, and be the person the team asks when someone wants to know whether something is actually true.
Click on Apply to know more.