Atrios

Atrios pays people to make warm introductions. Someone you trust says you should meet this person, and that introduction becomes a booked meeting on a company's calendar. No cold outreach. The oldest move in business, made into a product.

I joined when it had around $10,000 in revenue and almost nobody using it. I was on the founding team and did the design, product, and engineering myself. The idea was right. The product was in the way of it.

Most of what follows is the cheap kind of change: layout, copy, flow, the things you can see. The last decision is the other kind.


The product I inherited

The product I inherited was not usable. Not broken, exactly: every step worked if you were patient enough. But it asked for a LinkedIn export before it showed you anything, ran every introduction through email with the CEO on cc, and paid out months after the meeting, with nothing in between tracked. The people it was built for, the ones with networks worth protecting, are exactly the people who do not put up with that.

Getting in looked like this.

Step 3 of 4 of the old onboarding: instructions for requesting a LinkedIn data archive, with a button that says I've requested my archive
Before5% completedSign upName, roleExport contactsRequest from LinkedInThe wait2 to 10 hoursUpload the fileThen wait to hear back

If you got in, making an introduction and getting paid for it looked like this.

The old Propose an introduction dialog listing five steps: start the intro process, reach out, they respond, connect them by email, get rewarded $800
Before< 1% ever paid for an introOpen the platformWho could you introduce?Email the personCEO on cc, or it does not countWe ask the vendorA second thread, by handThey book a timeBy email, either wayWe confirm with bothDid it actually happen?We invoice the vendorThis takes a whileWe pay you2 to 3 months later

The 1% is the number that stayed with me. Payment is the end of the core loop: an intro was made, a meeting happened, the vendor confirmed it. Almost nobody who walked in reached it. We were losing people at the door and calling it something else.

Behind both numbers, deploying a change to dev took half a day, which set the pace for everything below.


The story

The first thing I changed was the positioning. Atrios paid people to introduce their contacts, which is the plot of affiliate marketing, and nobody with a network worth protecting wants to be read that way. So we changed who the main character was: not the company looking for leads, but the person whose friends already ask them what to use. We called them tastemakers. The pitch went from “intro your friends and make money” to “if your friends need something, send them through here.” Money is still in the sentence, but it comes last, as a consequence.

my first week: the new landing page

Onboarding: removing the door

The new Atrios application: paste a LinkedIn URL, pick a role and industry, add a phone number, with the companies marketplace visible behind the form
Step two of onboarding: connect LinkedIn or Google Calendar in one click, with a plain 'I'll do it later' link under the Continue button
Screens as I designed and shipped them. The whole application, after. One pasted URL does the work the CSV used to do, and the connection step comes second, after you have seen the marketplace, with a plain link to skip it.

The hypothesis was that people were leaving because of what we asked for before they got anything, not because of who they were. If that was right, removing the ask would move completion without changing who got in.

2 changes, and only 1 of them was a decision.

I rebuilt the application flow. Replacing the CSV export with a pasted LinkedIn URL was obvious once it was measured. Nobody defends a 2-hour wait.

Making the connection step optional was not obvious, and it is the one I would argue for again. The social graph is the most valuable thing we could hold. It is what lets us tell someone who they could introduce, and it is the reason the product can eventually do more than wait for people to think of a name. Giving it up at the door felt like giving up the product.

But we were asking for it before the user had received anything. Anything you put in front of the first turn of the loop is a tax you charge people for a value they have not yet experienced. The ask does not get cheaper by being early. It gets more expensive, because there is nothing on the other side of it yet.

By this point we had moved off Lambdas to Hono, with the frontend on Vercel, so a change took minutes to see rather than half a day. That is why these could be tried one at a time instead of as one large rewrite.

After70% completedPaste URLOne fieldAuto-filledVia UnipileInValue firstConnectOptional, later
3 steps, with connect sitting outside as optional.

Onboarding completion is now around 70%. The remaining 30% is deliberate: we turn away people who are not a fit rather than letting them in and failing them later.


The Inbox: one product instead of two

Before, a tastemaker sent a friend a loose link. The friend clicked it, landed somewhere, and never learned what Atrios was or why their friend was involved. Nothing tracked. Nothing explained.

I started out fixing that loop and ended up somewhere larger. The hypothesis was that the two audiences were one, and if that was right, a person who arrived as a friend would come back as a tastemaker without being asked to.

Every tastemaker is also a good lead. They are exactly the sort of person our companies want to meet, which means the two roles we had been designing as separate audiences were the same people the whole time. So we stopped building for two.

I designed and built the Inbox so that one account holds both sides. The friend who was referred lands there and sees which companies want to talk to them. The tastemaker sees the same thing, on the same surface, because there is no longer a difference. We learn who someone is once rather than twice.

The Atrios home: companies to introduce friends to, each with a reward per meeting and a target contact
The Atrios Inbox: companies that want to meet you, each with a reward, a short brief, and the steps to qualify, book, and give feedback
Home and Inbox, one account. On the left, companies you could introduce a friend to. On the right, companies that want to meet you. The same person uses both.

That changed what brings someone back. A static list of companies on a website is something you visit when you remember it exists. An inbox where new companies show up is something you check. The reason to open the product stopped being an obligation to go make an introduction and became curiosity about who is asking for you.

Intro sentBy a tastemakerInboxLearns the modelBooks meetingWith a companyBecomes oneOne tab awayThe person who received an intro is the best candidate to make one.
The loop closes on itself.

It also closes the loop it started as. The person who received an introduction is the best possible candidate to make one, because they have felt what it is like from the receiving end.


Qualification: making an answer final

People were retrying the qualification questions until they passed. Some of them 7 times.

That is not a user problem. If someone can guess their way through a filter, the filter is telling them what answer to give. We were running a check that taught people how to defeat it.

The hypothesis was that the check was teaching people the answer. If that was right, making an answer final would end the rerolls without the pass rate collapsing.

BeforeFails the checkWrong answer givenRetriesJust over half doFails againMost of themEach attempt revealed more about the expected answer. Some reached 7.
The loop fed itself. Each attempt revealed more about the answer we wanted.

2 changes. We verify answers against the open web instead of taking them at face value. And we removed the ability to reroll, so an answer is an answer. That is only enforceable because an answer now belongs to an account, the same account that receives intros and takes meetings, rather than to a link anyone could open again.

AfterAnswers onceNo rerollCheckedAgainst the open webIn, or outAn answer is an answer

This is friction added to a funnel I had spent months removing friction from, which is worth being honest about. The difference is what the friction is for. The CSV wait cost the user something and gave them nothing. The qualification check costs them a second attempt and gives the vendor a real lead.


Incentives: the one I could not make alone

Every decision above was mine to make, and more importantly it was fast to read. A layout change shows up in the funnel within days. That short delay is what made me confident about them.

This one is neither. I argued for it for months before it shipped, it is 2 weeks old, and the evidence will not arrive for months more. Sales had to go to vendors and pitch a closed-won incentive. Users had to rethink what the product was for. After months of it, the CEO agreed to try.

We paid $500 for an introduction that led to a meeting. Around 30% of activity was gamed. People asked friends to take a vendor meeting and split the money. Nobody was doing anything the product forbade. They were doing exactly what it paid for.

Gaming is not a character problem in your users. It is an output of the design.

If you reward a proxy, people optimize the proxy, and they will be better at it than you expect.

The hypothesis was that gaming was an output of the reward, not of the users. If that was right, moving the reward to the outcome would remove it without any enforcement, and the people who left would be the ones the old reward had selected for. So the change was not enforcement. It was moving what we pay on. Rewards moved downstream to closed-won, with product incentives for the friend who becomes a customer. The introducer gets paid when their friend actually becomes a customer.

Donella Meadows has a list of places you can intervene in a system, ordered by how much each one moves it. Near the bottom sit the numbers: prices, thresholds, copy, layout. Near the top sit the rules about what gets rewarded, and above those, what the system is for. Her observation is that the powerful places are rarely where people push, because the weak ones are visible and cheap and the strong ones are defended.

Every decision above this section sits near the bottom of that list. This is the first one that sits near the top, and it is the only one I could not make by myself.

It also finished the sentence the story section started. We had already changed what we said the product was for. This changed what it paid for, which is the version people believe.

Old: paid on the meetingIntroPayoutFast, small, and gameableNew: paid on closed wonIntroMeetingCustomer, payoutMonths of delay
The gap between the two payout points is the whole argument.

What it cost

Volume dropped. Activity dipped. Our heaviest users saw their earnings fall, because they had optimized for a fast cycle that no longer exists.

That dip is not the change failing. It is the change working. The old system's best players were the people the old system selected for.

What changed that I did not expect

I expected the composition of users to shift. It has started to, but not the way I planned for.

When we talked to heavy users whose earnings had dropped, they agreed with the direction. And something changed in the relationship. They started wanting to help their network find the right solution rather than wanting to run volume. We did not just change what they did. We changed what the activity meant to them.

The old system paid people to spend their reputation. The new one pays them for spending it well. The incentive and the reputation now point in the same direction, which is what the product always claimed to be about.

What I do not know yet

The reward runs on the closed-won cycle, so the evidence arrives months from now. I made this decision before I could have proof, because the composition of the user base was the problem and no amount of layout work reaches it.

It will have worked if dormant, highly connected users come back to the platform. That costs no acquisition spend and it tells us these are the people the product was for.


What I took from it

Every section above is the same move run at a different speed. Start from the number that is wrong. Write down what would have to be true for it to move. Build the smallest version that tests that, ship it, and read the result before deciding anything else.

Onboarding, the Inbox, and qualification each ran that loop in weeks. The incentive change is the same move with a read that takes months, and that changes the discipline. When the loop is fast you can be wrong cheaply and let the numbers argue for you. When it is slow you have to write down what worked and failed will look like before you ship, hold the position while the early numbers look worse, and be honest that you are holding it on reasoning rather than proof.

The pattern I would carry forward: the thing holding a product where it is is almost never the thing you can see. Layout, copy, and flow are where attention goes because they are visible and cheap to change. What a product rewards is invisible, and it decides who shows up.

You can redesign every screen and get the same people doing the same thing on different pages.