What is the difference between bottom-up and top-down sales?

They demand different products

A bottom-up product must be immediately useful to one person with no permission, no configuration and no training. That constraint shapes everything — onboarding, pricing page, even the depth of the feature set, because complexity that requires explanation kills the motion.

A top-down product must satisfy a buyer who will never use it daily: security posture, compliance, admin controls, reporting, integration with systems of record. Those requirements are invisible to individual users and decisive to procurement.

Building for both simultaneously from day one usually produces something that does neither well.

Where each wins

Stripe is the reference bottom-up case. Developers integrated it because the documentation and API were better than the alternatives, and by the time anyone senior was asked to approve a payments provider, it was already processing transactions. The decision had been made by the people who'd done the work.

Jira arrived through the opposite door — an organisational decision about process, configured centrally, rolled out to teams. That's why its history is one of accumulating configurability: the buyer was the person who wanted it to model their process, not the person who used it every day.

The collision point

Bottom-up companies hit a wall around the enterprise boundary. Usage has spread, IT notices, and suddenly there's a security review, an SSO requirement and a procurement process the self-serve motion has no answer for.

This isn't a failure of the model — it's the moment to add the top-down motion on top of the demand the product created. The companies that struggle are the ones that treat it as an interruption rather than a stage, and try to solve an enterprise buying process with a better pricing page.