Product Manager, Documentation Systems

What you'll do:

Required Qualifications

• 5+ years owning an outcome rather than a queue: product management, implementation or solutions consulting, technical program management, support engineering, developer experience, or technical enablement.
• Demonstrated experience automating your own work. You are comfortable in Git, on a command line, and in a codebase you did not write. You do not need to be a software engineer, but you do need to build.
• Practical experience shipping something real with an LLM, including how you evaluated its output and caught it being wrong.
• Direct exposure to customers in difficulty, through implementation, support escalation, solution consulting, professional services, or training. You understand why documentation can be technically correct and still fail the reader.
• Ability to learn a complex product without a specification, and to remember what confused you while learning it.
• Proven ability to influence product managers and engineers you do not manage.
• Comfort saying no. This is one person against a large surface, and prioritization is most of the job.
• It would be beneficial to have worked with MadCap Flare before, as it is what we author in today.
• Experience with docs-as-code or CI-driven publishing.
• B2B fintech, payments, or accounts receivable exposure.
• You have built an internal tool that other people came to depend on.
• Additional information
• We are an equal opportunity employer and value diversity at our company. We do not discriminate on the basis of race, religion, color, national origin, gender, sexual orientation, age, marital status, veteran status, or disability status.

What Will Make You Stand Out (Nice to Have)

Additional information

Preferred Qualifications

• What Will Make You Stand Out (Nice to Have)
• Deep familiarity with at least one complex enterprise system is preferred, such as an ERP or accounting platform, and an appetite to learn more.

Responsibilities

• Own our full documentation surface: in-product Help, implementation guides, support runbooks, and release notes, across our platform and our embedded applications.
• Decide what gets documented, what gets rewritten, and what gets retired.
• Build an information architecture prioritized by what customers search for and get stuck on, rather than by what shipped most recently.
• Define and own the metrics: documentation shipped with the release, page freshness, Help searches returning no results, and support volume on topics we believed were covered.
• Design and build an AI-assisted pipeline that drafts documentation from our real sources of truth: tickets, pull requests, release artifacts, and recorded demos.
• Build the evaluation process that catches the pipeline producing convincing but incorrect content before a customer does.
• Automate change detection, terminology and style enforcement, screenshot capture, and publishing.
• Own the toolchain. We author in MadCap Flare today and publish into a repo that our product loads. You will decide what to keep, what to automate around, and what to change.
• Our tickets today describe what we set out to build, not what we shipped, so documenting a feature currently means reverse engineering it. Change that.
• Partner with Product and Engineering to establish a definition of done that captures how a feature works: navigation, permissions, configuration, error states, and impact on existing users.
• Build the terminology and style standards that let both people and models write consistently across four ERP surfaces where the same concept carries four different names.
• ERPs change their interfaces on their own schedule, and our documentation goes stale when they do. Design the detection and revalidation process and own the SLA on it.
• Learn our products by using them, working out how they behave rather than reading specifications describing how they were intended to.
• Write the small share of content that requires a person: migration guides, error taxonomies, and integration behaviour, where being wrong costs a customer their month-end close.