Product Builder : quand les devs font du produit

Executive summary

Doctolib’s Pica team describes a shift in which developers take on more product ownership as AI accelerates implementation. Their “product builder” is a developer who leads a project, not a PM who primarily learns to code. The model builds on Doctolib’s existing rotating takeholder role and gives developers more responsibility for decisions and post-launch iteration.

The team’s experience suggests that faster coding alone does not speed up the whole product cycle: bottlenecks can move to scoping, decision-making, reviews, and coordination. Their response was to delegate reversible decisions, work in pairs, scope projects collaboratively, and judge progress by user impact rather than delivery alone.

Operating model and roles

• Doctolib has approximately 70 feature teams, generally led by a PM and an Engineering Manager (EM). Teams typically have about four developers; the Pica team has five.
• Pica has no dedicated Product Owner:
  • The PM retains discovery, priorities, and preparation of future work.
  • The EM sets the framework, coaches product builders, and follows project progress.
  • The product builder leads a project, coordinates technical scoping, writes or organizes tickets, raises dependencies, and makes agreed-upon product decisions.
• The role rotates by project and quarter. The team also rotates product areas and pairs people across them to reduce silos and avoid relying on only one person to know a feature.
• A buddy supports each product builder, particularly with reviews and cover during leave or absence. The team moved away from assigning one person to work entirely alone on a project.

Processes and playbooks

Flow-based delivery rather than sprints

• The team uses Kanban-style flow and does not plan work around sprint start and end dates.
• Historically, tickets were broken down so they could generally be completed in under two days. Small tickets reduced ambiguity and helped the agents succeed on their first attempt.
• The team uses ticket counts and its observed weekly throughput to forecast project timing, rather than relying on sprint velocity.

Impact-oriented goals

• Teams still make quarterly commitments through OKRs and KPIs.
• Product builders are encouraged to commit to an intended user impact—for example, whether a defined share of users adopts a feature—not just to shipping by a deadline.
• Developers are encouraged to examine product analytics, identify where users drop out of a funnel, and iterate.

Decision-making by reversibility

• Developers can make decisions when they are easy to undo, such as reverting a change or turning off a feature flag.
• Where there is uncertainty, the team can test alternatives through A/B tests or production experiments.
• Irreversible or higher-consequence decisions are held for team discussion.
• The team reported only two reversions across two quarters, which it viewed as evidence that experimentation was manageable.

Scoping day

• The PM, product builder, buddy, EM, and—when possible—a lead user work together for a full day.
• The PM opens with the users, their needs, and the problem; the group identifies questions and explores solutions.
• The discussion is transcribed. Claude summarizes the context, user stories, and open questions around lunchtime.
• In the afternoon, the group reviews and resolves questions, involving the lead user where useful. For medium-sized projects, the team may finish with a viable functional and technical solution and an initial breakdown of tickets.
• The aim is to replace a technical-scoping phase that could take weeks with shared context and faster project kickoffs.

Team alignment and learning rituals

• Daily stand-ups review progress, blockers, and priorities, with flexibility to reprioritize.
• A weekly working-methods meeting shares AI practices, discusses friction, and identifies improvements.
• A management meeting between the PM, EM, and managers is used to resolve escalations and make decisions.
• The team reviews its roadmap every two weeks, even without running sprints.

Psychological safety

• Leadership explicitly encouraged experimentation and acknowledged the right to make mistakes.
• The team treats the product-builder responsibilities as a change in role—not an expectation of simply adding more work. Time saved through automation is redirected to joint problem-solving and project strategy.
• Team members are encouraged to raise uncertainty, workload, and prioritization problems early.

AI and product execution

• Doctolib’s Autopilot connects Slack, Jira, GitHub Actions, and Claude-based agents to move from a stated intention to a pull request.
• In the example shown, a request in a Slack channel leads to a Jira ticket with context and acceptance criteria. An agent then opens a pull request, runs tests, requests reviews, responds to comments, and can make corrections.
• A second agent reviews the first agent’s work using a different setup, creating an initial feedback loop before a developer reviews the result.
• Developers are expected to supervise and redirect agents, build safeguards or “harnesses,” and check evidence such as test results and visual regressions—not blindly trust generated code.
• Better-performing models and improved testing increased first-pass success, allowing the team to give the agent larger, user-story-sized tasks and have it identify dependencies.
• Adoption was still uneven across developers, and the team noted that ambiguous tickets could send the agent down the wrong path.

Metrics and timelines

• The change followed a CTO’s call for Q2 to be an experimentation quarter, with permission to test new ways of working and learn from mistakes.
• In Q2, the team tried starting three projects in parallel, rather than sequencing one large project and a secondary project. This accelerated some work but exposed problems with context switching, PM workload, and developers working alone.
• By the time of the presentation:
  • About 50% of tickets were going through the agent.
  • Roughly 70–80% of tickets had the label that made them eligible for agent processing.
  • The team said that more than 50% of delivered work was agent-produced by October.
• The team planned to focus in Q4 on getting developers to use product analytics more actively to identify opportunities for iteration.
• The team described using 15–20% of capacity for technical debt when there is no suitable product topic ready, rather than filling time with unprioritized work.

Challenges and lessons

• Parallelizing projects too aggressively increased context switching and left some developers isolated with decision-making responsibility.
• Faster implementation did not eliminate upstream work: scoping, cross-team dependencies, design, compliance, and localization still mattered.
• The team addressed isolation with buddy reviews and pair work, accepting that buddies may have less context while ensuring they can step in when needed.
• The PM’s time is better spent on discovery and preparing the next valuable problems than translating every request into tickets.
• The model is context-dependent. The team said its internal-user focus permits more improvisation than some customer-facing work.

Hiring and design implications

• Doctolib does not recruit for a dedicated “product builder” job title; it continues to hire PMs and software engineers.
• It favors generalist engineers where the team’s needs allow, and looks for user orientation, product thinking, business understanding, and the ability to connect delivery to measurable impact.
• Interviews use concrete situations rather than relying only on candidates’ self-reported examples—for instance, asking when they proposed a feature and how they measured its user impact.
• Design was not fully integrated into the team’s routine scoping process yet. The speakers suggested involving designers in scoping, particularly for user-facing work, and highlighted design-system assets and AI-assisted mockups as ways to accelerate iteration.
• Legal and compliance input may be needed for work involving KYC, while localization across French, German, and Italian is an important delivery consideration.

Actionable takeaways

• Start with a team whose communication and delivery practices already work; do not treat a new role as a substitute for strong foundations.
• Give developers bounded ownership, with clear rules for reversible versus team-level decisions.
• Pair project leads with buddies to reduce isolation and protect continuity.
• Use small, clear work items where agents are less reliable, and expand task size as their performance improves.
• Bring PMs, engineers, and users together early to shorten scoping and share context.
• Measure outcomes and user behavior—not only deadlines and completed tickets.
• Make experimentation safe, but require evidence such as tests, analytics, and user feedback before treating AI-generated work as successful.

Presenters and sources: Céline Forestier (Product Manager, Doctolib); Julien (Engineering Manager, Doctolib); Alexandre, host from TPC; TPC livestream featuring the Pica team’s Doctolib experience.