Job Description

Job Description

When to Use

Use this skill when:

• The user explicitly asks to write, create, draft, or update a job description, job posting, or JD for a specific role
• The user needs to define a new position with responsibilities, requirements, and compensation structure for an open headcount
• The user wants to convert an existing role description from a task list or org chart entry into a competency-based, hireable job posting
• The user wants to refresh or modernize a stale JD to reduce bias, improve candidate quality, or comply with pay transparency laws
• The user needs a JD template calibrated to a specific function (engineering, sales, finance, design, operations) and seniority level (entry, mid, senior, staff, director, VP, C-suite)
• The user is an HR business partner, recruiter, or hiring manager and needs guidance on writing inclusive, legally defensible job descriptions
• The user is building a job architecture or leveling framework and needs consistent JD templates across a band

Do NOT use this skill when:

• The user wants to write a resume or CV for themselves or on behalf of a candidate -- use resume-builder
• The user needs an interview guide, structured interview questions, or a scoring rubric for evaluating candidates -- use interview-guide
• The user needs a formal offer letter or employment contract -- use offer-letter
• The user wants a performance review template or employee evaluation framework -- use performance-review
• The user wants a job leveling matrix, career ladder, or compensation band framework -- use job-leveling
• The user is asking for career advice about which job to pursue or how to get promoted -- use career-planning
• The user wants an organizational design consultation about whether a role should exist, where it should sit, or how teams should be structured -- these are strategic decisions that require more context than a JD can resolve

Process

Step 1: Gather Role Intelligence Before Writing a Single Word

Do not draft the JD before you have enough information. Attempt to extract the following from the user's request. If critical information is missing, ask a single consolidated set of questions rather than peppering the user with multiple follow-ups.

• Job title: Is it internally consistent with the company's leveling framework? (A "Senior Engineer" at a 10-person startup is not equivalent to a "Senior Engineer" at a 5,000-person enterprise -- flag this if relevant)
• Department and team: What org does this sit in? Who owns the budget for this role?
• Reporting structure: Who does this person report to? Do they manage anyone? If so, how many direct reports?
• Seniority level: Entry (0-2 years equivalent experience), mid (2-5), senior (5-8+), staff/principal (8+ with broad scope), manager/director (leading a team), VP/C-suite (executive accountability)
• Employment type: Full-time, part-time, contract, fractional, or temp-to-hire
• Location and work model: Fully remote (and which time zones), hybrid (how many days on-site), or in-person; city or region for in-person roles
• Role purpose statement: In 1-2 sentences, why does this role exist? What problem does it solve or what value does it create?
• Key initiatives for the first 6 months: What are the most important projects or deliverables this person will own in their first two quarters?
• What good looks like at 12 months: What would make the hiring manager say "this was an outstanding hire"?
• Compensation range: Salary or hourly rate, bonus structure, equity if applicable. If the user is unsure or reluctant, note that pay transparency reduces time-to-hire by an average of 30%, improves offer acceptance rates, and is legally required in California (SB 1162), Colorado (EPEWA), New York City (Local Law 32), Washington, and several other jurisdictions

Step 2: Calibrate Tone, Level, and Scope Before Drafting

Before writing, determine two parameters that govern every subsequent decision:

A. Role type classification -- this shapes the vocabulary and structure:

• Individual contributor (IC): Responsibilities are task and craft-focused ("Design and build," "Analyze and report," "Manage and maintain")
• Player-coach (manager who also does the work): Split responsibilities between people leadership and direct contribution -- typically 40/60 or 60/40 depending on team maturity
• People manager: Responsibilities focus on outcomes, team health, and cross-functional influence more than direct craft ("Build and develop a team," "Define the roadmap for," "Partner with")
• Executive: Responsibilities are accountability areas, not tasks ("Own the commercial strategy," "Ensure the company's security posture scales with growth")

B. Leveling calibration -- use this internal framework to set expectations:

• Entry: Learning the craft, contributing to defined tasks, gaining exposure
• Mid: Independent execution within a defined scope, handles ambiguity in familiar domains
• Senior: Independent execution in novel situations, influences others, raises the floor of the team
• Staff/Principal: Spans multiple teams, drives technical or functional strategy, multiplies other people's output
• Director: Sets the organizational roadmap, hires and develops managers, owns cross-functional outcomes
• VP/C-suite: Owns a business domain, operates at the intersection of company strategy and external relationships

Getting the level wrong is one of the most common JD errors -- an entry-level JD with senior-level requirements creates a near-impossible hiring bar and discourages qualified candidates.

Step 3: Write the Role Summary with a Hook

The role summary is the single highest-ROI section of a job description. Research from large-scale job board data shows that the first 250 words of a posting determine whether a candidate reads the rest. Write 3-5 sentences that accomplish four things:

• What: What does this person do at the highest level of abstraction?
• Why: Why does this role matter to the business, customers, or mission?
• Who: Who will they work with and what kind of team environment will they operate in?
• Win condition: What does outstanding performance look like at 6-12 months?

Use second person ("You will...") unless the company's voice is third person. Avoid:

• Corporate filler ("We are looking for a passionate, self-starter who thrives in a fast-paced environment")
• Superlatives ("world-class," "best-in-class," "exceptional")
• Culture-code words that signal exclusion ("hustle culture," "ninja," "rockstar," "guru," "wizard")
• Vague promises ("opportunity to make an impact," "be part of something special")

Good role summaries describe a real job with real stakes. If you cannot name the stakes, ask the user.

Step 4: Write 5-8 Responsibilities Using the AVR Method

Each responsibility should follow the Action-Value-Result (AVR) structure:

• Action: Begin with a present-tense action verb that matches the level (entry: "Support," "Contribute to," "Assist"; mid: "Develop," "Build," "Manage"; senior: "Design," "Own," "Lead"; executive: "Define," "Shape," "Ensure")
• Value: Describe the domain or artifact being acted upon with enough specificity that the candidate understands the scope
• Result: Where possible, describe the outcome or the standard of success ("...that supports 99.9% uptime targets" or "...enabling the sales team to reduce cycle time by 20%")

Ordering principle: Lead with the highest-leverage responsibility -- the one that, if left undone, makes everything else moot. End with cross-functional, mentorship, or continuous-improvement responsibilities.

Scope check: If you need more than 8 responsibilities to describe the role, raise this with the user. Roles with 9+ distinct responsibility domains are typically two roles that have been combined, or an under-resourced team trying to fill multiple gaps with one hire. This conversation can save a company a 6-month bad hire.

Common verb banks by function:

• Engineering: Design, architect, build, implement, maintain, instrument, debug, optimize, migrate, review, document
• Product: Define, prioritize, synthesize, communicate, coordinate, launch, analyze, iterate
• Sales: Prospect, qualify, manage, close, forecast, develop, negotiate, expand, build
• Finance: Model, forecast, reconcile, report, analyze, manage, close, advise, assess, support
• Design: Research, design, prototype, test, iterate, define, communicate, present, document
• Operations: Oversee, coordinate, standardize, improve, track, manage, implement, scale, audit
• HR/People: Partner, develop, administer, advise, recruit, build, facilitate, manage, design

Step 5: Build Requirements Using Competency-Based Criteria

The most common JD mistake is conflating requirements (what you actually need) with preferences (what would be nice), and expressing both as years-of-experience proxies that do not predict performance.

Must-have requirements (target 4-6 items): Apply the "Day One Rejection Test" to every item -- "If a candidate had every other quality we wanted but lacked this, would we reject them?" If the answer is no, move it to nice-to-have. Common categories for must-haves:

• Demonstrated capability: "You have designed and shipped backend APIs that handle concurrent users at scale" not "5+ years of backend engineering"
• Domain knowledge: "You understand double-entry bookkeeping and can reconcile a balance sheet" not "accounting degree required"
• Behavioral competency: "You have managed competing priorities in an ambiguous, fast-moving environment and can show your process for doing so" -- useful for roles where judgment and adaptability are differentiating factors
• Certifications or licensure (only when legally required): CPA for signing financial statements, PE license for structural engineering sign-off, Series 7 for certain financial advisory roles

Nice-to-have requirements (target 3-5 items): These describe the best version of a candidate, not the minimum viable version. Useful framing: "A candidate who brings these skills will accelerate their impact and require less ramp time."

What to explicitly exclude:

• Degree requirements unless legally required or the role genuinely cannot be done without that credential -- removing degree requirements increases applicant pool diversity by 10-30% in most functions
• Exact year counts ("3-5 years of...") -- these are arbitrary proxies for seniority that correlate poorly with performance and may create age discrimination exposure
• Tool-specific lists ("Must know Jira, Confluence, Slack, Notion, and Asana") -- tool fluency is learned in days; include only tools where deep expertise is a genuine differentiator
• Physical requirements not related to bona fide occupational qualifications

Step 6: Structure Compensation and Benefits Transparently

Compensation structure guidance:

• Express salary ranges as annual figures for full-time roles, hourly or daily rates for contract roles
• The range should represent the realistic hiring range -- not a floor-to-ceiling span of $80K. Best practice is a range width of 15-25% of the midpoint (e.g., $120K-$150K for a $135K midpoint, not $100K-$200K)
• If equity is included, describe the structure: "Stock options" vs. "RSUs," vesting schedule (4-year with 1-year cliff is standard), and whether the grant is a fixed number or a percentage of total shares outstanding
• Bonus: specify target percentage (e.g., "10% target annual bonus tied to individual and company performance"), not just "eligible for bonus"
• For contract roles: specify if the rate is corp-to-corp (C2C), W-2, or 1099, as the take-home varies significantly and candidates self-select based on tax implications

Benefits highlights (choose 3-5 that are genuinely differentiating):

• Do not list "competitive salary" as a benefit -- it is the salary, not a benefit
• Do not list legally required benefits (Social Security matching, workers' comp) as perks
• Differentiating benefits worth naming: employer-paid health premium percentage, 401(k) match percentage and vesting schedule, equity participation, parental leave weeks (not just "generous leave"), home office stipend amount, L&D budget amount, unlimited PTO with a floor, sabbatical policy

Step 7: Add Role Context That Converts Passive Candidates

Passive candidates -- those not actively job hunting but open to the right opportunity -- are often the most qualified pool. They need more than a list of requirements to apply. Add:

30/60/90 day ramp: One to two sentences per milestone. First 30 days focus on onboarding, relationship-building, and context absorption. Days 31-60 are typically about small contributions and understanding the technical or functional landscape. Days 61-90 involve owning a meaningful deliverable independently.

Growth trajectory: What could this role become in 18-24 months? IC roles can grow to senior, staff, or into management. Management roles can expand scope, headcount, or functional breadth. Do not over-promise, but concrete paths increase application rates.

Team culture signal: Two to three sentences that describe how the team actually works -- not "collaborative and innovative." Useful signals: "We do architecture reviews before major projects and post-mortems after incidents," "The product and engineering teams co-own the roadmap in weekly planning sessions," "We have a no-blame culture around bugs and a high bar for design quality."

Step 8: Review for Bias, Inclusion, and Legal Compliance

Run the completed JD through this five-point checklist before delivering to the user:

1. Gendered language scan: Flag masculine-coded words (aggressive, competitive, dominant, rock star, ninja, strong, independent) not balanced by communal words (collaborative, supportive, mentoring, inclusive). Replace "he/she" with "they" or restructure into second person.

2. Age discrimination exposure: Remove any language that implies a preference for younger ("recent graduate," "digital native," "energetic") or older ("seasoned," "veteran") candidates unless directly relevant. Remove year-count requirements that could screen out experienced candidates.

3. Disability and accommodation: Include or recommend an ADA (Americans with Disabilities Act) accommodation statement. For in-person or physical roles, list only physical requirements that are genuine occupational necessities.

4. Unnecessary credential filter: Confirm that any degree or certification requirement has a genuine operational justification. The EEOC's adverse impact standard means that credential requirements that disproportionately screen out protected classes require job-relatedness justification.

5. Inclusion invitation: End with a statement that explicitly invites candidates who meet most (not all) requirements to apply. Studies show that men apply when they meet 60% of listed requirements; women and underrepresented candidates tend to apply only when they meet 90%+. Naming this dynamic and inverting it expands the qualified applicant pool.

Output Format

## [Job Title]

**Department:** [Department name]
**Reports to:** [Title of direct manager]
**Direct reports:** [Number, or "None" for IC roles]
**Location:** [City, State / Remote / Hybrid (X days/week in [City])]
**Employment type:** [Full-time / Part-time / Contract -- duration if contract]
**Compensation:** [$X,000 -- $X,000/year | $X/hour] [+ bonus and/or equity if applicable]

---

### About the Role

[3-5 sentences: what the role does, why it matters to the business or customers,
who the person works with, and what success looks like at 6-12 months.
Write in second person ("You will...") or neutral third person ("This role...").
No jargon, no superlatives.]

---

### What You Will Do

1. **[Strong action verb + domain artifact].** [1-2 sentences of scope and outcome context.
   What does this look like at scale? What standard are we aiming for?]

2. **[Strong action verb + domain artifact].** [1-2 sentences.]

3. **[Strong action verb + domain artifact].** [1-2 sentences.]

4. **[Strong action verb + domain artifact].** [1-2 sentences.]

5. **[Strong action verb + domain artifact].** [1-2 sentences.]

6. **[Strong action verb + domain artifact].** [1-2 sentences. This slot is often used for
   cross-functional collaboration, communication, or stakeholder management.]

7. **[Strong action verb + domain artifact].** [Optional 7th responsibility. Use only if genuinely
   distinct from items above. If the role demands this many, confirm it is still one role.]

---

### What We Are Looking For

**You must bring:**
- [Demonstrated capability statement -- what they have done, not how long they have done it.
  Focus on outcomes, scale, complexity, or domain.]
- [Second must-have: behavioral or domain competency]
- [Third must-have: technical or functional competency]
- [Fourth must-have: communication, leadership, or cross-functional competency if relevant]
- [Fifth must-have: only add if genuinely required on Day One -- keep to 4-6 total]

**You will stand out if you also bring:**
- [Nice-to-have 1: specific skill or experience that accelerates impact]
- [Nice-to-have 2: adjacent domain knowledge]
- [Nice-to-have 3: tool, methodology, or industry background]
- [Nice-to-have 4: optional 4th if the role has a strong differentiating profile]

---

### Compensation and Benefits

- **Base salary:** $[X,000] -- $[X,000] per year
- **Bonus:** [Target percentage and structure, or omit if not applicable]
- **Equity:** [RSUs / options, vesting schedule -- e.g., "4-year vest, 1-year cliff" -- or omit]
- **Benefits highlights:**
  - [Most differentiating benefit: e.g., "100% employer-paid medical, dental, and vision"]
  - [Second benefit: e.g., "$3,000 annual learning and development budget"]
  - [Third benefit: e.g., "16 weeks fully paid parental leave, primary and secondary caregiver"]
  - [Fourth benefit if applicable: e.g., "$2,000 home office setup stipend"]
  - [Fifth benefit if applicable: e.g., "Flexible PTO with a 3-week annual minimum"]

---

### What to Expect

**Your first 30 days:**
[1-2 sentences: onboarding focus, key relationships to build, context to absorb]

**Your first 90 days:**
[1-2 sentences: first independent contribution, first meaningful deliverable or milestone]

**At 12 months:**
[1-2 sentences: what does outstanding performance look like? What has this person built,
changed, or set in motion?]

**Growth trajectory:**
[1-2 sentences: what can this role become? Be concrete but honest.]

---

### Our Team

[2-3 sentences describing actual working culture -- how decisions get made, how the team
communicates, what norms exist. Avoid "fast-paced," "collaborative," and "innovative"
without specifics to back them up.]

---

### How to Apply

[Application instructions: link to ATS, what to include in the application, whether a cover
letter is required, and a rough timeline for the hiring process.]

[Accommodation statement: "We are committed to an inclusive hiring process. If you require
accommodations at any stage, please contact [email or HR contact]."]

We encourage you to apply even if you do not meet every requirement listed here.
Research shows that qualified candidates -- especially those from underrepresented groups --
often self-select out of roles they are well-suited for. If this role excites you and you
bring most of what we are looking for, we want to hear from you.

Rules

1. Never require a specific number of years of experience as a must-have. "5+ years of Python" tells you nothing about ability and may create age discrimination exposure. Use demonstrated capability language instead: "You have built and maintained Python services in production, including handling errors, logging, and deployment." This is testable in an interview; year counts are not.

2. Never list more than 8 responsibilities. A role with 9+ distinct responsibilities is either two roles, or a role that has not been thought through. If the user insists on 9+, surface the concern explicitly: "This role description covers what looks like multiple distinct domains. You may find that no candidate can do all of this well, or that a strong candidate will scope the role themselves and ignore the parts they find less interesting." Ask which 6-8 items are truly non-negotiable.

3. Must-have requirements must pass the Day One Rejection Test. Before including any item in the must-have list, ask: "Would we reject an otherwise excellent candidate who lacks only this one thing?" If the answer is "it depends" or "probably not," it belongs in nice-to-have. Inflated must-have lists reduce applicant volume without improving candidate quality -- research from LinkedIn Talent Insights shows job posts with 6+ must-have requirements receive 23% fewer applications than posts with 4 or fewer.

4. Remove degree requirements unless legally required or genuinely predictive of job performance. A computer science degree requirement for a software engineering role that values demonstrated ability in open-source contribution, portfolio projects, or bootcamp training is an unnecessary barrier. A CPA requirement for a Comptroller role signing off on financial statements is legally and professionally justified. When in doubt, ask the user: "Would you interview a candidate with a strong portfolio and no degree?" If yes, remove the degree requirement.

5. Compensation ranges must reflect the actual hiring range, not the entire band. A range of $80,000--$200,000 conveys no information and will be perceived as evasive by candidates. Target a range width of 15-25% of the midpoint. If the user says "our band is wide," help them narrow to a realistic offer range for this specific role and level.

6. Never use culturally exclusionary shorthand. Terms like "rockstar," "ninja," "guru," "wizard," "10x engineer," and "hustle" signal a cultural filter that correlates strongly with age, gender, and background homogeneity. They also attract candidates who self-identify with those terms, which tends to harm team psychological safety and collaboration norms. Replace with specific, observable competency descriptors.

7. Avoid the "laundry list of tools" anti-pattern in requirements. Listing "PostgreSQL, MySQL, SQL Server, BigQuery, and Redshift" as requirements communicates that you want familiarity with relational databases -- say that instead. Listing tools signals that the role will be narrow and tool-locked rather than craft-focused. The exception: when a specific proprietary system or deeply specialized tool is a genuine core requirement (e.g., Salesforce CPQ configuration for a RevOps-specific role).

8. Always end with an explicit inclusion invitation. This is not performative -- it has a measurable effect on applicant diversity. Name the dynamic: tell candidates that you want to hear from people who meet most of the requirements. Studies by Hewlett Packard Enterprise and LinkedIn show this phrasing increases applications from women by 18% and from candidates from underrepresented racial and ethnic groups by 12% on comparable job posts.

9. The responsibilities section must be written at the correct level of abstraction for the seniority. An entry-level JD that says "Define the team's API architecture strategy" is creating a false expectation. A director-level JD that says "Write unit tests for the user authentication module" is describing two levels below the correct scope. Mismatched responsibility-level language is a leading cause of early attrition -- the hire discovers on their first week that the role is not what the JD described.

10. Every requirement must be assessable in the interview process. If you cannot design a question, a work sample, or a behavioral prompt that tests for a listed requirement, it should not be a requirement. This rule eliminates vague filler like "passionate about technology," "entrepreneurial mindset," and "excellent communication skills" unless accompanied by a testable behavioral definition (e.g., "You have presented technical concepts to non-technical stakeholders at the executive level and can describe a specific example").

Edge Cases

Executive-level roles (VP, SVP, C-suite): Shift the entire document from task-oriented language to accountability-and-outcome language. A VP of Engineering does not "write code" or "design services" -- they "own the technical strategy and platform health that enables the engineering team to ship with quality and speed." Must-have requirements shift from technical skills to leadership track record: "You have built and scaled an engineering organization from 20 to 60+ engineers" or "You have led a company through a platform migration without interrupting product delivery." The 30/60/90 ramp focuses on stakeholder relationship-building, organizational diagnosis, and strategy articulation rather than technical contribution. Compensation often includes an Executive Annual Incentive Plan (EAIP) with both individual and company performance gates -- describe the structure if provided.

Staff and principal-level IC roles: These roles sit above senior but below management and require a different vocabulary. Staff engineers and principal scientists operate across multiple teams or systems, drive standards adoption, and are force multipliers for other ICs. Responsibilities should reflect scope beyond a single team ("Define the observability strategy across all backend services," "Lead the cross-team migration to a shared data model"). Requirements should focus on influence without authority, technical depth combined with breadth, and evidence of driving organizational-level change. Avoid implying management responsibilities unless they are genuinely part of the role -- many strong staff candidates have explicitly chosen the IC track and will screen out if the JD implies hidden management expectations.

Entry-level and new-graduate roles: Remove all experience requirements and replace with aptitude indicators. Useful proxies for entry-level candidates: relevant coursework, capstone projects or theses, personal or open-source projects, internship contributions, or demonstrated learning velocity (certifications, community participation). Nice-to-haves should feel achievable -- "You have built a small web application outside of coursework" not "You have experience with production deployments." The 30/60/90 ramp should emphasize mentorship, structured onboarding, and psychological safety to make mistakes. Compensation may include a transparent entry-level band -- be especially careful about equal pay compliance here, as entry-level ranges are scrutinized closely in audits.

Roles with remote-first or async-first working models: Specify time zone requirements precisely (e.g., "overlap with US Pacific Time, 9am--1pm PT required"). Passive candidates often parse time zone requirements as hard filters -- vague language like "flexible time zones" leads to bad matches late in the process. Note explicitly whether in-person requirements exist (quarterly team offsite, annual company gathering, customer visits) and the company's policy on covering travel. Describe the asynchronous communication tooling and norms: "We use Slack for synchronous communication and Notion for documentation -- we write decisions down rather than relying on meetings." Home office stipend and equipment policy belong in benefits.

Contract and fractional roles: Specify the contract type (1099 independent contractor, W-2 through a staffing agency, C2C through the candidate's own LLC), duration, renewal or extension policy, and conversion-to-full-time potential. Compensation should be listed as an hourly or daily rate. If the role does not include benefits, say so explicitly and early -- omitting this information leads to wasted time in late-stage negotiations. For fractional executive roles (fractional CFO, fractional CMO), describe the expected time commitment in hours per week or days per month rather than a percentage of FTE.

Regulated industries (healthcare, financial services, legal, government contracting): Some certifications and credentials are genuinely required by law or regulation, not just hiring preference. A HIPAA-covered entity hiring a Privacy Officer may legitimately require CIPP certification. A broker-dealer hiring a licensed representative requires FINRA Series 7 and 63. A federal contractor may require US citizenship or a security clearance. When the user identifies a regulated role, surface these requirements explicitly and note that they are legally defensible credential requirements -- distinct from the general guidance to remove unnecessary degree requirements. Include the credential or license in the must-have list with a brief parenthetical explaining the regulatory basis.

Replacing an underperforming incumbent: If the user reveals that this is a backfill due to a performance issue, be careful not to write a JD that is a thinly veiled description of what the previous person failed to do. JDs written this way often include oddly specific requirements ("must be comfortable being held accountable for deadlines") or responsibilities that reflect past failures rather than genuine role scope. Ask the user to describe what success looks like going forward, not what went wrong previously. The JD should attract the best candidates for the role as it should be -- not serve as a postmortem of the previous hire.

Roles in jurisdictions with pay transparency laws: As of 2024, mandatory pay range disclosure applies to all employers with 15+ employees posting roles accessible to candidates in California, Colorado, New York City, Washington, Hawaii, Illinois, and several other jurisdictions. For remote roles where any candidate in those states could apply, a conservative legal interpretation requires posting a salary range. If the user is reluctant to include a range, provide this framing: "Not including a range reduces your applicant pool in these jurisdictions, increases time-to-fill, and creates a compliance exposure if any candidates in covered states apply. The most practical path is to include the range."

Example

Input from user: "Can you write a job description for a Senior Product Manager? It's at a B2B SaaS company -- about 200 employees. The PM will own our analytics product, which is the fastest-growing part of our platform. They report to the Head of Product. The team is hybrid -- NYC office 2 days a week. We want to pay $150K--$190K base plus a 10% target bonus. We also have equity."

Output:

Senior Product Manager -- Analytics

Department: Product Reports to: Head of Product Direct reports: None Location: Hybrid -- New York City (2 days/week in office, Tuesday and Thursday) Employment type: Full-time Compensation: $150,000 -- $190,000 base salary + 10% target annual bonus + equity

About the Role

You will own the product strategy and execution for our analytics product -- the fastest-growing area of our platform and the feature set our enterprise customers cite most often as their reason for renewing and expanding. This role sits at the intersection of data, UX, and enterprise sales, and your decisions will directly influence the outcomes of customers who use our platform to run their businesses. You will work closely with an engineering team of five, a product designer, and a data team, partnering daily with sales and customer success to translate customer problems into product bets. At 12 months, the bar for success is clear: a shipping cadence the team is proud of, a customer satisfaction score that has improved measurably, and an analytics roadmap the company trusts.

What You Will Do

1. Define and own the analytics product roadmap. Work with customers, sales, customer success, and internal data stakeholders to identify the highest-leverage bets for the analytics product. Maintain a rolling 12-month roadmap and a sequenced 90-day delivery plan that the team can build to.

2. Translate customer problems into clear, buildable specifications. Conduct discovery interviews, synthesize qualitative and quantitative signals, and produce product requirements that give engineers and designers the context they need to make good decisions -- without over-specifying the solution.

3. Lead sprint planning and delivery cadence with the engineering team. Act as the connective tissue between the engineering team and the rest of the business. Manage scope and trade-off decisions in real time, keep stakeholders informed about progress and changes, and remove blockers that slow delivery.

4. Define and track product success metrics. Instrument the analytics product with the right KPIs -- engagement depth, time-to-value, feature adoption rates, and retention correlations. Build a shared understanding of what the metrics mean and use them to inform prioritization decisions in every planning cycle.

5. Partner with sales and customer success to close and retain enterprise accounts. Participate in late-stage sales conversations for enterprise deals where product roadmap and capability are a buying factor. Conduct quarterly business reviews with key accounts alongside customer success managers to understand adoption and identify expansion opportunities.

6. Synthesize competitive intelligence and market trends. Monitor the competitive landscape in B2B analytics and data visualization. Identify where we have differentiation and where we are at risk, and bring those insights into roadmap prioritization.

7. Develop and coach junior product talent. As a senior contributor, model strong product craft for associate and mid-level PMs on the team. Share frameworks, give feedback on discovery and specification work, and participate in the team's product critique process.

What We Are Looking For

You must bring:

• Demonstrated experience owning a B2B SaaS product end-to-end -- from discovery and prioritization through shipping and measuring outcomes. You have made difficult trade-off calls and can articulate how you made them.
• The ability to work closely with data and analytics domains -- you do not need to be a data engineer, but you understand how data pipelines work, why data quality matters, and what it means to design an analytics UX that builds trust with business users.
• Strong cross-functional influence. You have worked alongside sales, customer success, and enterprise customers, and you know how to navigate competing inputs without losing sight of the product strategy.
• A track record of shipping: you have delivered multiple product initiatives from concept to measurable customer outcome in a software environment with engineers and designers.
• The ability to write clearly and reason publicly. At our size, good written communication is how decisions get made asynchronously -- you can write a one-pager, a PRD, or a stakeholder update that people actually read and trust.

You will stand out if you also bring:

• Experience building analytics, reporting, or data visualization features -- you have thought deeply about how business users consume and act on data
• Familiarity with enterprise SaaS sales cycles, including how product roadmap conversations factor into procurement decisions
• Background working with a data or BI team on instrumentation strategy -- you know what good product analytics infrastructure looks like from the inside
• Experience in a company that scaled from ~100 to 300+ employees -- you understand how process and communication norms change as the team grows

Compensation and Benefits

• Base salary: $150,000 -- $190,000 per year
• Bonus: 10% target annual bonus, paid based on individual and company performance against defined goals
• Equity: RSU grant with 4-year vesting schedule and 1-year cliff; grant size based on level and scope at time of offer
• Benefits highlights:
  • Employer pays 100% of medical, dental, and vision premiums for employees (80% for dependents)
  • $2,500 annual learning and development budget (conferences, courses, books -- no approval required under $500)
  • 16 weeks fully paid parental leave for primary caregivers; 8 weeks for secondary caregivers
  • 401(k) with 4% employer match, fully vested immediately
  • Flexible PTO -- we ask that you take a minimum of 3 weeks per year and disconnect when you do

What to Expect

Your first 30 days: You will spend the first month in deep context-absorption mode -- shadowing customer calls with sales and customer success, reviewing the existing roadmap and the reasoning behind it, meeting your engineering and design partners, and reading everything written about the product in the last 12 months. You will not be expected to produce a roadmap yet; you will be expected to ask sharp questions.

Your first 90 days: By the end of month three, you will have delivered your first product initiative and shared a revised roadmap for the next two quarters with the Head of Product and the leadership team. You will have run at least five customer discovery interviews independently and have a point of view on the two or three areas of the product that most need attention.

At 12 months: You own the analytics roadmap with confidence, the team ships with predictability, and customers can describe specific ways the analytics product has improved in the last year. You are the person in the building who knows the most about what our analytics customers need next.

Growth trajectory: This role can grow into a Group Product Manager position overseeing multiple product areas, or into a Head of Product track as the team expands. We promote from within where the capability and scope are both present -- we will be explicit with you about what that path requires.

Our Team

Product at our company operates in two-week sprints with asynchronous planning documentation and synchronous refinement sessions. We write architecture decision records before major technical bets and post-mortems after anything that did not go as planned -- without naming blame. The Head of Product reviews all roadmap documents and gives written feedback before final prioritization decisions, which keeps alignment high without requiring daily meetings.

How to Apply

Apply through our careers portal at [link]. We ask for a resume and a brief written response (200-400 words) to the prompt: "Describe a product decision you made that you later realized was wrong. What happened, and what did you learn?" No cover letter is required. We review applications on a rolling basis and aim to respond to all candidates within 10 business days. The interview process includes an initial recruiter screen, a hiring manager conversation, a work sample exercise (shared 48 hours in advance), and a final panel with product, engineering, and a member of the leadership team.

We are committed to an inclusive hiring process. If you require accommodations at any stage, please contact hiring@[company].com and we will make arrangements promptly.

We encourage you to apply even if you do not meet every requirement listed here. Research consistently shows that qualified candidates -- especially women and candidates from underrepresented groups -- apply only when they feel they meet nearly 100% of the criteria. If this role excites you and you bring most of what we are looking for, we want to hear from you.