How to Validate an HR Tech Idea Without an HR Background

You don't need to have run payroll or sat in an HRBP seat to build credible HR software — you need borrowed domain depth, acquired on purpose through structured practitioner research. Pick one narrow HR workflow, interview ten people who do that work today, shadow it in practice, recruit one of them as a design partner, and prove it with a paid pilot before you write feature code.

Quick Answer: Don't try to out-know HR practitioners — out-listen them. Narrow to one specific workflow (onboarding, leave administration, performance calibration — never "HR" as a category), interview ten people who own that workflow, watch it happen instead of just asking about it, turn your best interviewee into a design partner, and validate demand with a paid pilot before you design a single screen.

Prerequisites: A Specific HR Workflow, Not "HR" Broadly

Settle on one workflow before you do anything else, because every step below depends on it. "HR" isn't a market — it's a department that owns a dozen distinct workflows, each with its own buyer, its own software category, its own compliance surface, and its own definition of "working." Building for "HR" means you can't tell anyone what your product does in one sentence, and you can't tell whether an interview went well because you have no fixed workflow to measure it against.

• Name the workflow, not the department. "Onboarding paperwork for hourly retail workers," "leave-of-absence tracking for a mid-market manufacturer," and "performance-review calibration across a distributed engineering org" are workflows. "HR software" is a category page on a review site.
• Name the buyer separately from the user. In most HR workflows the person who feels the pain daily — a line manager, a new hire, a recruiter — is not the person who signs the contract. Know both before you interview anyone, because a great user-facing product can still fail to sell if the actual buyer never shows up in your research.
• Know roughly where the workflow sits on the compliance spectrum. Payroll, benefits administration, and anything touching protected leave or immigration status carry real regulatory weight. Internal communication tools and recognition platforms carry almost none. You don't need expertise yet — you need an honest guess at which end of that spectrum you're building toward, because it changes how much of the research below is mandatory rather than optional.

The complete guide to validating an HR tech startup idea covers the full stakeholder map — buyer, user, and the IT function that often blocks integration — and everything below assumes you've read at least that much. What follows is the specific playbook for closing the domain-knowledge gap when you didn't grow up inside the function.

Step 1: Map the Workflow in Public, Then Let Practitioners Correct It

Draw the workflow you're targeting — every step, every handoff, every system it touches — using only what you can find in public sources, and treat the result as a hypothesis to be corrected, not a spec to defend.

Start with vendor documentation, help-center articles from the two or three incumbent tools in the space, job postings for the roles that own the workflow, and any public conference talks or webinars practitioners have given about it. Sketch the steps as you understand them: who initiates the workflow, what triggers it, which systems and people touch it in sequence, and where it typically breaks down according to what you can find. This map will be wrong in specific, useful ways — that's the point. Practitioners correct a wrong map far faster and more precisely than they answer an open-ended "tell me about your job" question, because a wrong map gives them something concrete to react to.

Bring this map, drawn or written out, into every conversation in the next step. Ask each practitioner to mark what's missing, what's out of order, and what you got flatly wrong. You'll walk out of the first two or three interviews with a map that barely resembles your draft — which is exactly the signal that you started from an outsider's guess and are converging on how the workflow actually runs.

Step 2: Recruit Ten Practitioners Who Actually Do the Workflow

Talk to ten people who touch the workflow directly, spread across the different roles that see it from a different angle — not ten people who share the same job title, which only tells you one perspective ten times.

The table below breaks down which roles to include and why each one sees something the others miss.

Recruiting ten strangers is the harder half of this step, and it's a separate skill from running the interview itself — where to find HR leaders to interview covers the specific communities, LinkedIn approaches, and outreach scripts that get a busy HR professional to say yes to a call with someone they've never met. Once you're in the room, run every one of these conversations on Rob Fitzpatrick's discipline from The Mom Test: ask about specific things that already happened, never about a hypothetical future feature. "Walk me through the last time this workflow broke down" produces evidence. "Would you use a tool that automated this?" produces politeness.

Step 3: Shadow the Process Instead of Only Asking About It

Watch the workflow happen in real time, over someone's shoulder, at least once — because what a practitioner describes from memory and what they actually do under time pressure are reliably different, and the gap between them is where most of your product opportunity lives.

People are bad narrators of their own habitual work, not out of dishonesty but because expertise compresses into intuition — the workarounds, the extra screens they check, the double-verification they've built out of one bad experience three years ago become invisible to the person doing them. A shadowing session, even a short one over screen-share, surfaces the click-throughs, the spreadsheet-on-the-side, and the "oh, I always check this other system first" moments an interview alone never produces.

Ask for thirty to sixty minutes to watch someone execute the workflow start to finish, or as much of it as fits in one sitting. Say almost nothing while it happens — note every extra step, every tool switch, every moment of visible hesitation, and save your questions for afterward. Two or three shadowing sessions on top of your ten interviews will do more to correct your workflow map than the next five interviews would.

Step 4: Find a Design Partner Inside the Function

Turn your strongest interview relationship into an ongoing design partner — someone who agrees to review mockups, react to prototypes, and tell you honestly when a direction is wrong, in exchange for early input into a tool built around their actual problem.

Not every practitioner you talk to will make a good design partner, and you're not looking for the most enthusiastic person in your interview pool. You're looking for someone who was specific and critical in the first conversation — who corrected your workflow map with detail rather than vague encouragement, who has clear opinions about what's wrong with their current tools, and who has enough standing in their organization that their reaction is a reasonable proxy for how a broader buyer population will react.

Arvid Kahl's The Embedded Entrepreneur is built around exactly this move: instead of building in isolation and hoping a market shows up, you embed yourself inside the community you're building for until one of its members becomes a genuine collaborator, not just a research subject. A design partner relationship is that embedding made concrete — a standing thirty-minute call every two weeks, a shared document they annotate, a Slack channel where they flag what's broken about your latest mock. That relationship is worth more than any amount of secondhand research, because it's live, ongoing, and self-correcting.

Step 5: Run a Paid Pilot Before You Build the Full Product

Ask your design partner's organization, or another org from your interview pool, to pay something — even a small amount — for an early, narrow version of the workflow tool, before you invest in the full build.

A paid pilot doesn't need to be the finished product. It can be a manual, concierge version of the workflow you're automating, delivered by you personally through spreadsheets and email for the first few weeks, priced honestly for the value it delivers even if the delivery mechanism is embarrassingly manual behind the scenes. What you're testing isn't whether the software works — you haven't built it yet — it's whether an organization that touches this workflow every day will commit real budget to solving the problem you think you understand. A free pilot tells you people are willing to try something. A paid one tells you they believe it's worth solving, which is the number that actually predicts a business.

Treat any resistance to paying, especially from your design partner's own organization, as data rather than an obstacle to negotiate around. If the person who corrected your workflow map in detail and reviewed three rounds of mockups still won't attach a budget number to a pilot, that's a stronger signal about market readiness than another glowing interview would be.

Worked Example: An Engineer Validating an Onboarding Tool

Consider a backend engineer, ten years into a software career and zero years in HR, who keeps hearing the same complaint from a friend who runs people operations at a mid-size retail chain: new-hire paperwork takes too long and too many hires fall through the cracks in their first two weeks.

Following Step 1, the engineer spends a weekend mapping "hourly retail onboarding" from public sources — a few HR blog posts, two competitor help centers, and a handful of job postings for "onboarding coordinator" roles that describe the tasks in detail. The draft map has six steps, starting with an offer letter and ending with a first shift. It's a reasonable first guess and, as it turns out, wrong in three places once real practitioners see it.

For Step 2, the engineer recruits ten people: three HRBPs at different retail chains, two onboarding coordinators, two store-level managers who actually walk a new hire through their first shift, an HRIS administrator who manages the applicant-tracking system, and an employment-law generalist who flags a compliance step the engineer's map missed entirely — I-9 verification timing, which turns out to be the single most litigated part of the whole process. That interview alone reshapes the product's priority list before a line of code exists.

In Step 3, the engineer shadows one HRBP for forty-five minutes processing three new hires in the applicant-tracking system and watches her switch between four different tools — the ATS, a shared drive of PDF forms, a text-message thread with the store manager, and a personal spreadsheet she built to track who still owes paperwork. None of that spreadsheet workaround showed up in any interview; it only surfaced by watching.

For Step 4, the engineer asks that same HRBP to become a design partner, and she agrees, in part because the shadowing session made clear the engineer was paying real attention to her actual day rather than pitching a product at her. Over six weeks of biweekly calls, three rounds of mockups get reduced to one core screen: a single dashboard replacing her four-tool juggling act with a real-time view of who's missing what.

By Step 5, the engineer proposes a four-week paid pilot to that HRBP's regional director — a manual, concierge version of the dashboard built as a shared spreadsheet with automated reminder emails bolted on through a simple script, priced at a modest flat monthly fee. The regional director says yes. That single "yes, and here's a purchase order" is worth more than the ten unpaid interviews combined, because it's the first piece of evidence that anyone outside the engineer's own network will actually fund the problem getting solved.

Two Mistakes That Sink Outsider HR Tech Founders

Building From Job-Ad Keywords Instead of Workflows

Scraping HR job postings for recurring phrases — "streamline onboarding," "reduce time-to-hire," "improve employee experience" — and treating those phrases as validated feature requirements is one of the fastest ways an outsider founder builds the wrong product. Job postings describe what a company wants a hire to be responsible for in the abstract; they don't describe the specific, situational friction that HRBP actually fights every week. A phrase like "improve employee experience" could mean twenty different underlying problems depending on the company, and none of them are visible from the outside.

Job-ad language is a decent source of vocabulary for your outreach messages — it tells you how the function talks about itself — but it is not a substitute for Step 1's workflow map or Step 2's interviews. Treat it as a starting hypothesis to bring into a real conversation, never as a requirements document you build straight from.

Skipping the Compliance Review Because You're "Just Building Software"

Assuming compliance is someone else's problem, or something to figure out after the product proves demand, is a mistake that gets more expensive the longer it's deferred — because HR software frequently touches protected leave, wage-and-hour law, immigration verification, or data covered by state and federal employment regulation, and a product architecture built without that constraint in mind is often expensive to retrofit.

You don't need a law degree before you validate an idea, but you do need an honest answer, gathered directly from the employment counsel or compliance lead in your Step 2 interview pool, about which parts of your target workflow are legally load-bearing. Skip that conversation and you risk designing a product around the wrong assumption of what's optional — discovering only after a pilot, or worse after a launch, that a "nice to have" feature was actually the one thing standing between your buyer's organization and a compliance violation.

Key Takeaways

• Narrow to a workflow, not a department. "HR" isn't buildable; "leave-of-absence tracking for a manufacturer" is — pick the workflow before you do anything else.
• Recruit across roles, not within one title. An HRBP, a recruiter, an HRIS admin, a compliance lead, and a line manager each see a different slice of the same workflow.
• Ask about the past, following The Mom Test discipline. What someone did last week is evidence; what they'd theoretically use is politeness.
• Shadowing catches what interviews can't. Practitioners compress expertise into invisible habit — watching the work surfaces the workaround-spreadsheet nobody mentions out loud.
• One design partner is worth more than ten passive interviewees. The Embedded Entrepreneur model of embedding inside a community turns research subjects into an ongoing, self-correcting collaboration.
• A paid pilot is the real test, not a free one. Willingness to attach a budget number tells you something enthusiasm never will.
• Compliance isn't a later problem. Learn the legal floor of your workflow from a real compliance practitioner before you architect around the wrong assumption of what's optional.

Frequently Asked Questions

Do I need HR experience to start an HR tech startup?

No. Plenty of successful HR tech founders came from engineering, sales, or an adjacent operations role rather than an HR career. What you need instead is a structured way to borrow domain depth — narrow workflow, direct practitioner interviews, shadowing, and a design partner — done deliberately rather than assumed away.

How many HR practitioners should I interview before building anything?

Ten across the roles that touch your target workflow from different angles is a reasonable floor before you commit to building, following customer research fundamentals for pre-product founders: enough to see a pattern repeat rather than chase a single loud opinion. Keep going past ten if you're still hearing genuinely new information; stop deferring the build once the same frustrations start repeating.

What's the difference between an HR practitioner and an HR buyer I should talk to?

A practitioner is whoever actually executes the workflow day to day — an HRBP, a recruiter, a line manager — while the buyer is whoever signs off on the purchase, often a director or VP one or two levels above the practitioner. Both matter: the practitioner tells you whether the product solves a real daily problem, and the buyer tells you whether solving it is worth budget. Skipping either one leaves a gap in your validation.

Can I validate an HR tech idea without paying practitioners for their time?

Yes, for the interview and shadowing stages — most HR practitioners will give thirty to sixty minutes to a founder who's specific, respectful of their time, and genuinely building for their problem, without payment. Once you move to a design partnership or a pilot, be ready to offer something of real value in return: early access, a say in the product direction, or in the pilot's case, an honest price that reflects what the solution is actually worth to their organization.