This is such a great thread! I've definitely been there with the kitchen-sink approach - it's so tempting to list everything when you're trying to be thorough. What's been a game-changer for me is actually creating three distinct buckets: non-negotiables (like that teaching certification!), strong preferences, and nice-to-haves. I literally sit down with hiring managers now and force them to pick their top 3 must-haves, then everything else gets categorized. The "what would make them fail in 90 days" question is brilliant - I'm stealing that! I've also started looking at our past successful hires to see what they actually had versus what we thought we needed. Sometimes we're way off base about what really matters day-to-day. It's definitely made our job postings clearer and honestly saved me from some pretty awkward conversations with candidates who thought they were qualified when they weren't even close to meeting the legal requirements.
This is such a common pain point, and honestly, it took me a while to get better at this too. The scenario planning approach mentioned above is spot-on - that "what would make them fail in the first 90 days" question is brilliant because it forces you to think about actual job performance rather than ideal candidate profiles.
What I've found works well is creating a three-tier framework with hiring managers during our intake meetings. We start with legal/regulatory requirements (like your teaching certification example) - these are absolute non-negotiables that we literally cannot work around. Then we move to functional requirements - the skills and experience needed to actually do the core job successfully from day one. Finally, we identify enhancement factors - things that would make someone excel or grow faster in the role.
The key insight I've gained over the past couple of years is that most hiring managers haven't really thought through this distinction either. They often come to me with a laundry list of everything they'd love in a perfect world, but they haven't considered the practical trade-offs. So I've started asking more pointed questions: "If we had to choose between someone with 5 years of classroom management experience but limited tech skills versus someone who's tech-savvy but only has 2 years of teaching experience, which way would you lean?" These hypothetical scenarios help clarify priorities really quickly.
One thing that's been eye-opening since we started using Talantly is seeing the data on how different requirement structures affect applicant quality and volume. When we had those kitchen-sink descriptions, we were getting tons of applications from people who met maybe 60% of the listed requirements, which created a lot of noise in the screening process. Now that we're more intentional about how we structure and prioritize requirements, we're seeing better alignment between what we post and what we actually receive.
The other piece that's been crucial is getting hiring managers to rank requirements by impact on job success, not just by what sounds impressive. For teaching roles specifically, I've learned that things like classroom management skills and curriculum development experience often matter more than the latest EdTech certifications, even though the tech stuff is easier to measure and list.
Have you tried doing a post-mortem on your recent hires to see which requirements actually predicted success? That data can be really powerful when you're having these prioritization conversations with hiring managers.
That's such a smart reframe! The "what would make them fail" question is brilliant because it forces you to think about actual job performance rather than ideal candidate profiles. I've been wrestling with similar prioritization issues since we started using more structured approaches - the data actually showed me how my scattered requirements were creating these weird filtering effects where we'd miss great candidates or attract completely wrong fits. One thing that's helped me is literally mapping requirements to specific job tasks, like "needs state certification to legally teach" versus "knows Google Classroom to save training time." It sounds obvious when you say it out loud, but when you're writing the JD, it's easy to just dump everything into one bucket. The scenario planning approach you mentioned is gold though - I'm definitely stealing that for my next hiring manager meeting!
This hits close to home - I've definitely been on the other side of this equation as someone who's had to work with hiring managers who struggle with this exact prioritization challenge. From my experience in consulting, I've found that the root issue is usually that hiring managers (and sometimes talent coordinators) haven't really thought through what the role actually *does* day-to-day versus what they think it *should* do.
What's worked well for me is borrowing a framework we use in client work - essentially creating a "critical path" for the role. I'll sit down with the hiring manager and map out the first 6 months: what are the 3-4 things this person absolutely must accomplish to be considered successful? Then we work backwards from there. If they need to lead client presentations by month 3, then presentation skills become non-negotiable. If they're not touching clients until month 6, maybe that's a nice-to-have.
The "failure question" approach the previous commenter mentioned is brilliant - I'm definitely stealing that one. I usually ask something similar: "If this person bombed in their first quarter, what would be the most likely reason?" Nine times out of ten, it's not because they couldn't use the latest project management software or didn't have experience with a specific methodology. It's usually something more fundamental - they can't handle ambiguity, they struggle with difficult conversations, or they can't prioritize competing demands.
One thing I've learned the hard way is that hiring managers often conflate "this would make my life easier" with "this is essential for the role." A manager might say "experience with our CRM system is critical" when what they really mean is "I don't want to spend time training someone on it." That's a legitimate concern, but it's a training issue, not a role requirement.
The challenge I still run into sometimes is when you have senior stakeholders who want to add their pet requirements to the mix. I've had partners insist that candidates need specific industry experience when the role is actually much more about general consulting skills. In those cases, I try to get them to commit to trade-offs: "If industry experience is truly non-negotiable, are you willing to compromise on analytical skills or communication ability?" That usually helps clarify their actual priorities pretty quickly.
Since you mentioned Talantly
The 90-day failure question is brilliant - I'm definitely stealing that one. In my experience with business unit hiring, I've found that having separate conversations with the hiring manager about "what kills productivity immediately" versus "what accelerates performance" helps create that natural hierarchy. The tricky part is when you're hiring across different regions where the same role might have genuinely different priorities, but starting with those core failure points usually gives you a solid foundation to build from.
This is such a relatable struggle! I've definitely been there with the kitchen-sink approach to job descriptions. What's been eye-opening for me lately is actually mapping out the hiring funnel backwards - starting with "what does success look like in month 3, 6, 12?" and then working backwards to figure out what's absolutely critical versus what can be trained. I've found that when I sit with hiring managers, they often confuse "things that would be awesome" with "things we literally cannot function without." The 90-day failure question is brilliant - I'm totally stealing that! It's funny how these seemingly small changes in how we frame requirements can completely shift the candidate pool. Still figuring out the perfect balance myself, but at least now I'm asking better questions upfront instead of trying to fix it after we've already confused half our applicant pool.
That's a brilliant reframing question - I'm definitely stealing that approach for our next hiring manager calibration sessions. We've been wrestling with similar prioritization challenges as we scale our engineering teams, and I've found that getting hiring managers to think about failure modes rather than just success criteria cuts through the wishlist mentality really effectively. The other thing that's helped us is actually tracking which "nice-to-have" requirements we consistently waive during the interview process - that data usually reveals what we're actually willing to compromise on versus what truly blocks someone from being successful. It's taken some trial and error, but having those clearer distinctions has definitely sped up our screening process and reduced candidate confusion.
Yeah, that "what would make them fail" question is solid - I've started using something similar when screening candidates for clients. It's way easier to spot the actual must-haves when you flip it around like that instead of getting lost in the nice-to-have wishlist stuff.
This is such a common struggle! I've found that creating a simple three-bucket system really helps - "must-have" (legal requirements, core skills), "should-have" (things that make the job easier but can be learned), and "nice-to-have" (bonus skills). The 90-day failure question is brilliant - I'm definitely stealing that! What's also worked for me is involving the actual team members who'll work with the new hire, not just the hiring manager. They often have the most realistic perspective on what actually matters day-to-day versus what sounds good on paper. I learned this the hard way when we hired someone who checked all the boxes but couldn't handle our specific parent communication style - something the veteran teachers would have flagged immediately if I'd asked them upfront.
Yeah, that "90-day failure" question is gold - I use a similar approach where I ask clients what would make them regret the hire after three months. Usually separates the legal requirements and core competencies from the "wouldn't it be nice if..." stuff pretty fast.
This is such a relatable struggle! I've definitely been there with the kitchen-sink approach to job descriptions. What's been helping me lately is actually mapping out requirements in three clear buckets before I even start writing: absolute must-haves (like that teaching certification!), strong preferences, and nice-to-haves. I've started doing a quick 15-minute chat with hiring managers where I literally ask "if someone doesn't have X, would we still interview them?" for each requirement. It sounds simple, but it's amazing how often the answer surprises both of us. The "what would make them fail in 90 days" question is brilliant too - I'm definitely stealing that one! It's been a learning curve for sure, but I'm finding that being more intentional upfront saves so much time on the backend when you're not sifting through applications from people who are missing the actual deal-breakers.
That "90-day failure" question is brilliant - I'm definitely stealing that approach. From my experience scaling engineering teams, I've found that the most critical distinction is between skills that can be taught quickly versus those that are foundational to the role. For teaching positions, state certification is obviously non-negotiable, but tech proficiency can usually be developed with some basic training. What's helped me recently is creating a simple three-tier system: absolute requirements, strong preferences, and nice-to-haves - then being ruthless about keeping that first tier to maybe 3-4 items max.
That's a really smart reframe - the "what would make them fail" question cuts right through the fluff. I've found that hiring managers suddenly get very clear about priorities when they think about their worst-case scenarios instead of their wish lists.
This is such a common challenge, and honestly, you're not alone in learning this the hard way! I've been on the other side of this as someone who's had to untangle similar messes when working with clients on their talent strategies.
From my consulting background, I've seen this pattern play out repeatedly across different industries - not just education. The root issue is usually that we're trying to solve for too many things at once without a clear hierarchy. What I've found works well is borrowing from how we structure client requirements in consulting projects.
I typically recommend a three-tier approach that I walk hiring managers through: **Critical** (role cannot function without this), **Important** (significantly impacts performance but can be developed), and **Preferred** (nice-to-have that might differentiate candidates). The key is being ruthless about that first category - if you can't immediately explain why something would make someone fail in the role within 6 months, it probably doesn't belong there.
The question about what would make someone fail in the first 90 days is brilliant, by the way. I use a variation of that - I ask hiring managers to describe their worst hire in that role and what went wrong. Usually, it wasn't because someone lacked a "nice-to-have" skill; it was because they were missing something fundamental.
One thing that's helped me lately is actually mapping requirements against real performance data when possible. Since we started using some of the newer AI-powered tools for talent analysis, I can sometimes validate whether certain requirements actually correlate with success in similar roles. Though I'll be honest - the customization options in some of these platforms can be limiting when you're trying to get really specific about role requirements. Sometimes the categories they offer don't quite match how you'd naturally think about prioritizing qualifications.
The scenario planning approach mentioned earlier is spot-on too. I often have hiring managers walk through: "Candidate A has the teaching certification but minimal tech skills" versus "Candidate B is a tech wizard but needs to complete certification." Which one do you interview first? That usually clarifies priorities pretty quickly.
Have you tried doing a post-mortem on your successful hires in similar roles? Sometimes looking backward at what actually made people successful can be more revealing than trying to predict forward.
That's a really smart approach - the "what would make them fail" question is brilliant for cutting through the noise. In manufacturing, I've found that breaking requirements into true deal-breakers versus development opportunities has been crucial, especially since we often have roles where safety certifications are non-negotiable but other skills can be trained. The challenge I'm still working through is getting hiring managers to be honest about what they're actually willing to compromise on versus what they just think sounds good on paper.