How top startups under 100 people build Product without bureaucracy

In this special episode, I brought together 4 leaders who all scaled product teams in startups under 100 people: Adrien Griveau (Founding Designer at Linear), Lucas Bédout (CEO at Hyperline), Guillaume Martin (CEO at Pictarine) and Danyl Hassim (CEO at Danim).

Each of them faced the same tension: how do you keep speed, alignment and ownership when your company is growing but still far from the processes of larger organizations? Their experiences span remote teams, no-PM cultures, squads evolving as the company triples, and orgs where product becomes the operating system of the whole business.

I sat down with these 4 leaders to discuss how to structure and collaborate as a product team in a company under 100 people, and what others can learn from their approaches.

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! 😊

‍

Keep teams small and obsessed with outcomes, not rituals

Adrien Griveau explained how Linear operated with a radically lightweight rhythm while fully remote. Their setup relied on simple, predictable touchpoints and extremely high ownership within the team. They kept 3 weekly catch-ups, split their team into compatible time zones and gave every engineer and designer full leadership over their project.

“We’ve always had a strong ownership culture” as Adrien shared.

This ownership extended to shipping. Linear’s cadence was anchored by a weekly changelog, published to users by email every Wednesday or Thursday. That rhythm forced teams to focus on real outcomes: if something wasn’t ready for that week, it had to ship the week after. It pushed everyone toward rapid iteration rather than perfect planning. The changelog also doubled as an internal micro-roadmap. Instead of long-term speculation, teams could make decisions based on what they wanted customers to see next week.

Another essential insight: Linear deliberately prioritized fixing existing issues over adding features. A small bug that annoys users daily could become the reason they try a competitor. This mindset allowed the team to build momentum through small achievements, reinforcing trust and team speed.

The lesson for sub-100-person startups is simple: optimize for clarity and ownership, not ceremonies or processes. Rituals are only useful if they help teams answer the question “what did we ship that mattered?” As Adrien described, the goal is less about process fidelity and more about lighting a fire under teams to deliver meaningful progress every week.

‍

Remove the PM role to force product thinking across engineering

Lucas Bedout shared a radically different but equally powerful approach: Hyperline intentionally runs with no PMs at all. Developers own the entire lifecycle of features, from design questions to customer support. Lucas explained that introducing a PM often creates a dangerous dynamic where engineers defer responsibility, saying “oh no, that’s a Product problem” which he wants to eliminate.

With no PM in place, devs are pushed to deeply understand the business, customer context and tradeoffs. Every engineer does support shifts on Intercom every two weeks, meaning they feel directly the consequences of missing an edge case or misunderstanding a customer workflow. This increases accountability and drastically reduces gaps between teams.

The operating rhythm is weekly, not biweekly or monthly. There are no standups, no specs and no complex rituals. Every Friday, Lucas asks a single question: “What did you achieve this week?”
‍

‍
Focus on the value actually delivered, rather than on tasks completed or effort invested. This keeps the team laser-focused.

However, Lucas also acknowledges that this model won’t scale infinitely. At 25 or 30 developers, he expects PMs to reappear, with a very different mandate: business-first product thinkers focused on packaging, distribution, and long-term direction rather than traditional project management or writing specifications. This PM is closer to PMM than to classical PM.

The takeaway is powerful: sometimes the best way to create strong product culture is to remove intermediaries, forcing engineers to internalize context and impact. Only bring PMs back when they can elevate strategy, not manage execution.

‍

Make product the operating system of the entire company

Guillaume Martin shared how Pictarine faced an inflection point when crossing 60 people: loss of alignment, unclear contribution to the broader strategy and growing confusion on priorities. To fix this, they made a bold structural choice: they removed the entire product team. Instead, product became embedded into two new departments: design and operations.

Operations, led by François, owns the “how” of product management: rituals, execution quality, performance and process improvement. The founders (Guillaume and Max) own the “what”: the vision, direction and strategic choices. This separation lets each leader work in their zone of excellence.

Guillaume insists that he stays close to strategic product topics, particularly where deep understanding shapes the right decisions. He calls this operating in “founder mode”, meaning staying connected to the details that matter without micromanaging.

“The further you are from the details, the worse your decisions become” as Guillaume put it.

To avoid micromanagement, Pictarine relies heavily on trust and feedback culture. PMs are encouraged to challenge the CEO. Teams revisit their rituals regularly: weekly squad meetings with the PM and execs, plus a monthly review on whether the squad should continue, pivot or stop. Their guiding principle is simple: rituals must trigger real discussions, not status updates.

The key insight for startups: product is not a silo. When the company’s strategy is deeply tied to the roadmap, product becomes the backbone of the entire org. The structure must reinforce ownership of both vision (the what) and execution excellence (the how), with clear boundaries and mutual trust.

‍

Split product into focused domains as complexity increases

Danyl Hassim brought a different angle with Danim, where product complexity comes from heavy rendering infrastructure, AI components and a template studio. Their org naturally split into three domains: the product app, the R&D team (AI and rendering engine) and the studio that builds templates. Each domain reflects a core value stream for the product.

As the company grows, they’ve begun forming squads aligned with user journeys: creation, diffusion and performance. These squads combine product and tech roles depending on the feature. Danim recently hired their first PM and a UX designer, progressively moving from a founder-led product approach to a more structured model with clearer ownership.

Because their product relies heavily on deep tech (video rendering engine + AI), the R&D team operates somewhat separately while still supporting the rest of the product. This combination of domain-based teams for infrastructure and squad-based teams for user-facing workflows shows how startups can adapt their organization to fit the nature of the product rather than impose a cookie-cutter structure.

The lesson is clear: complexity should drive structure. When your product spans multiple technical layers, splitting teams by value streams or domains prevents bottlenecks and gives clarity on who owns what. Danim demonstrates that you don’t need a rigid model early on; you evolve your org as soon as the product’s shape becomes clear.

‍

Avoid fixed methodologies that prevent real discussions

One of Guillaume’s strongest takeaways is that fixed methodologies often harm rather than help performance under 100 people. Scrum, rigid ceremonies or standardized rituals tend to devolve into status updates, which signal that teams are no longer having real conversations.

“When a meeting turns into a status update, I think we’ve already lost” Guillaume emphasized.

Instead, squads must adapt their rituals to the problem at hand. For some teams, weekly cycles work. For others, monthly checkpoints. The only rule: teams should regularly revisit their operating system. At Pictarine, squads hold monthly evaluations on whether the structure still makes sense. Rituals evolve throughout the squad’s lifecycle based on needs, not dogma.

This flexible, reflective approach ensures teams keep the true goal at the center: high-quality decisions. Good rituals generate tension, debate and clarity. Poor rituals generate documentation and noise. The moment rituals stop creating value, they are changed or removed. This approach fosters autonomy, responsibility and continuous improvement.

For early-stage teams, this is a critical mindset. Under 100 people, your biggest enemy is overly formalized processes that disconnect teams from reality. The best orgs design rituals as tools, not rules. They evolve them as the product evolves, keeping alignment and velocity high.

‍

• Small teams with high ownership outperform rigid squads when speed matters under 100 people.
• Weekly shipping cadences (like Linear’s changelog) create natural focus and force meaningful progress.
• Removing PMs early can build stronger product intuition in engineers by eliminating responsibility gaps.
• Engineers doing support regularly creates powerful accountability loops that improve product quality.
• PMs should only be added when they meaningfully contribute to business direction, not engineer coordination.
• Product should align the entire company when the roadmap is tightly linked to strategy.
• Separating “what” (vision) from “how” (execution excellence) clarifies responsibilities as a startup scales.
• Founder involvement in details is valuable when it informs strategic clarity without drifting into micromanagement.
• High-trust cultures allow ICs to challenge CEOs and prevent harmful top-down decision patterns.
• Domain-based teams make sense when you have deep tech layers like R&D or rendering engines.
• Squads organized around user journeys help maintain clarity as product surface grows.
• Adaptive rituals outperform fixed methodologies because they evolve with team needs.
• Monthly evaluations of squad performance help prevent drift and preserve alignment.
• Status-update meetings are a sign that rituals are failing and must be redesigned.
• The best orgs under 100 people minimize process and maximize conversations and ownership.

‍

My video (in french 🇫🇷) about product team organization

If you enjoyed this edition of How They Build, I took a deeper, unfiltered dive into the topic in my latest YouTube video. For now, this new raw video format is only available in French. But let me know if you’d like to see it in English.

Watch on Youtube

Also available as a podcast (French for now):

Listen on Podcast

‍