What 2025 taught me about Product, AI and building companies

As 2025 comes to an end, I wanted to pause for a moment and look back.

Last April, I launched How They Build with a simple ambition: go beyond surface-level advice and really understand how great teams build products, make decisions, and operate when things are uncertain.

‍

Since then, I’ve published 20 in-depth company analyses, all drawn from long-form interviews with founders and Product leaders. I also spent weeks working on a full documentary in San Francisco, talking with teams building at the very edge of AI, product, and company building.

That’s hundreds of hours of conversations, note-taking, rewriting, and pattern-spotting.

In this edition, I wanted to step back and share my biggest learnings from this year.

The patterns that kept coming up again and again across these interviews. The lessons that genuinely changed how I think about product, AI, leadership, and execution.

It’s also a way to help you (re)discover episodes you might have missed along the way, and to connect dots between stories that can look very different at first glance.

These learnings come from conversations with founders and product leaders building across very different contexts. Here are the articles referenced throughout this newsletter:

• OpenAI — Romain Huet, Head of Developer Experience
• Linear — Adrien Griveau, Founding Designer
• Qonto — Didier Hilhorst, VP Design
• Nabla — Alexandre Lebrun, CEO
• Veed — Samuel Beek, CPO
• Pennylane — Arthur Waller, CEO
• Hyperline — Lucas Bédout, CEO
• Pictarine — Guillaume Martin, CEO
• Tomorro — Antoine Fabre, CEO
• How to prioritize Product with 4 proven methods
• Why more startups start with a Product Designer first

I hope this synthesis helps you reflect, challenge a few assumptions, and head into 2026 with a slightly sharper mental model of what really matters when building products.

Thanks for reading, supporting the project, and sharing your feedback all year long.

I wish you wonderful end-of-year holidays, some well-deserved rest, and a great start to the year ahead. 🎄✨

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

‍

1) Time to value is about belief, not speed (from Hyperline)

In my interview with Hyperline’s CEO, Lucas Bédout, one lesson stood out more than anything else about time to value.

Shortening time to value is not about making the full product faster. In complex B2B software, that goal is often unrealistic. Billing, finance, and RevOps workflows take time, and users expect that. The real mistake is confusing time to completion with time to conviction.

What Hyperline realized is that the real leverage comes from extracting small, independent pieces of value from a complex product and letting users experience those first. Instead of forcing users to finish setup before seeing anything useful, they designed the product as a staircase of tiny value moments. Each step delivers an immediate insight, like seeing ARR, burn, or customers, with minimal effort.

Those moments do not replace the core workflow. They make it feel worth completing. By the time users reach the “real” job to be done, they are no longer lost or hesitant. They are already convinced.

The takeaway I’m carrying into 2025 is simple: time to value is about creating early belief, not early completion. Products that win are not the ones that rush users to the finish line, but the ones that give them a reason to keep going.

-> How Hyperline cut Time-to-Value by 8 with Better Onboarding

‍

‍

‍

‍

‍

‍

2) AI adoption is a trust problem, not a feature problem (from Tomorro)

What Tomorro proved with its new product named Oro is that AI adoption in B2B is not a marketing or packaging problem first. It’s a trust problem.

They did not rush to sell an AI assistant as soon as LLMs became available. Instead, they spent most of 2024 in near silence, obsessing over one thing: reliability. They accepted that as long as the AI was not clearly better than a human, users would double-check everything, and the product would never become indispensable.

The real breakthrough came when they crossed a quality threshold. Moving from ~50% to ~95% accuracy in contract data extraction fundamentally changed user behavior. Users stopped verifying outputs. AI shifted from “tool you test” to “teammate you rely on”. Only then did monetization make sense.

That’s why the conversion was so strong. About 25% of existing customers paid for Oro within 2 months, not because of clever pricing or aggressive sales tactics, but because the value was already proven in daily workflows. Selling became a formality.

The deeper takeaway is this: AI strategy is not about speed to launch, it’s about speed to trust. Until trust is there, distribution, pricing, and growth tactics are just noise. Once trust is there, monetization follows naturally.

If Hyperline taught how to create early conviction in a product, Tomorro shows that with AI, conviction only comes after sustained proof.

-> How Tomorro scaled a new AI feature to €200K in just 2 months

‍

‍

‍

‍

‍

‍

3) Reclaim control before you try to scale (from Pictarine)

In my interview with Pictarine’s CEO, Guillaume Martin, one lesson stood out as a powerful reminder of where real growth leverage often hides.

For years, Pictarine had a great product and strong demand. Users loved the experience. Volumes were there. But growth had a ceiling they couldn’t break, not because of the product itself, but because of a structural constraint: they didn’t control pricing or payment.

Customers paid in-store. Partners set the prices. Pictarine took a commission.

As a result, they couldn’t bundle, experiment, differentiate pricing, or fully fund innovation. Any new feature had to fit inside someone else’s pricing grid.

The growth unlock didn’t come from shipping more features. It came from moving payment into the app and reclaiming control over the transaction. Once Pictarine owned pricing and checkout, everything else followed: better margins, premium features, new offers, stronger branding, and faster iteration.

What’s striking is how often teams overlook this. They push harder on product while leaving core economics untouched. Pictarine did the opposite. They fixed the foundation first.

The transferable insight is simple but uncomfortable:

If you don’t control pricing and payment, you don’t really control your product strategy.

Growth plateaus are often structural, not creative. And the fastest way to unlock them is not to build more, but to take back ownership where value is actually captured.

-> How Pictarine 4x’ed its revenue in 3 years by shifting the payment model

‍

‍

‍

‍

‍

‍

4‍) Founder-mode works only if “what” and “how” aren’t mixed (from Pictarine)

As Pictarine grew from a tight 30-person team to more than 80 people, they hit a familiar scaling wall. Teams were busy, but alignment was fading. People worked hard, yet struggled to see how their work connected to the bigger picture.

The issue wasn’t talent or effort. It was blurred ownership.

Guillaume (CEO) didn’t respond by stepping back into classic “manager mode”. He did the opposite. He leaned into founder-mode, but with a critical adjustment: clearly separating who owns what from who owns how.

At Pictarine:

• Founders own the what: vision, direction, long-term bets.
• A dedicated operations layer owns the how: execution quality, product management, performance, rituals.

They even went as far as removing the traditional centralized “product team”, making the entire company product-driven, with product management embedded in execution rather than acting as a layer in between.

This is what made founder-mode scalable. Guillaume stays deeply involved in strategic areas like product and AI, but without micromanaging delivery. Teams are encouraged to challenge him. Vision is explicit. Execution is trusted.

The broader lesson is not “founders should do everything”. It’s the opposite:

Founder-mode breaks when vision and execution are mixed. It scales when they’re clearly owned by different people.

When everyone knows who decides direction and who ensures performance, speed and clarity go up at the same time. That’s how Pictarine managed to move fast without losing alignment.

‍

5) Bugs are a velocity choice, not a quality failure (from Pennylane)

In my interview with Pennylane’s CEO, Arthur Waller, one counter-intuitive lesson stood out around bugs and product quality.

‍

Pennylane ships fast. Very fast. And as a result, they tolerate a level of bugs that would be unacceptable in many other companies. This is not accidental. It’s a deliberate tradeoff.

Pennylane is rebuilding an entire category. Accounting software, banking, payments, invoicing, regulatory infrastructure, all inside a single product. At that level of ambition, waiting for perfect polish would mean never shipping at all.

Arthur explains that some companies optimize for near-zero bugs, and that choice defines their velocity. Others, like Pennylane, accept a higher bug count to keep expanding the surface area of the product. What matters is not eliminating bugs, but containing their impact.

That’s why Pennylane invests heavily in:

• Clear prioritization between critical and non-critical bugs
• Dedicated “firefighting” teams during fiscal deadlines
• Fast response times when bugs affect accountants or closing periods

The goal is not stability at all costs. The goal is controlled instability.

Arthur even references Booking’s philosophy: if teams ship and there are no bugs, it often means they’re not moving fast enough. In that context, a low bug count can be a false signal of quality.

The deeper takeaway is this: bug strategy must match product ambition.

A narrow, polished product can and should aim for near-zero bugs.

An infrastructure-level product cannot. Trying to apply the same standards would slow execution to a crawl.

Pennylane chose speed, accepted the consequences, and built systems to absorb them. That choice is a big part of why they’re able to move at their current pace.

-> How Pennylane hit 400k Clients by betting on a new product

‍

‍

‍

‍

‍

💫 A quick note on Stellar

Alongside How They Build, I spent this year building Stellar.

Stellar is a Product & Engineering advisory firm working with CEOs of European software companies (50–500 people) whose teams struggle to ship fast, prioritize clearly, and turn product work into predictable revenue impact. We help teams regain focus, velocity, and efficiency through a Revenue-First Product Development operating system, shaped by elite CPOs and CTOs and proven across 80+ software companies like Timeleft, Dayuse, and ManoMano.

‍

Looking ahead to 2026

If you’re leading a software company and want to fix prioritization, velocity, or product impact issues before they repeat next year, I offer 30-minute strategic calls to help diagnose the real bottlenecks and clarify what to fix first.

Book a 30-min strategic call

‍

6) Win one segment before expanding the market (from Linear)

In my interview with Adrien Griveau, Founding Designer at Linear, the most defining growth lesson was not about features or design polish. It was about who the product was built for, and when.

Linear never tried to serve all teams at once. Instead, they followed a strict sequencing strategy inspired by Slack: win one customer segment completely before moving to the next.

They started with very small teams, roughly 1–20 people. These teams were easy to onboard, quick to adopt, and didn’t require heavy sales or custom workflows. Linear optimized everything for them: self-serve onboarding, defaults, performance, and simplicity. Only when this segment was truly delighted did the team move upmarket.

This progression continued step by step: 20–100 people, then 100–500, then 500+. Each expansion was deliberate, timed, and backed by product readiness. Importantly, Linear resisted the temptation to chase large customers too early, even when those customers were already knocking on the door.

“Convincing a 20-person startup was much easier than convincing a 300-person company.” Adrien Griveau

Requests from larger teams were acknowledged, logged, and backlogged, but they didn’t dictate the roadmap prematurely. The risk was clear: building for the wrong segment too early would bloat the product, slow execution, and compromise the experience for the users Linear was actually trying to win.

The transferable insight is simple but rare in practice:

growth compounds when you sequence customers instead of widening the market too early.

Linear expanded its total addressable market not by dilution, but by depth. Each segment became a stable foundation for the next.

‍

7) Speed comes from focus, not from moving faster (from Linear)

Linear’s execution speed didn’t come from large teams, aggressive marketing, or endless parallel initiatives. It came from clear, time-bound missions.

Every 6 months, Linear defined a single objective tied to a specific customer segment. That mission acted as a filter for every decision across product, design, and marketing. The question was always the same: does this help us win this pool right now?

Anything that didn’t fit the mission was explicitly labeled a “side quest” and pushed to the backlog. This wasn’t about saying no forever. It was about saying “not now”, with discipline.

This approach created clarity at every level. Teams didn’t waste time debating priorities or reacting to the loudest feedback. They knew what mattered for the next 6 months and optimized relentlessly for it. Each mission culminated in a major release, with a dedicated landing page and narrative, reinforcing momentum internally and externally.

The key insight is counter-intuitive: velocity is not a function of speed, but of constraint.

By reducing the number of things teams were allowed to work on, Linear made execution obvious. Fewer choices meant faster decisions, fewer trade-offs, and higher quality outcomes.

Instead of running faster in every direction, Linear narrowed the path so progress became inevitable.

-> Linear’s Playbook for building a world-class Product

‍

‍

‍

‍

‍

‍

8) The first product hire sets velocity, not process

One of the clearest lessons from recent conversations with founders at Hyperline, Lago, and Linear is that the first product hire is less about organization and more about momentum.

At the earliest stages of a startup, the biggest risk is not misalignment. It’s stagnation. Teams don’t fail because they lack process, rituals, or roadmaps. They fail because ideas take too long to turn into something real.

That’s why more founders are choosing their first product hire based on shipping power, not role definition.

Historically, the default choice was a Product Manager. Someone to structure, prioritize, and coordinate. But many founders now see this as premature. When the product is still fluid and the problem space is still being explored, adding coordination often slows things down instead of accelerating them.

What these founders are optimizing for is velocity: the ability to ideate, prototype, test, and ship in tight loops. Product Designers, Product Engineers, or hybrid profiles tend to excel here because they work directly in the craft. They don’t just discuss the product. They materially push it forward.

The underlying shift is not anti-PM. It’s anti-abstraction too early.

Early teams need people who reduce the distance between an idea and a shipped feature. Process, ownership models, and formal discovery frameworks matter later. At the beginning, they often create drag.

‍

This is also why the designer-first approach only works when a founder truly owns Product end to end. Without a clear product anchor at the founding level, any first hire risks becoming a coordinator by default. Velocity collapses when no one is accountable for decisions and quality.

The transferable takeaway is simple:

your first product hire should make the product move faster, not make it cleaner to talk about.

Structure can wait. Momentum can’t.

-> Why more startups start with a Product Designer first

‍

‍

‍

‍

‍

‍

9) Product-market fit is often found by removing, not adding (from Nabla)

In my interview with Alexandre Lebrun, CEO of Nabla, the most important lesson wasn’t about AI, healthcare, or even pivots. It was about subtraction as a product strategy.

Nabla didn’t start small. They started broad.

Patient records, messaging, prescriptions, video consults — a full “Care Platform” designed to modernize healthcare workflows. The product was technically impressive, well-designed, and backed by strong engineering talent. Yet adoption stalled.

Despite years of work and millions raised, Nabla hit a ceiling at around 10 small customers. Usage was shallow. Expansion was unclear. Adding more features didn’t help. It only increased complexity.

The breakthrough came when Alexandre asked a brutally honest question every founder should ask:

“If we were starting from scratch today, what would we build?”

The answer wasn’t another iteration of the platform.

It was one feature buried inside it: an AI assistant that automatically wrote medical consultation notes.

Nabla made a radical decision. They killed 80% of the product and rebuilt everything around that single workflow. Within weeks, adoption validated the choice. Doctors didn’t need a new system. They needed something that saved them time today, without changing how they worked.

This is the key insight:

when adoption is weak, the problem is rarely that the product is too small. It’s that it’s too big.

Breadth masked the absence of pull. Focus revealed it.

Nabla didn’t find product-market fit by listening harder or building more. They found it by cutting until only the undeniable value remained — the one workflow users would fight to keep.

Subtraction wasn’t a reset.

It was the fastest path to clarity, conviction, and growth.

-> How Nabla dropped 80% of its product and found PMF

‍

‍

‍

‍

‍

‍

10) Prioritization is a leadership problem before it’s a product problem

One idea keeps surfacing across Pennylane, Hyperline, Linear, and Danim: strong product teams don’t prioritize better because they use better frameworks.

They prioritize better because they understand what they are optimizing for right now.

There is no single “correct” prioritization method. Sometimes the strongest signal comes from users, like Arthur Waller spotting overwhelming demand for a feature through a simple LinkedIn post. Sometimes it comes from fast experiments, like Hyperline testing demand with fake menu items or Linear discarding 90% of prototypes to uncover the few that create real impact.

But user demand alone is never enough.

At other moments, discipline matters more than responsiveness. Danim deliberately killed features loved by a vocal minority because they conflicted with the product’s promise of simplicity. Linear postponed requests from large customers because they didn’t fit the current segment they were trying to win. Pennylane anchored decisions to clear company-level priorities, even when attractive ideas surfaced elsewhere.

The common thread is not the method. It’s the judgment.

Great prioritization happens when teams continuously resolve the tension between:

• User signals (what people ask for and react to)
• Product vision (what the product should stand for)
• Business strategy (which customers and outcomes matter now)

The mistake many teams make is treating prioritization as a scoring exercise. Frameworks like RICE or ICE don’t make decisions for you. They only structure conversations. The real work is deciding which constraint deserves priority at this moment in the company’s life.

That’s why prioritization is fundamentally a leadership problem before it’s a product problem. When strategy is clear, tradeoffs become obvious. When it isn’t, no framework will prevent roadmap chaos.

The transferable takeaway is simple:

Great prioritization doesn’t come from ranking ideas better, but from knowing which signal to trust right now.

And that choice evolves as the company grows.

-> How to prioritize Product with 4 proven methods

‍

‍

‍

‍

‍

‍

11) AI fails when it’s treated like an add-on (from Veed.io)

One of the most important lessons from my conversation with Samuel Beek, CPO of Veed, is that AI only becomes a growth driver when it forces you to rethink the product itself.

At first, Veed did what many companies do: it added AI features on top of an existing workflow. Automatic subtitles, background removal, avatars. These features improved the product, but they didn’t change the growth curve. Adoption remained incremental.

The turning point came when the team realized the issue wasn’t demand. It was design.

As long as AI lived inside a traditional video editor, users still faced the same core problem: they needed footage to begin with. Editing assumed something already existed. AI was accelerating the wrong step.

Growth unlocked when Veed stopped enhancing the old journey and replaced it.

‍

With the launch of GenAI Studio, Veed flipped the workflow entirely. Instead of editing videos, users could generate them from scratch using text prompts. This solved the hardest barrier in video creation: the blank canvas. Within months, half of all exported videos on Veed were AI-generated, and the product started attracting users who had never edited a video before.

The lesson is subtle but critical: weak AI adoption often isn’t a signal of weak demand. It’s a signal of a mismatched workflow.

Early failures with avatars led the team to believe there was no market. In reality, the feature was trapped inside an experience designed for editing, not generation. Once Veed built purpose-made AI surfaces, demand became obvious.

This pattern repeated across their growth bets. Viral features worked when transformation was instantly visible. Hackathons paid off when they explored new journeys, not incremental improvements. Model integrations drove traffic because Veed offered the simplest way to experience new capabilities, not just another toggle in a complex tool.

The transferable takeaway is clear:

AI doesn’t create growth by decorating existing products. It creates growth when it redefines what users come to the product to do.

Treat AI as an add-on, and it will behave like one. Treat it as a new starting point, and it can reshape your entire growth trajectory.

-> How Veed.io turned AI into its biggest growth driver

‍

‍

‍

‍

‍

‍

12) AI collapses roles, so execution beats coordination

One of the strongest patterns I observed across teams at Rippling, Gamma, DeepMind, Vercel, Revo, and others is that AI is quietly dismantling traditional role boundaries.

‍

In many European teams, work is still organized as a linear chain: PM writes the spec, designer produces mocks, engineer implements. AI breaks that model. Not because job titles disappear, but because capabilities spread across roles.

Designers now prototype directly in code.

PMs test technical feasibility themselves using Cursor or Claude.

Engineers reason more deeply about product intent and user experience.

AI acts like a super-capable intern that everyone can delegate to. The result is not replacement, but elevation: people move one level up, focusing more on judgment, intent, and outcomes.

Across interviews, the same shift came up again and again. Teams no longer wait on handoffs to move forward. Prototyping, scoping, design, and engineering happen together, in tight loops. Product development becomes circular instead of sequential.

This has a profound consequence for how teams operate:

coordination is no longer the bottleneck.

When everyone can test ideas themselves, the limiting factor becomes decision quality. What to try. What to discard. What deserves attention now.

That’s why these teams invest less energy in process and more in clarity:

• clear constraints
• explicit guardrails
• strong product taste
• shared understanding of what “good” looks like

The mistake would be to interpret this as “roles don’t matter anymore.” They still do. But their borders are softer, and their value shifts from execution ownership to decision-making and prioritization.

The transferable takeaway is simple:

in AI-native teams, speed doesn’t come from better coordination, but from empowering individuals to execute end-to-end.

As AI collapses roles, leadership and judgment rise to the surface.

-> 8 Lessons from Inside Silicon Valley’s AI Product Teams

‍

‍

‍

‍

‍

‍

That’s it for this year’s edition of How They Build.

If even one of these learnings helps you make a better product decision, avoid a wrong turn, or move a little faster with more clarity, then this work was worth it.

Thank you for being part of the journey. I’ll see you in 2026, with new conversations, new patterns to uncover, and plenty more to build together 🫶🏽

Timothe

‍