Product Case Study

BD4

Add contacts,
build your network

From a single form to a five-path router, and everything that broke, debated, and shipped along the way.

Screens

20 across 5 flows

Versions

4 FRD iterations

Principles

3 shipped

“The Add screen isn’t a form. It’s a router, and a search engine.”

01 · What is BD4

A business-development engine for professionals.

BD4 handles the relationship work that gets pushed aside, telling you who to reach, when to act, and what to say.

Prioritizes

The right person to contact, and why now.

Drafts

Outreach in your voice, grounded in real context.

Sustains

Consistent follow-through so relationships stay warm.

The engine needs fuel

But every action depends on one thing: a network to work with.

No contacts → nothing to prioritize, nothing to draft, nothing to sustain.

02 · The Problem

An empty BD4 is worthless.

The recommendation engine, warmth scoring, and action flow all depend on a populated network. Without contacts, the product cannot prove itself, and professionals leave before it can.

The cold-start problem

Intelligence needs a substrate. No contacts means no signals to rank, no warmth to score, and nothing to recommend.

“So the real question wasn’t how do we add a contact. It was how do we get a network fast enough to earn trust?”

Today’s top action: None, CEO of Nothing. Why now: add people to experience BD4
02 · Research & Discovery

Four findings that shaped everything

A formal study, direct access to beta participants who gave candid feedback at the exact moments the product failed them.

01

Existing contacts were the harder problem

Books of business live in three places, incomplete. The system has to tolerate mess, not reject it.

02

Incomplete data was the norm

“My contacts are in my old CRM, a LinkedIn export, and a spreadsheet.” Bulk became first-class.

03

The small field silently failed

Enrichment mislabeled a contact and couldn’t flag it. The system needs to know when it is confidently wrong.

04

Privacy was an afterthought

Users ask what BD4 does with their data before it becomes a trust feature.

02 · The Hypothesis, and where it broke

On-the-go intelligence was one door, not the room.

BD4’s founding philosophy was intelligence in the moment: meet someone, add them, get a recommendation. The first Add screen was smart and right, for one kind of user.

The initial hypothesis

Search & Add

“A professional meets someone, searches their name, and BD4 catches the rest.”

One contact, in the moment · worked for 1 of 5 scenarios

MetricV1 Result
Time-to-network threshold3–5 days · many never reached
Reaching an active networking session~15%

One at a time can’t populate a network fast enough to earn trust. Most users left session 1 with a to-do and an empty engine.

02 · The Hypothesis, and where it broke

On-the-go intelligence was one door, not the room.

In their own words

“My book of business is in a spreadsheet I’ve kept for years.”

“Everyone I know is already in my email.”

“I grab their LinkedIn and decide later.”

“I’ve known him 20 years, he’s barely online.”

The job wasn’t one entry. It was five.

Search-and-add assumed the network already existed. For most professionals it already did, just scattered across email, spreadsheets, LinkedIn, and memory. The Add screen had to meet all of them.

03 · Solutioning

One door became five. Five became one room.

Each version didn’t just add a path, it changed what we believed the Add screen’s job was.

One door, then a door with three arrows, then five paths into one room
V1 · Search & Add

Build it here

Search a name. Add one contact. The network starts here.

V2 · Bring it in

Import what exists

Bulk and dedupe became first-class. The network already exists.

V3 · Five doors, one room

Meet it wherever it lives

Five entry paths. One shared destination. Only what happens next.

On-the-go intelligence was never wrong, it was one door. Add PCS became the room they all open into.

03 · Five scenarios

User scenarios

The original design assumed professionals add contacts one at a time, right after a meeting.

1

Just met someone

Fast single-add, zero friction, a memory or a business card.

2

Got a LinkedIn URL

Paste and go. BD4 finds everything from the URL alone.

3

Uploading a list

45–200 rows from a conference. One at a time isn’t viable.

4

Existing book of business

Years of contacts, incomplete. Tolerate mess.

5

No online footprint

A name and a relationship, and little else.

The gap

Only one scenario starts from zero. The other four already have their people, scattered, incomplete, and waiting to be migrated.

03 · The Router Architecture

One router. Five paths. One queue.

Every entry path feeds the same matching pipeline and lands in the same draft queue. No per-path silos.

Add Contact router branching to Natural Language, LinkedIn URL, Scan QR, Bulk Upload, and Manual Entry
One unified queue

All five paths land in the same search-queue-draft sequence, same card types, same data floor, same reopen behavior.

→ 1

No silos. No path-specific edge cases downstream.

The Screens

What it looks like in the product

Add, match, mine, enrich, and the running total that makes progress feel real.

Product screens: add a contact, finding your contact, drafts, 200-row mining, BD4 found vs only you know, and the contact-count total
03 · Information Architecture

Core flow

Every entry path, natural language, LinkedIn URL, QR scan, bulk upload, feeds the same matching pipeline and lands in the same draft queue.

Flow A · Choose router

7 screens. Landing, natural-language add, drafts list.

Flow B · Search, find & match

6 screens. Finding, seven match states, confirmation.

Flow C · Enrich & classify

4 screens. Show info, collect context, classify.

Flow D · Confirm & draft

3 screens. Confirm, enrich, added or saved.

No per-path silos. One pipeline, one queue, one set of rules.

04 · Information Architecture

From entry to a usable PCS

Five entry paths converge into one matching, enrichment and confirmation system.

Five-stage contact pipeline: entry, find and match, enrich and classify, confirm, drafts queue
Flow A · Route and choose

One entry point that reads the situation, then hands the user the fastest path in

Natural language first

“Tell BD4 who you’re building a relationship with”, the default is a sentence, not a form. “Alex Chen, CEO from Stripe,” and BD4 pulls together the rest.

Every other path, one tap away

Scan QR, LinkedIn URL, Bulk Upload, Contact Import all sit right below, for four other scenarios one swipe more than a tap from the same screen.

Drafts stay visible while you work

Uploads enrich in the background. 150 of 100 done enriching, 90 added, 20 to be reviewed, while single-adds land as draft cards, all in one place.

Same router, every surface

Desktop and mobile use the identical entry logic, the router isn’t a screen, it’s the system behind all of them.

Build Your Community entry screen: natural-language input with Scan QR, LinkedIn URL, Bulk Upload, Contact Import, and drafts enriching in the background
Stage 02 · Find & Match

Searching a contact wasn’t one outcome, it was seven

Every confidence level and edge case needed its own screen, copy, and path. Designing the happy path first would leave the seven scenarios broken in production. Scroll to move through them.

High confidence match, we found a match Multiple profiles found, confirm the right one Low confidence match at 34% Similar contact already in your community Partial data, could not reach sources, filled form No match found, could not complete the search
  1. 1

    High confidence match

    94% match. Auto-fill and move on, the happy path resolved instantly.

  2. 2

    Multiple profiles found

    Found several people. Disambiguate, the user picks the right one.

  3. 3

    Low confidence match

    Only 34% sure. Show the guess, flag it, and offer save-as-draft or incorrect-match.

  4. 4

    Similar contact exists

    Already in your community. Merge or create, the user decides.

  5. 5

    Partial data only

    Sources unreachable. BD4 fills what it caught, the user adds the rest and retries.

  6. 6

    No match found

    Nothing came back. Details are saved, fall back to manual entry, never a wall.

  7. 7

    Timeout, hard failure

    The search broke. The card is saved as a draft so no input is ever lost.

Flow C · Enrichment evolution

The enrichment screen went through three philosophies

Each version changed what we believed the screen’s job was, and how much we trusted the system versus the professional.

1

Show information

BD4 found from public sources, PCS, Crunchbase. Name, role, company. Trust the data.

2

Collect context

Add the relationship layer the system can’t see, how you met, why they matter. Human-led. The user knows more.

3

Eliminate friction at scale

Enrich and classify in one motion, defaulting the unknowable so nothing blocks the add. Balanced. Ship the network fast.

Enrichment phase 1, show what BD4 found
Enrichment phase 2, collect context
Enrichment phase 3, eliminate friction
07 · Conflict & Hard Decisions

The unknown-defaults debate

Should Type, Fit, Warmth, and Stage be mandatory before bulk upload? Or is Unknown a valid default? A real disagreement, and this was on the wrong side of it.

My original position (wrong)

Make classification mandatory. A wrong recommendation, an “into message” to a 10-year client, is more damaging than no recommendation at all.

I pushed back on Unknown as a permanent state.

What we shipped (right)

Type defaults to Prospect. Fit, Warmth, Stage default to Unknown. The engine handles Unknown via partial-confidence, reduced confidence, not silence.

Blocking the add was the bigger risk. Some recommendation beat none.

What I learned

A permanent “Unknown” that keeps users moving beats a mandatory field that stops them. Reduce confidence gracefully, don’t block the network from forming.

08 · The Draft System

Five ways in. One draft out.

01

One data floor

Name + Role + Company, or it’s incomplete. The same threshold applies to all five paths.

02

Two card types

Complete or incomplete. Every path renders the same two cards.

03

Edits always win

Enrichment never overwrites a field the user changed.

The paths diverge. The draft doesn’t.

Drafts queue of 35 with enriched, enriching, and unresolved card states
08 · The Draft System · Proof

Different inputs. The same two cards.

PathProduces
Natural languageComplete, or incomplete + flagged
LinkedIn URLComplete, auto-enriched
QR scanIncomplete, enrich later
Bulk uploadOne draft per row; nulls → incomplete
Manual entryComplete if floor met

Five inputs. One queue, two card types, one set of rules.

Unresolved draft-card variants showing progressively less data
09 · Version History

V1 → V4: how our understanding evolved

Each version didn’t just add a feature, it changed what we believed the product’s job was.

V1

Single input

One form, one finish. Assumes everyone adds one contact at a time.

V2

The router

Five situations, five paths. The reframe that reorganized everything.

V3

Show info + collect context

Enrichment splits into what the system knows and what only the human does.

V4

Scale via enrichment

Bulk becomes first-class, activation across all five paths.

10 · Documentation, the FRD as interface

A great FRD answers the 11pm question when no one’s available

The FRD’s job isn’t to describe a feature, it’s to transfer understanding so completely a developer can resolve any edge case without escalating.

Screen ID + purpose

Screen 04 isn’t “match screen,” it’s “Match, Confirmation, low-confidence variant.” Bits and edits are separate specs. Naming them apart gave low confidence a flag and high confidence auto-fill behavior.

UX-tagged items

Reopen a draft after enrichment ran overnight, if the user added a field, enrichment never overwrites it. Without that rule, fresh data silently erases an intentional correction, the worst kind of bug, because it looks like the system working.

Copy-tagged items

The bulk-upload result copy: “X profiles couldn’t be enriched, saved as draft.” They broke something over a subtle inline “review their scoring.” The specified the exact string, and so did every other case.

Logic-tagged items

A CSV row has a name but no email. Not documented means the developer guesses, skip it, or reject the whole file. The FRD says accept the row, save it as an incomplete draft, and queue it for enrichment. A data-quality problem becomes a designed state, not an error.

Acceptance criteria

“Done” for the match flow isn’t “it finds the contact,” it is: if each with its own copy and auto-motivating timeout. Defining the states with a dry timeout got itself instead of surfacing as a frozen screen in production.

11 · Outcomes

What shipped, and how we’ll know it worked

A complete Add-PCS system, measured by whether professionals reach value faster.

What shipped

20-screen FRD

Every entry, every match outcome.

Router architecture

Five paths, one pipeline.

7-state matching

Every confidence outcome handled.

Bulk upload

CSV to mining pipeline.

Draft system

One queue, two card types.

Product principles

Unknown-defaults, edits-win, one queue.

Success signals
70%Activation, reach the first active networking session
≤ 8 minNetwork threshold, reach 10 useful contacts
60% / 80%Active network, first session to first week
≤ 60 secFirst contact added, single-add paths
≥ 85%Task completion, drafts resolved

Shipping the system matters. Proving it reduces time-to-value matters more.

What this work proves

Three lenses

As a product thinker

The router reframe was a strategic decision, not a design one. Naming the real job, before it came under pressure, gave the team something to hold to.

As a prioritizer

Three decisions, unknown-defaults, mandatory review, draft persistence, each looked like a detail. Each was actually a product principle.

As a builder

The FRD went through four versions over twelve weeks. Every engineering answer could’ve been a Slack thread, was answered in the doc instead.

Strategy named the architecture. Design made every state survivable. Documentation shipped it.