Getting a SpringVerify account to make its first hire in Goodfit — without asking them to build a second hiring tool.

Goodfit already sits inside SpringVerify. The problem isn't discovery — it's asking someone doing a compliance job to start a hiring job from scratch.

SpringworksSpringVerifyGoodfitIntegrations

Who I'm building for

HR Ops runs the verification queue. They don't open the roles.
Their day, in order: someone gets hired → they open SpringVerify → they send the form → they chase documents → they read the report.
What they want: fewer people to chase. Fewer surprises after the offer.
What they cannot do: post a job. They don't own the role, so anything starting with "create a job" gets ignored.
So the pitch can't be "hire better." It has to be about the work they already have.
This is my read of the product, not customer research. Next step: three customer calls in week one to confirm or kill it.

The problem

It asks them to build a second hiring tool. They already have one.
Three entry points, three empty states, one shared cause.
Jobs page: "No jobs found. Create your first job." Sets the ceiling on all of this.
Overview: Four counters at zero, three empty panels. Tells us who's even a buyer.
Getting started: Three setup steps before anything happens. Tells us if it's a finding problem or a value problem.
Every empty box here is already full in the tool they hire with. Filling it in means typing the same thing twice.
Three numbers I'd ask for in week one: how many accounts have a hiring tool connected, how many verify because they hire (not to re-check staff), and how many have ever posted a job on Goodfit.

Options I considered

Four ways in. Three I worked out properly before dropping them.
A. Wait for a check to fail: A report comes back wrong. Offer to screen earlier next time.
B. Assess people after they join: A new joiner or a leaver. Run a Goodfit test in that window.
C. Ask new joiners for referrals: They refer people for roles like their own.
D. Pull in their hiring tool (chosen): Read the open roles and applicants from the system they already run.
Why the other three lose is the next slide — that reasoning matters more than the answer.

Why A, B and C lose

A was my first idea. It's wrong for a reason that only shows up once you know how BGV runs in India.
A, wrong moment: In India the check runs after the person has joined. A bad report rarely undoes the hire — there's no pain to attach the pitch to.
B, wrong product: Goodfit is built to hire people. Testing people who already work there bends it to fit a moment we happen to have.
C, wrong messenger: A verification company asking a new joiner to refer friends is odd — and it isn't HR's call to make.
D, why D wins: One customer. One hiring tool. Already connected — the role and the people are sitting in it. The only option where the trigger is a fact, not a guess.
And why not their ATS's own screening? Most Indian ATSs stop at collecting applications, and none of them can start the background check when someone is hired. That join is ours to own.

The journey, today and after

Same person, same week. The difference is where Goodfit sits.
Today: Role opens in ATS → Screens by hand → Picks & hires → Opens SpringVerify → Starts check by hand. Goodfit never appears anywhere on this line. The dashboard card sits beside the work, not in it.
After the sync: Role opens in ATS (same as today) → Shows up in SpringVerify (nobody creates a job) → Applicants arrive (nobody uploads a list) → Screens in Goodfit (interview already built) → Hired, check starts (no form to fill).
Four steps become one line. The last box is the payback: they finish a verification without ever filling in a form.
Only the first box is unchanged. Everything after it is work we take off them.

How the data moves

One read, one write back, one event. Nothing new for them to maintain.
Their ATS: the role and the applicants live here → SpringVerify reads it through Integrations, creates the job, pulls people in → Goodfit: job and candidates appear, ready to screen.
The check starts on its own. No second form. They mark the person hired in their ATS, and that event triggers the background check in SpringVerify — automatically.
The ranked shortlist goes back into their ATS. Nobody has to move to a new place to work — Goodfit writes the result back to where they already are.
The whole thing rests on the first arrow. If Integrations can only send results back and cannot read open roles, this needs a different source.

Wireframes

Same screens. Different content. Every element already exists.
SpringVerify dashboard: Hiring work becomes a task in the queue, not an ad beside it.
Goodfit › Jobs: Opens with their real roles instead of an empty page.
Goodfit › Overview: Counters show what is waiting on them, not what they haven't done.
I changed what fills these screens, not how they look. So it ships without a design cycle.

What we read, and what happens when it isn't there

Most accounts will be missing something on day one. That's the real design problem.
Fields we read: the open role and when it opened; how many people have applied; the applicants' names and contact; past applicants, into the talent pool.
When they're missing — no hiring tool connected: use job titles from past checks. A tool we don't support: add the role by hand. New role, nobody applied yet: screen from the talent pool. Data crossing two products: needs consent under DPDP.
If the integrations can only send results back and cannot read open roles, this needs a different source.
Which is why it's the first thing I'd check, and not the first thing I'd build.

How I'd know it worked

My claim: setup is the blocker, not interest. Here's how that gets proved or killed.
The number to watch: accounts that pay for their first assessment. Not sign-ins. Not free credits. The only one that means someone chose it.
The early sign: connected accounts that start a role on the first visit. Tells us in days whether removing the setup was the right fix.
The line not to cross: check turnaround and satisfaction must not slip. SpringVerify is bought on trust. If this costs trust, it stops.
How I'd know I was wrong: connected accounts start roles at the same rate as everyone else. Then setup was never the blocker, and the next conversation is about the product itself.

Order

Ordered by what depends on what, not by size.
First: Connect the hiring tool. Roles and applicants come across. Jobs page has something in it. The blocker — everything else depends on this.
Then: A task on the dashboard, "Add people to screen." Counters filled in. Only works after the first step. A counter at zero is worse than no counter.
Later: Check starts on hire. Careers page on by default. One balance across both products. Needs accounts that have actually hired through it first.
If I had to cut, I'd cut all of "Later." It's the part I'd most enjoy building, and none of it proves the idea works.

What I'd check first

Five questions. None of them need engineering time.
1. Can the integrations read open roles, or only send results back? Kills the first step. (Week 1)
2. How many accounts have a hiring tool connected at all? Sets the ceiling — could shrink this a lot. (Week 1)
3. Does HR own the role, or must they forward it to someone? Changes the main button on every screen. (Week 1)
4. Can applicant data move between the two products legally? Limits what we can pull. DPDP. (Week 2)
5. Do ready-made interviews per job title exist, or is that a build? Adds scope — step three of Goodfit's own setup today. (Week 2)
All five are answerable in two weeks of asking, before anyone writes code.

Want to discuss this in person?

Send me a note about what you read here and I'll get back to you myself.