Case study · Upfort · 2023 to 2026
Growing a product its users never chose to buy
Upfort sells cybersecurity to small businesses through insurance carriers, brokers and affinity groups. The carrier signs the deal. The business owner gets the product with the policy. Somebody in the office then has to deploy it to people who have never heard of us. I was Head of Product, and the hardest problem on my desk was the gap between a signed partner and a protected employee.
These describe the shape of the problem rather than results. Deployment and activation figures from this work belong to Upfort and are not published here. The interface below was redrawn from scratch for this page and is not Upfort's product design.
The situation
The buyer, the user and the channel are three different people
In most software the person who pays is close to the person who uses it. In embedded distribution they can be four handoffs apart, and nobody in the middle is accountable for the last one.
An insurance carrier or a broker decides to include the security service with cyber coverage. The policyholder, a business with somewhere between ten and a few hundred employees, receives it. Someone at that business, usually an office manager or a founder rather than a security professional, is expected to turn it on. Their employees then have to use it, and no employee ever asked for any of this.
Every party in that chain has a different reason to care, and the product only produces value at the far end of it. A carrier that has signed and a policyholder who has received are both counted as wins by the business, and neither one means a single person is protected.
Wants fewer claims and a reason to renew. Never opens the product.
Got it with the policy. Reads one email about it, maybe.
No security background, no budget for this, and a day job.
Finds out this exists when a browser warning appears.
The diagnosis
We were measuring the wrong end of the chain
Partner sign-ups and policyholder counts are the numbers a channel business reaches for, because they move first and they are easy to report. They are also the two numbers that can grow while the product does nothing for anyone.
We reset the measure the product was held to. Deployment, not accounts created, not partners signed. Tools actually running for actual people. The proxy event we could watch daily was the first non-admin user added to a workspace, because that is the moment an admin stops evaluating and starts rolling out. One admin protecting one admin is not a deployment.
That reframing changed what counted as a bug. A confusing consent screen stopped being a design nit and became the thing standing between a signed partner and a protected employee.
A signed partner and a protected employee are separated by four handoffs, and the product only owns the last two.
The redesign
What a zero-intent admin can actually be asked to do
The onboarding we had was built for someone who had chosen the product. It opened with a feature inventory, asked for mailbox permissions early because that is where the technical dependency sat, and treated adding the team as an administrative afterthought.
None of that survives contact with an admin who did not buy anything. Three changes did most of the work.
Outcomes, not feature names
Seven separately named capabilities folded into two packages described by what the business gets. Nobody outside security knows what a secure email gateway is, and the name does not help them decide.
Value before authorization
The highest-objection step is granting access to the company mailbox. It moved behind a moment where the admin has already seen the product catch something. The ask is the same. The position is not.
The team is the goal, not the cleanup
Adding employees became the next step after value lands, with three routes out of it, including handing the job to whoever really runs IT.
Before
- 1Create an account
- 2Read what the seven products do
- 3Grant mailbox access to continue
- 4Configure settings
- 5Add users, eventually
Ordered by how the system is built. The heaviest ask arrives before any reason to say yes.
After
- 1Activate with the policy number you already have
- 2See the product catch a real-looking attack
- 3Connect the mailbox, with the objection answered on screen
- 4Add the team, or hand it to the person who runs IT
- 5Coverage tells you who is still exposed
Ordered by what the admin needs in order to take the next step.
The prototype
Six screens, redrawn
I build clickable prototypes before engineering time goes into a flow, using AI coding agents, which is how my teams test whether a sequence holds up before anyone commits to it.
The six screens below are a rebuild made for this page. The product decisions are the ones described above. The visual design, the layout, the components and the sample data are all mine and were written from scratch. Use the arrow keys or the buttons.
Activate
Your cyber policy came with this. Turn it on.
It is already paid for. You need the policy number, not a credit card.
Setup stays open for 14 days.
- 1On the letter or email that sent you here.
- 2On the first page of your policy PDF, labeled Policy ID or Policy Number.
- 3Your broker has it and can read it to you.
No policy number? We can bill you directly instead.
Build safer habits
Teach your team what to spot, and block what they miss
Two minutes of practice a month, plus a browser that stops the ones nobody would catch.
- ✓Short lessons built from the attacks aimed at businesses your size.
- ✓Warnings that interrupt a bad link before the page opens.
- ✓Works with the email and browsers you already use.
Try it
Action required: your account has been limited
security‑alert@bank‑verify‑secure.com
We detected an unusual sign-in. Verify your information within 24 hours to restore access.
Verify my accountNice catch. The sending domain is not the bank's.
Catch inbox threats
Connect email to stop what training will not catch
The ones built well enough to fool a careful person get intercepted before they land.
Needs an administrator to approve once. Nobody shares a password.
- +Reads incoming mail to flag and quarantine threats.
- +Adds a report button inside Gmail and Outlook.
- −Does not read sent mail or drafts.
- −Does not change how anyone's mail works.
- −Revoke it from your admin console at any time.
Add the team
Right now this protects you and nobody else
Attacks arrive at whoever opens the mail. Pick whichever of these is least work.
Coverage
Who is still exposed
Deployment is the number. Everything else on this screen is in service of closing these three gaps.
| Person | Browser | Device | ||
|---|---|---|---|---|
| Dana Okafor | Covered | Missing | Missing | Send setup link |
| Marcus Hale | Covered | Covered | Missing | Send setup link |
| Priya Raman | Covered | Missing | Covered | Send setup link |
| Toby Lindqvist | Covered | Covered | Covered |
Sample data written for this page.
Reports
Proof for the people who are not in here
Your broker and your carrier asked what you have in place. These answer it without a meeting.
Protection coverage
Every person on the roster against email, browser and device protection, with the gaps named.
External exposure
What the internet can see of your business, and which findings are closed since the last scan.
Training record
Completion by person, with the refreshers that are due.
Sample data written for this page.
The only credential they have is a policy number
This person did not sign up for anything. They were sent here by an insurer, and the one identifier they hold is on the policy document. Opening with a password creation screen loses a share of them on the first page.
The activation window is on the screen because setup lapses, and a lapsed workspace is a partner relationship that quietly produced nothing.
Redrawn from scratch for this page. The layout, visual design, sample data and copy above are mine and were written here. This is not Upfort's interface and no customer, partner or performance data appears anywhere on this page.
The second user
The channel is a user too, and it wants paper
A carrier or broker that bundles a security service has its own job to do. It has to justify the bundle internally, show an underwriter that policyholders have controls in place, and give a producer something to talk about at renewal. None of that happens inside the admin console, because the channel never logs in.
Exportable reports are the interface for that user. Coverage by person, external exposure with findings closed since the last scan, training completion. They are unglamorous and they are the artifact that keeps the distribution deal alive, which makes them a product surface rather than a reporting chore.
What I would do differently
The honest part
Two things I would change if I were starting this again.
The first is that I spent too long treating onboarding as a flow problem when a share of it was a distribution problem. How the policyholder first hears about the service, who sends that message, and whether it comes from a name they trust all sit upstream of the first screen and move the number more than any screen does. That work needs the partner in the room, and I started it later than I should have.
The second is measurement discipline. A large change to a funnel should ship with the measure it is expected to move and a check that catches a regression without anyone going looking for one. I have watched a rebuild degrade a rate quietly because the instrumentation was pointed somewhere else. Now I write down what should move and what would tell me it went the wrong way before anything ships.
What carries over
What I would bring to an embedded or partner-led team
Five things that hold anywhere the buyer, the user and the channel are different parties.
- 01Measure at the far end of the chain. Partner sign-ups and seats provisioned both grow while nothing is working. Pick the event that can only happen if the product delivered, then find a daily proxy for it.
- 02Design for zero intent. A user who never chose the product has no patience for a feature tour and no obligation to finish. Everything is an outcome they recognize, or it is noise.
- 03Sequence by objection, not by architecture. Find the ask most likely to stop someone, then earn the right to make it. The order of the steps is a product decision, not an engineering one.
- 04Give the reluctant admin an exit that still counts. Handing the job to whoever really runs IT is a successful path, not an abandonment, and building it that way keeps accounts alive that otherwise stall.
- 05Build for the partner who never logs in. Reports, evidence and renewal artifacts are the channel's product surface. Treat them as first class and the distribution deal renews itself.