Writing Job Descriptions That Attract the Right People (Not Just Any People)

Most job descriptions are written by the wrong person, for the wrong reason, using the wrong template.

The hiring manager copies last year's JD, adds three new bullet points, inflates the experience requirement by two years "just to be safe," and sends it to the recruiter to post. The recruiter posts it. A hundred people apply. Eighty of them have no business applying. Fifteen could actually do the job. Five are genuinely great fits.

The interesting question is: why did the five great fits apply at all, despite the JD being unclear about what the job actually involves?

The answer, usually, is that they recognized the company name or heard about the role from someone. They applied in spite of the JD, not because of it.

That's the opportunity. A well-written JD can pull more of the right candidates into your funnel before word of mouth does the work for you.

The Core Problem: Requirements Instead of Outcomes

The standard JD structure is: role summary → responsibilities (bullet list) → requirements (bullet list). The responsibilities section tells people what they'll be doing. The requirements section tells people what they need to have done.

Neither section tells a candidate what they'll actually accomplish.

Consider the difference:

Standard: "Manage enterprise customer relationships and ensure high retention rates."

Outcome-focused: "Own a portfolio of 30-40 enterprise accounts. Your goal in year one: get retention above 92% and expand three accounts by 20%+."

The first could describe anyone in any customer success role. The second tells you exactly what the job is, what success looks like, and whether you're the kind of person who would find that exciting. The right candidate reads that and thinks "I know how to do that." The wrong candidate reads it and self-selects out.

The best job description makes a great candidate think "this was written for me" — and makes an average candidate think "I'm not sure I'm ready for this."

The Experience Inflation Problem

"8-10 years of experience required" for a role that takes two years to learn is now standard in Indian tech hiring — particularly for engineering and product roles. This happens because hiring managers default to using experience as a proxy for capability, and because inflating requirements feels safer than defining what you actually need.

The result: you filter out candidates who could do the job on day one, while attracting experienced candidates who have coasted for years and check the box.

A Bangalore-based product team once posted a Senior Product Manager role requiring 7+ years of PM experience. After three months with no strong hires, they rewrote the JD with a 4+ year requirement and added two outcome statements: "You'll own our B2B onboarding funnel and reduce time-to-value from 45 days to under 20" and "You'll work directly with three enterprise clients to shape our roadmap." They hired within five weeks — a candidate with 5 years of experience who had done exactly this kind of work at a smaller company.

Rewriting the Requirements Section

Instead of listing credentials, list demonstrated capabilities. The shift is subtle but significant.

Before: "Strong analytical skills with experience in SQL and Excel."

After: "You can pull your own data. You're comfortable writing SQL queries to answer questions without waiting on a data analyst, and you can build a clean Excel model when you need to communicate a recommendation."

Before: "Excellent communication skills, written and verbal."

After: "You write clear emails. When something is complicated, you can explain it simply. You're comfortable presenting to customers or to a room of senior stakeholders."

The rewritten versions do two things: they give candidates a realistic self-assessment tool, and they signal that you care about actual work, not credential collection.

The "Why This Role" Section Most JDs Skip

Every JD should have a paragraph — not a bullet list — that explains why this role is interesting right now. What is the company working on that makes this position meaningful? What will this person be part of that they couldn't be part of elsewhere?

This is especially important for mid-career candidates who have options and are choosing between roles, not just applying to everything.

For a Series B startup: "We're moving from product-market fit to scale. This is the role that builds the infrastructure that makes that possible. You'll have genuine ownership and you'll see your work reflected in the P&L within 12 months."

For an MNC: "This team runs the India go-to-market for a product used by over 2 million people. It's a $50Mn revenue center and it's growing 40% year-over-year. You'll have real resources and a real mandate."

Neither paragraph is hype. Both are honest about what makes the role worth considering.

What to Cut

Most JDs are 30% longer than they need to be. Cut:

• Requirements that describe the job rather than the person ("must be able to work in a fast-paced environment")
• Soft skills listed as requirements ("strong team player," "proactive self-starter") — these are expectations, not differentiators
• Redundant bullet points that restate the same idea three different ways
• The company boilerplate at the top that nobody reads

A JD should be scannable in 90 seconds and complete in five minutes. If it takes longer than that, you've lost candidates who had better things to read.

The Test

Before publishing any JD, show it to one person who could be your ideal hire. Ask them three questions: Does this sound like a role you'd apply for? Does it tell you what you'd actually be working on? Does it give you a clear sense of what success looks like?

If the answer to any of those is no, you have more editing to do.

The best JDs get shared. Candidates forward them to peers, post them in Slack communities, mention them in conversations. That only happens when the role sounds genuinely interesting — and interesting starts with honest, specific, outcome-focused writing.

---