How to test a hiring product with one employer

A hiring-product pilot should answer a specific question about a real piece of work. An employer agreeing to try software is useful, but access alone does not establish what the founder will learn. Start with the workflow the employer wants to improve, the people who operate it and the decision both sides will make when the pilot ends. That gives a small test a purpose beyond collecting logins.

The following four-week structure is a proposed pilot plan for a founder building a coordination tool under Jobry. Its example is arranging interviews for one hourly role at one location. The same approach can be adapted to another bounded workflow. The employer remains responsible for its hiring decisions and policies, while the founder studies the agreed coordination task.

Agree the question before the feature list

A good starting question is narrow enough to observe: can the team arrange interviews with fewer repeated messages while keeping the status clear to staff and applicants? That question identifies work, rather than a general ambition to improve hiring. It also makes the founder specify what the product does. In this example, it supports the exchange of availability and the handoff between two managers.

Write a one-page pilot agreement covering the role, location, participating staff, dates, support contact and scope. State which existing process remains authoritative if the new tool fails. Agree how personal information will be handled, who can access it and what happens to pilot records afterward. Appropriate legal and security review should happen before real applicant information enters a new system.

Week one: observe the current workflow

Ask a manager to walk through a recent interview arrangement. Follow the work across the actual tools and conversations used. Note when an application became ready for contact, when someone offered an interview and how the final time reached the interviewer. Include the small follow-ups that rarely appear in a process chart. Those steps often explain why the task feels more difficult than the official workflow suggests.

The Nielsen Norman Group's service-blueprinting method recommends using direct evidence such as employee accounts and observation of work. For this pilot, a compact map can show applicant actions, manager actions and the systems supporting them. Use the map to agree where the test starts and ends, so the baseline describes the same work the product will later support.

Choose a baseline with context

Measure a small set of observable events. The team might record the time from ready-to-contact to a confirmed interview, the number of messages needed and the number of times a colleague had to ask for the latest status. Keep definitions stable. An interview offered is different from an interview confirmed, and a cancelled vacancy should not quietly disappear from the record.

Discuss what else affects the result. A manager may be away, an applicant may request a later date or the role may have an unusual schedule. Record those circumstances alongside the numbers. The aim is to understand the workflow, so a handful of observations with clear context can be more useful than a large total whose meaning nobody can explain.

Week two: test the smallest working path

Build the part needed for the agreed task. For the example pilot, that may be an availability request, a manager view and a visible interview status. Test it with staff using representative scenarios before involving applicants. Ask participants to complete the task while explaining what they expect. Watch where a label suggests a different state from the one the system actually records.

Nielsen Norman Group's service-blueprinting FAQ recommends starting with a small group and a small scope when applying the method. That fits a first employer pilot. A founder can learn from one manager team without adding every possible role, location and exception to the first release. Resolve the basic handoff before broadening the test.

Use a visible manual service layer

Some work may happen manually during an early pilot. A founder might check an unanswered invitation or help a manager correct a status. Be explicit about that support and record when it occurs. Otherwise the product can appear to work independently while a person quietly repairs the process behind it. The team needs to understand both the user experience and the effort required to deliver it.

Keep a support log with the event, the action taken and the reason it was needed. Separate a confusing screen from a missing feature and an employer policy question. These lead to different changes. A policy question may need the employer's decision, while an unclear status label can be tested in the interface. The founder should leave the week knowing which kind of work each problem created.

Week three: run the bounded workflow

Use the tool for the agreed role and staff group. Keep the previous process available as the fallback defined at the start. Check in at a scheduled time instead of interrupting every task. Ask managers to flag confusion when it occurs, then review the specific example together. A screenshot without the surrounding task can be misleading, so capture enough context to understand what the person was trying to do.

Continue the same measurements used for the baseline. Track manual assistance as well, since a faster confirmation that requires constant founder intervention may suggest another service model. Look at exceptions rather than averaging them away. A single applicant unable to respond through the chosen channel can reveal an important gap in the design.

Week four: make the decision together

Review the workflow map, observations, measures and support log with the employer. Ask staff to demonstrate what they can now do and what remains difficult. Compare the same start and end points with the baseline. Treat the results as evidence from this pilot, including its limited scope and the circumstances that affected it. The discussion should end with a decision about the next version.

Agree the decision criteria before interpreting the result. Continuing might require managers to use the status view independently, applicants to receive accurate arrangements and support effort to fit the service the founder intends to run. Revising might mean narrowing the task further. Stopping can also be useful if the observed problem does not justify a separate product. Each outcome should lead to a specific action.

Leave the employer with a clear handoff

At the end, confirm which workflow will operate next, who owns any remaining tasks and how the pilot data will be handled. Thank staff for their time and share the changes their examples informed. A pilot relationship is easier to continue when the founder closes the loop on what was learned and what happens to the tool people have been using.

Jobry can be the name on the first demonstration and the next employer conversation. The pilot supplies the evidence behind that introduction: a defined task, a baseline, a working test and an honest decision. The first step is to agree one measurable workflow with one employer and put the review date on the calendar.