How Fountain added $10M in ARR in 12 months by accelerating product launches

Backstory

Fountain is an American HR software company founded in 2015 and backed early by Y Combinator. The company initially built an applicant tracking system tailored to frontline workers, a segment often overlooked by traditional HR software built for desk-based employees. Over time, Fountain became the system of record for high-volume hiring in logistics, retail, food services, and the gig economy, serving companies that need to hire thousands of frontline workers every month.

By 2022, Fountain had grown to around 200 employees and raised over $200M across multiple funding rounds, including a large Series C. But the company faced a strategic inflection point. Its core ATS product was strong but sticky in the wrong way: customers rarely switched, making expansion difficult. At the same time, internal product velocity had slowed dramatically due to organizational complexity, technical debt, and a culture that had drifted away from experimentation.

In this context, Fountain acquired Clevy, a French HR chatbot startup co-founded by Salim Jernite. Salim joined Fountain with a clear mandate: help restore speed, rebuild innovation, and unlock new revenue streams through faster product launches. I sat down with Salim Jernite, Chief Product Officer at Fountain, to discuss how he built a product factory that launched eight products in 12 months and added $10M in ARR.

Disclaimer: The organizational choices and technical solutions shared in this newsletter aren’t meant to be copied and pasted as-is. Always keep your company’s context in mind before adopting something that works elsewhere! 😊

‍

Build leverage fast by shipping before asking permission

When Salim arrived at Fountain, the company had the opposite of a shipping culture. Roadmaps stretched over 18 months, teams were large and slow, and “we can’t do this” had become the default answer. Rather than trying to change the system through alignment decks or organizational redesign, Salim focused on one thing: leverage.

He identified two high-impact initiatives that had been requested internally for years but never shipped. Instead of escalating through management, he quietly assembled a small team and built them under the radar. One of those features, a real-time translation capability in the product interface, was shipped in three weeks on a codebase the team did not even know.

The goal was not perfection. It was proof. Proof that speed was still possible. Proof that customers would respond. Proof that delivery could cut through internal resistance faster than debate ever could.

Once the feature was live, internal dynamics changed overnight. Sales teams loved it, customer success pushed it, and the CEO saw tangible evidence that product velocity could be restored. The cost of saying no became higher than the cost of supporting the team.

Salim later summarized this approach simply:

“We didn’t ask for permission. We shipped, and once it worked, nobody could argue anymore” — Salim Jernite

This early win was not about revenue. It was about credibility. By shipping first and explaining later, Salim created the political and organizational leverage needed to go bigger. It unlocked direct access to the CEO, reduced interference from middle management, and made it possible to propose a much more ambitious transformation.

‍

Turn innovation into a repeatable product factory

After proving speed was possible, Salim proposed something radical: stop treating product launches as one-off projects and start treating them as an industrial process. Instead of betting everything on a single roadmap, he designed a factory model that could produce new products continuously.

At the core of this model was a strict nine-month lifecycle. Every product followed the same structure: three months of discovery, three months of beta, and three months to reach general availability. Every quarter, a new product entered discovery. Every quarter, another product graduated to launch. This created a pipeline where multiple products were always in motion at different stages.

Discovery was design-led, not engineering-led. Designers spent weeks speaking directly with customers, mapping pain points, and prototyping solutions before a single line of production code was written. The bar to move forward was clear: at least four customers had to commit to buying the product if it shipped.

This removed a massive amount of risk. By the time engineering got involved, the team already knew who would buy, why they would buy, and how much they were willing to pay.

The factory model also created momentum. Teams were no longer stuck debating priorities endlessly. Everyone knew where each product stood in the pipeline and what success looked like at every stage.

Salim described the effect clearly:

“Once the factory was running, everything compounded. We shipped faster, learned faster, and stopped wasting time on ideas that wouldn’t sell”

‍

Design squads for speed, not comfort

One of the most counterintuitive choices Salim made was to keep squads intentionally small and partially shared. A typical squad consisted of one senior engineering lead, two backend engineers, and one frontend engineer. Product management, design, and QA were split across multiple squads instead of being fully dedicated.

This setup went against many scaling best practices, but it forced ruthless prioritization. Teams could not hide behind process or overstaffing. If something did not matter, it simply did not get done.

The key was seniority. These squads were staffed with experienced engineers who could make decisions independently and accept trade-offs. They optimized for demo-ability first, not architectural perfection.

This approach enabled extremely fast iteration cycles. In some cases, teams shipped demo-ready products in under a month, refined them live with customers, and then hardened them only after commercial validation.

The constraint was intentional. Limited resources created focus. Focus created speed. Speed created learning.

It also made it easier to scale. When demand spiked, Salim could add squads without redesigning the entire organization. Each squad followed the same operating model, the same milestones, and the same definition of success.

‍

Co-design with customers until they become buyers

A critical pillar of Fountain’s product factory was co-design. Customers were not interviewed once and forgotten. They were embedded into the product development process from day one.

For every new initiative, the team recruited a small group of design partners. These customers had real pain, real urgency, and real budgets. They joined regular sessions, reviewed prototypes, and shaped the product roadmap in real time.

This created two powerful effects. First, it dramatically increased product quality. Teams were not guessing what frontline operators needed; they were building alongside them. Second, it turned beta users into champions.

By the time a product launched, it already had customers willing to sign contracts. Sales was not asked to sell a hypothetical roadmap. They were handed a product with reference customers, case studies, and live usage.

In some cases, Salim personally closed the first deals to remove friction and prove demand. Once the product was clearly sellable, sales teams quickly followed.

This approach reframed beta from a cost center into a revenue engine. Every beta had a clear commercial objective, and success was measured in signed order forms, not NPS scores.

‍

Align launches with go-to-market from day 1

Shipping a product was never considered the finish line. For Salim, a product only existed once the rest of the company could sell it confidently.

Product marketing and growth were involved months before launch. While engineering worked on the beta, the go-to-market team prepared positioning, pricing, landing pages, sales decks, and internal enablement. Every launch came with a complete “product kit” ready for sales, marketing, and customer success.

This eliminated a common failure mode in B2B SaaS: great products that nobody knows how to sell. At Fountain, launches were synchronized moments across the company.

The impact was visible immediately. Conversion rates improved, sales cycles shortened, and new products generated revenue faster than legacy features ever had.

“If sales can’t sell it on day one, the product isn’t done”, Salim put it bluntly

‍

When speed beats strategy: the i-9 product bet

Not every product came from a carefully planned roadmap. One of Fountain’s biggest wins started as a reactive bet.

A major customer informed Fountain they were changing their i-9 compliance provider, a legally required employment verification process in the US. The opportunity was massive, but Fountain did not have a product.

Instead of running a long strategy process, Salim acted. He studied regulations, read customer complaints, partnered with an external engine provider, and asked a four-person team to build a demo in three weeks.

The product was incomplete, but it was credible. It got Fountain into the RFP process against established incumbents. As requirements became clearer, the team scaled up, filled gaps, and shipped aggressively.

Fountain won the deal. Within months, the product was live at massive scale and became one of the fastest-growing revenue lines in the company.

The lesson was clear: vision matters, but speed and trust sometimes matter more. When the opportunity is big enough, momentum can justify bending the roadmap.

‍

The mistake: waiting too long to challenge broken assumptions

The biggest mistake Salim shared was not about execution, but timing. Fountain’s slowdown did not happen overnight. Product velocity declined gradually as teams grew, processes hardened, and fear of breaking things increased.

For too long, those signals were accepted as normal. Long timelines, negative engineering culture, and overprocessing became institutionalized before leadership fully reacted.

By the time action was taken, the company had already lost momentum and revenue opportunities.

The key lesson is not to wait for a crisis to question core assumptions. When teams start saying “it’s impossible” more often than “let’s try,” something is already broken.

Fixing that requires more than reorgs or new frameworks. It requires visible proof that speed is still possible and leaders willing to back delivery over consensus.

‍

• Shipping one undeniable win can unlock more organizational change than months of alignment meetings.
• Treating product development as a factory creates compounding speed and learning across launches.
• Small, senior squads outperform large teams when speed and accountability matter most.
• Co-design turns customers into buyers and removes most go-to-market risk before launch.
• A product is not done until sales can confidently sell it with the right narrative and tools.
• Strategic roadmaps should bend when rare, high-leverage opportunities appear.
• Cultural debt and technical debt grow quietly but compound just as fast as product velocity.

‍

My full video with Salim Jernite, CPO

Dive deeper into this topic with Salim Jernite, Chief Product Officer of Fountain, in my latest podcast episode:

Listen on podcast

Watch on Youtube

‍