Bottom-up Adoption

Software used to arrive from above. An internal systems group drew up a shortlist, an executive approved it, a company-wide announcement went out, and from that day everyone used the thing. Half a year between the decision and the first real use was normal, and in all that time nobody asked the people who would work in that tool every day.

So the same scene kept repeating on the floor. The document tool the company paid for sat unopened while teams piled their actual meeting notes into whatever free web tool they liked. The approved option went unused, and the option nobody had approved was where the work happened.

The order flipped once products arrived that a single person could sign up for and use alone. Instead of a decision arriving first and usage following, usage accumulates and the decision ratifies it later. Bottom-up adoption names that reversal. Various mechanisms built into the product push the sequence along, and the flow those mechanisms produce is what the term points at.

Adoption moves through four stages, each one a larger headcount than the last, and each stage has a mechanism inside the product that carries users into the next one.

1. One person arrives. A self-serve signup flow — an account created from an email address alone, with no contact form and no approval step — opens this stage. Whoever walks in is not representing their company. They came to solve one problem of their own.
2. They find value while working alone. The gap between signing up and deciding the product is worth keeping is called time to wow, and when that gap is long, adoption stops at stage one. Products that require an administrator to configure something before anyone can work stall right here.
3. It spreads sideways. Showing a document to a colleague means typing in their address, and the person who receives it creates an account to open the document. Team invite is the mechanism for this stage. From here users arrive in teams rather than one at a time.
4. A limit is hit and somebody pays. This is where usage-based upgrade design lands: cross the line on the free plan and an upgrade prompt appears. The first payment usually comes off a team lead's card or a team budget, runs about $30 a month, and never touches an approval chain.

At Pagedeck the four stages tend to move at this pace. One engineer at some company signs up alone and starts writing meeting notes. Three weeks later six accounts share that company's email domain. Two quarters later forty people are working out of the same document library. Through all of it, nobody in that company's procurement group has heard the name Pagedeck.

The decision maker shows up last, and by then there are hundreds of documents inside the company, so the question on the table has changed. It is no longer whether to adopt the tool but whether to consolidate what people already use into a company account. Rather than water being poured from the top and soaking down, it rises from the floor until it reaches the decision maker's feet.

A viral surface — the product's name visible in the corner of a shared link someone opens — restarts all four stages inside a different company.

Three conditions decide whether a product can spread this way. It has to be useful to one person working alone, the first payment has to be small enough to skip an approval chain, and starting has to require nobody else's permission. Collaboration documents, design tools and code repositories qualify. Payroll systems do not, because one person cannot run payroll alone; security appliances cost tens of thousands of dollars a unit; accounting ledgers only open once permissions are granted. Products like those go to enterprise sales — long deals worked through a large company's procurement process — from the start.

The term itself comes up in three places.

Pricing work is the most frequent one. Where the free plan's limit sits, and whether to charge by seats in proportion to how many people use the product, directly set the speed of the spread. Cap the free plan at three documents and adoption stalls before stage three; cap it at two hundred and nobody ever reaches stage four.

It comes up again when a sales organization is being designed. A product that spreads bottom-up needs people who find accounts already in use and convert them into organization-wide contracts before it needs people making cold calls. That makes identifying the champion — the person inside the customer advocating for your tool — a practical task. It is usually not whoever signed up first but whoever pulled the team in.

It shows up in investor material too. The word compresses the claim that revenue grows without adding sales headcount, so it travels alongside numbers on how users per company domain have grown month over month.

"There are already 22 people on accounts from this company. Now is the time to roll them into a company-wide plan."

Bottom-up adoption has already happened somewhere, and sales should go in.

"We're bottom-up, so building out a sales team first gets the order wrong."

An argument for spending on the signup flow and the product experience before spending on sales headcount.

"Is it fine that people start using this before it passes a security review?"

Pointing at the risk on the other side of spreading without controls.

At Pagedeck, Ravi scans users per company domain every week. When a company jumps from one user to 22 in a month, that list goes to Sofia. The conversation about an organization-wide contract starts at a company where nobody has paid anything yet.

The most common misreading is that bottom-up adoption means sales is unnecessary. Payments happen without a sales conversation, so the assumption comes easily. But turning a company where 40 people use the product into a 500-seat contract drags in a security review, a legal review, price negotiation and billing changes, and people do that work. Skip it and you end up with dozens of users across a company while the revenue stays at the few tens of dollars a month coming off a team lead's card.

The second misreading is that opening the product for free is enough to make it spread. The barrier is gone, so the rest looks automatic — but things spread because someone who used the product alone gained a reason to show it to a colleague, not because it cost nothing. When that reason isn't built into the product, free accounts pile up: signups climb month over month while average users per company domain sits at 1.1 and no team ever converts.