Business model, strategy, North Star
Referrers are the scarce side, so nothing is ever sold to them
Written after the research, from the problem statement.
Business model → strategy → design pressure
Business model
A two-sided marketplace
Candidates on one side, employees who refer on the other. Far more people ask than refer, so the referrer is the scarce side, and every business call protects them first. Worked it out
Strategy: quality as identity
Every request that reaches a referrer is complete and a real fit
The problem statement turned around: referrers drop requests that hand them the candidate's work (n76), and help when the candidate has done it (n77). What it costs: candidates do more before they ask, and can ask fewer people.
Design pressure this creates
Fewer, complete requests
A request can't be sent incomplete. Referrers see the best matches first. Candidates get a limited number of requests. The outcome travels back at almost no extra work.
Who pays
Phase 1 · Build both sides
Free for everyone
A paywall on an empty marketplace blocks the people it needs.
Phase 2 · Companies pay
For complete, matched referrals
Companies already pay for referrals through their bonus schemes (n62, n87). Guessing that they'd pay a platform.
Candidates, if ever
Only for tools that help them
Never to reach, see or jump ahead of a referrer.
Rejected ways to make money
Candidates pay to reach referrers
Version 2's Premium did this. It sells the scarce side's attention, and paying doesn't change a referrer's rule (n50, n76).
Referrers pay
They have the least reason to take part already (C4). Charging them kills supply.
Ads
Ads pay off when people spend more time in the app, and SideDoor is meant to get a referral done in minutes.
North Star
The value exchange
A candidate who fits gets referred by someone they didn't know, and that person didn't have to chase anything
A referral counts when either side confirms it went into the company's portal: the referrer marks it, or the candidate marks the company's email. Per referrer, not total, because the referrer is the scarce side and a total can rise from sign-ups alone.
| The North Star checklist | Answer |
|---|---|
| Can it rise while users are unhappy? | Partly: poor fits could be submitted. Watched by the guardrail |
| Can marketing inflate it? | No. It's per active referrer |
| Value, not activity? | Yes. A submission is when both sides get what they came for |
| Would a fall predict trouble? | Yes. Fewer referrals per referrer means referrers drifting away |
Looks like a North Star, isn't one
Requests sent
Rises when candidates spam, which is the problem SideDoor exists to fix.
Swipes and matches
Version 2's numbers. A match that never turns into a submission doesn't help either side.
Messages sent
Rises when details are still being chased, which means the product failed.
The bet, placed before any user contact
Five problems at once, then one moment and one guess
The first card is copied from the FigJam made before the interviews. The research kept one of its five problems.
Rewritten after the research: one moment, one guess
My mentor said: make it a LinkedIn feature. I kept it separate.
- The work sits between two systems nobody owns. It starts on LinkedIn and ends in the company's portal. LinkedIn can't see inside that portal either (n46, n57, n59, n60, n71)
- The referrer gets value before anyone else joins, from a link they send to strangers (n66)
- All four asked for a dedicated place as candidates (n24, n45, n113, n147), though a wish is weak evidence
"a link is sent to the candidate to fill out their own personal details, which would cut the referrer's effort by 50%"
Samarth, as a referrer · n66- All four ask and get asked on LinkedIn today (n04, n09, n29, n49, n68, n116, n138)
- Referral communities go quiet: on Fishbowl a message might be seen "next week" (n28)
- The cold start could fail: a referrer may not send a link, because sending it is already a yes
Guessing
Not in this project
- The company's referral bonus: no product controls it (n62, n87)
- Connecting to referral portals like Workday: no outside product has access (n46)
- Interviews and HR decisions after the referral (n86, n88)
- Candidates who take a referral and don't join (n89, n90)
- Recruiters: no data from them
What was collected
Four people, each interviewed twice: once asking, once being asked
All four have asked strangers for referrals and all four refer people at work, so each could speak for the other side too.
Samarth
Specialist Programmer, Infosys
Riya
Refers at Accenture
Akash
Senior backend developer, a finance startup
Atishya
Senior product manager, consumer tech
Sample and its bias, written before anyone asks
Everyone in this sample is one of four tech employees who already refer people, mostly people they know, which means I will not hear from employees who ignore referral requests, from recruiters, from people outside tech, or from candidates who have never asked a stranger.
Four people is still thin: where only one says it, the page says so.
Also collected
Screenshots of 11 products
LinkedIn, GetMeReferred, EasyRefer and Instahyre were read at full size (stage 10).
Kept off this page
Desk research figures
Referral hire rates and time to hire, with no source links kept. No market figure goes on the page until the sources are found.
One observation per note, in their words
162 notes, one observation each
Grouped by interview, in the order they were said. Each note's corner says where it went.
Five pains, each from the side that feels it
Five clusters, each with the tension underneath it
Each label starts with the side that feels it: the candidate asking, or the referrer being asked.
What was merged, and what got lost
- Silence instead of a no (n18) was going to be its own cluster. Merged into C3: not hearing no and not knowing the status are the same gap from two sides. The emotional cost of silence (n16) now sits in C1.
- Proving fit was merged into C2 first, then split back out as C5. Checking fit is the referrer's pain, but candidates want it too, before they ask. C5 is thin.
Every note under its cluster
Each cluster, with its notes sorted into smaller groups
When [situation], I want to [motivation], so I can [outcome]
Five jobs became three, because two pairs were one job seen twice
One job per cluster, then combined where two clusters wanted the same thing.
Five, one per cluster
What combines, and what doesn't
Three final jobs
Asking where it will be read
from C1 + C5When I need a referral at a company where I know nobody, I want to ask someone who is willing, for a role I fit, so my request gets read and has a real chance.
Knowing what happened
from C3When I've asked someone to refer me, I want to know whether it went in and where it stands, so I can move on or follow up instead of guessing from silence.
Referring a stranger in minutes, not an evening
from C2 + C4When someone I don't know asks me for a referral, I want everything I need already there, so helping takes minutes and is worth it even if they're never hired.
All three, in one line
A referral depends on one busy employee's effort, and nothing makes that effort small or lets its result travel back.
Lost in the merge: n89 and n90, referrers wasting effort on people who take a referral and never join. That's about who gets referred, and it stays visible as out of scope.
[User segment] struggles with [problem] because [root cause], which means [implication for design]
Three insight statements, one per final job
The segment and problem come from the notes. The root cause and what it means for design are my reading of them.
Asking where it will be read
from C1 + C5Candidates with nobody they know at the company struggle with getting a stranger to even read their request, messaging two or three people on LinkedIn and hearing nothing, because nothing shows which employees are open to referring or how well the candidate fits, so every ask arrives as the same cold message, which means the ask has to go to someone who has already said they're willing, and carry the fit with it.
n09 n13 n14 n15 n17 n30 · n04 n08 n20 n21 n24 n28 n37 n43 n49 n68 · n11 n22 n23 n29
Knowing what happened
from C3Candidates who have asked for a referral struggle with not knowing whether it was ignored, declined, submitted or rejected, waiting weeks and reading silence as a no, because the status sits in the company's portal and the referrer's inbox, and nobody's job is to tell the candidate, which means the status has to reach the candidate through the referrer, without the company sharing its data.
n01 n18 n25 n33 n34 n35 n36 n41 n44 n45 n46 n84 n85
Referring a stranger in minutes, not an evening
from C2 + C4Referrers asked by people they don't know struggle with requests that cost them rounds of chasing job IDs, cities and dates of birth, for a bonus that is low and only paid if the person is hired, because the request arrives as a message and a resume while their portal needs structured fields, so the referrer ends up doing the candidate's data entry, which means the candidate has to supply everything the portal asks for before the referrer is asked to do anything.
n57 n59 n60 n66 n67 n70 n71 n73 n74 n75 n76 n77 n78 n79 · n31 n32 n42 n52 n62 n69 n87
Chosen from three drafts
The request asks the referrer to do the candidate's work, and the answer never travels back
Three drafts: one from the referrer's side, one from the candidate's, one holding both. I picked the one that holds both, and narrowed it.
Problem statement
An employee asked for a referral by someone they don't know has to do the candidate's work before they can say yes. So most don't, and the candidate never finds out.
The request arrives as a LinkedIn message and a resume. The company's portal needs the job ID, the city, the date of birth, career gaps and preferred interview locations, none of which are in the resume. So the referrer either chases the candidate for them or drops the request. The only reward is a bonus that is low and paid only if the person is hired.
Meanwhile the status of a submitted referral already exists, in the referrer's portal and emails. It never reaches the candidate, who reads silence as a no.
Referrers are willing to help strangers. Samarth would refer a complete stranger who fits, and Riya feels "a little obligated" once a candidate has shared the job ID. What stops them is the work the request leaves for them, and nothing brings the answer back to the candidate.
"they don't share the job ID, which irritates me a lot... I will not take the pain and go and check for it"
Riya, as a referrer · n76"whoever did not reply, they did not refer me"
Riya, as a candidate · n35What happens today
Saw itAll eight interviews
That the work is why strangers get dropped
Worked it outAll four as referrers, and Riya's rule (n76, n77)
That a complete request gets referred more
GuessingNobody was shown one
Referring a stranger costs the referrer admin work nobody pays them for, so they don't do it.
Lost: it ignores the candidate who never learns what happened, and that's in all four candidate interviews.
A candidate with nobody at the company has no way to reach a referrer who will read the request, and no way to learn what happened.
Lost: it describes what the candidate suffers, not why. Designing for it alone gives the referrer no reason to take part.
Walking it back to a note, out loud
What the research killed in the first design
Referrers fear for their reputation
"that responsibility should not fall on the referrer"
Samarth, as a referrer · n55Referrers need help deciding
All four already have simple rules: a 50 to 70% skill match (n50), a 90% match (n115), whether the job ID was shared (n76, n81), their own field only (n152). Their pain is the admin.
Referrers are flooded
Samarth doesn't get many requests (n61). So request limits can't be justified by spam, only by the guardrail.
Trust between strangers is the gap
The notes show work and silence. Nobody named trust as the reason they didn't refer.
Four products, plus no product at all
Everyone sends a message and a resume. Nobody sends what the portal needs.
From my own screenshots. The products may have changed since.
| How you ask | What limits asking | What the referrer gets | Who reports status | |
|---|---|---|---|---|
| A blank message | Connecting first | Nothing on screen | The candidate ("Did you hear back?") | |
| GetMeReferred | Free-text "Referral Message", resume | Credits bought with money | Credits for accepting | Nobody, for referrals |
| EasyRefer | Form, message, sometimes 50-word answers | Nothing seen | Nothing on screen | The platform, for its own applications |
| Instahyre | No referral step visible | A visible penalty for backing out | No referrer | The platform, for applications |
| No product | WhatsApp or LinkedIn, job link, resume | Nothing | A bonus, sometimes | The referrer's portal, only they see it |
| SideDoor | A complete request, portal fields included | A weekly limit, not money | Fit shown, fields ready to copy | The referrer, in one tap |
What nobody does, and why not
Collect the portal's fields before the ask
Every portal asks something different. The two portals in the notes overlap a lot but not fully, so a request can carry the common fields plus a short company-specific part. Worked it out
Show the candidate what happened
No outside product can read the company's system (n46). But the referrer already sees it (n58, n83), so they pass it on, if that costs a single tap.
Show fit to the referrer
Fit scores are sold to candidates, and nobody shows fit to the referrer. Samarth checks it by hand (n50) and asked for exactly this (n65), so this is where SideDoor can do something new.
Keep asking free and still limit volume
GetMeReferred controls volume with price. SideDoor uses a weekly limit and complete-request rules instead.
- A free-text request box: more writing, still no job ID
- Paying per referrer: sells the scarce side
- Swipe, or Interested / Not interested: one gesture pushes volume
- Stats on the page with no source
- "People you can reach out to": the warm path first, as Samarth does (n03, n04)
- "Did you hear back?": status without the company's data
- "Review time is typically 1 week": sets the wait before it turns into silence
What a model should do here, and what it shouldn't
The model does two jobs: reading documents into fields, and ordering requests by fit
Everything else is plain product. Nothing moves without a person.
| What a model can do | In SideDoor | Verdict |
|---|---|---|
| Pull out | Resume into the fields a portal needs; job description into job ID, city, skills | Yes, the most Samarth types skills into the portal by hand (n60) |
| Sort | Order a referrer's requests by fit, with the reasons shown | Yes Samarth checks fit by rule (n50) and asked for this (n65) |
| Suggest | One question per skill for the referrer to ask, from the job description | Yes, tap to use The referrer can write their own |
| Generate | Write the candidate's message | Harmful Riya acts on the job ID, not the prose (n76) |
| Predict | "Your chances are high" | Nothing yet A concept has no outcomes to learn from |
| Act | Auto-send requests, auto-decline low fits | Harmful Volume, and a decline in the referrer's name they didn't make. Samarth refers borderline people on purpose (n53) |
How much it does on its own, for the fit order
Show only matched candidates
A hidden request is silence for the candidate, which is C3 again.
Best fit first, lower matches folded and still referable
The referrer decides every one. No single score: a count they can check, like "4 of 7 skills", each skill with where it was found.
When it's wrong, the words on screen
"Not enough in their resume to judge fit for this job. Read it before you decide."
"Add the job ID first. It's the first thing a referrer needs."
"We couldn't read this file. Try a PDF with text you can select, or fill in the details yourself."
The riskiest assumption
That a resume and a job description hold enough to judge fit the way Samarth does. If most requests land in "Not enough to judge", the ordering helps no one. The cheapest test: five real resumes for one of his roles, with and without the breakdown.
The one-page brief
How might we let a stranger's request be acted on in minutes, and the answer travel back for free?
The main path
- A candidate finds a job where someone refers, with their match shown before asking
- Checks the request. The portal's missing fields are asked once, and Send stays off until it's complete
- The referrer sees requests ordered by fit, weaker ones folded but still there
- Opens one: what could stop it first, then each skill with where it was found
- Taps Refer. Every portal field is ready to copy, or emailed to their work inbox
- Marks it submitted while the portal is still open
- The candidate sees Submitted, and what usually comes next
Own the input, understand the output, trace the chain
Each design decision, traced to the number it should move
An input that rises without moving the North Star is noise. More complete requests only matter if referrers submit more of them.
Referrers who turn off requests or leave must not rise. A product that makes asking easier can flood the people it depends on. Watched with a second number: requests left unanswered after 7 days must not rise.
Which loop each feature belongs to
Each version kept untouched in Figma
From a swipe app to a request that arrives ready
Scroll sideways: what each version changed, and what I learned.
V3 to V6 show today's screen where that change still lives.
Stress and craft passes
I predicted only 1 of the 13 breaks I found.
Empty lists, long names, wrong input and slow networks, thrown at the screens with the expected result written down first.
| What I threw | What should happen | What happened | How bad |
|---|---|---|---|
| A skill 60 characters long | It wraps. It's the evidence | Cut to "Human-centred service design ar" | Major |
| Date of birth 31/02/1999 | An error under the field, Send stays off | No field error, so a wrong date reaches the portal | Major |
| Refer tapped by mistake | A few seconds to undo | Status flips, and the candidate is told something false | Major |
| Send tapped twice on a slow network | "Sending…", and the button turns off | No in-flight state | Major |
| A 300-character note | It wraps, the card grows | It wraps, the card grows | Passes |
All four majors above were fixed: wrapping, a date picker so a wrong date can't be entered, a 5-second Undo, and a Sending state. On the last pass, three quick taps on Send took requests left from 2 to 0. That's fixed too.
Craft, in numbers
44 × 44 tap areas
Back, bell, edit pencil and link icons were 18 to 24 pt. Each now has a 44 pt hit area.
White on brand green, 2.54 : 1
The "4 of 7" banner failed the 4.5 : 1 text needs. After seven rounds the banner was deleted, and the evidence moved up by its height.
Written before the test, never changed after
What would prove me wrong
Nobody has used SideDoor yet. The next real test: 8 referrers in tech who got a stranger's request in the last month, each using their link for two weeks.
Fewer than 1 in 5
complete requests from strangers get submitted to the company portal. Today's cold message gets about 1 reply in 5: "80% of the time they don't reply" (Riya, n30). A complete request has to beat that.
Fewer than 3 of 8
referrers send their link to anyone in the two weeks. Then referrers won't start the loop alone, and the cold-start bet is dead.
First, a usability test
Samarth and Riya, one session each, ten tasks: five as a candidate, then five as a referrer. It can show whether two people can finish the main flows and where they get stuck. It can't show whether referrers will submit more. That needs the test above.
Open questions a real test would answer
How much of a real portal form do the common fields cover?
Will a referrer pass on the status if it's one tap?
Does showing fit to the referrer raise how many they submit, or only how fast they decline?
Are invited candidates referred as often as those who ask on their own?