This article is an in-depth summary (I know, ironic) of an interview with Dominique Jost, Head of Product at Doist. You can watch the full interview ​on YouTube​.

Enjoy, and as always: Reach out with your thoughts, questions, comments.

—

Most companies I've spoken to for this series started thinking about AI 2-3 years ago. Doist’s first internal memo about AI dates from 2016.

I sat down with Dominique Jost, Head of Product at the company behind Todoist and Twist. 110 people, fully remote, and fully self-funded. A company that has been growing on its own terms for two decades.

Ten years ago, Amir Salihefendic, Doist's CEO and founder, wrote a piece about what he saw as the foundational pillars of the company's future. One of them was AI. Even back then, he already saw it as something that must be core to any productivity tool in the market. Ten years ago, there were still no tools to make his vision a reality. But when ChatGPT and other LLMs arrived, Doist finally got the technology to match a mindset they'd had for years.

From Mindset to Reality: The Slow AI Adoption at Doist

Despite being culturally prepared, the AI adoption at the company wasn’t immediate.

Dominique describes it as a classic change management curve. The first challenge wasn't intellectual - nobody at Doist was arguing that AI wasn't worth exploring. It was simply the nature of change and humans being resistant to it. The new tools were still clunky and expensive. The use cases weren't obvious. And the early examples flooding LinkedIn and the internet were almost exclusively about engineering, meaning that adoption across wider functions was even harder.

So how did they push it forward in those early days? By showing, not mandating.

Amir, who still writes backend code every single day, led by example, using AI tools in his workflows. Then, someone would discover something useful, share it in a five-minute lightning talk, and a few more people would try it. There was no formal upskilling program or company-wide rollout, just an organic, steady movement.

This initial phase took about two years. Six to twelve months ago, the first non-engineers started using AI tools for something beyond editing copy. That was the turning point.

The Product team was one of the first non-technical teams to venture into it. In Q2 2025, Dominique set a goal: by the end of Q3, the team would have shipped one feature end-to-end. He didn’t even define what feature it should be, as long as it would be deployed to production.

What followed was what you would expect from any non-technical team trying to code: struggling with setting up local development environments, deciphering documentation written by engineers, and getting lost in the terminal.

The remote-first culture at Doist means the company has extensive documentation. But that had always been written by engineers, for engineers, which meant it was dense and hard to follow for everyone else. PMs used ChatGPT to decode that documentation and re-wrote it from scratch in language anyone could follow. They literally called it “instructions for dummies.”

"I think now our instruction is the official instruction because even the engineers had to admit that it makes a bit more sense”

said Dominique.

The feature was successfully deployed ahead of time, and they recorded the experience throughout, sharing it with the rest of the company as a series of Looms. The message they wanted to convey: if we can do this, so can you.

One thing that made this possible was the support of the Engineering team. In my other conversations in this series, several leaders reported engineers initially being against other people touching the code base. That resistance became something they had to overcome first. Not at Doist. The CTO and the broader engineering organisation were completely supportive: PMs raise pull requests, engineers review them, give feedback, and teach.

How Doist Works Now

The core process of how Doist builds products hasn't changed.

Dominique describes it as a “pretty boring double diamond”, and he means that as a compliment.

What has changed is the nuance inside of it and, to some extent, who gets to do what.

The most visible change is speed. Tasks that used to take a week now take a day. Synthesising research, writing specs, analysing data… all that individual work has compressed, leaving more time for the actual thinking.

But speed is almost the least interesting part of the story. The more fundamental change is that everyone on a squad now has the ability to act directly on the product.

PMs prototype in the source code rather than describing what they want in a spec, hoping engineers will interpret it correctly. Designers build directly in the product in their local environments. When someone spots a bug mid-sprint, they don't open a ticket and wait, they fix it themselves. When the copy is wrong, whoever notices it can correct it. The small, low-hanging fruits that used to queue up for an engineer are now handled by whoever spots them and is willing to handle them.

As an example, in a recent squad meeting, Dominique's team was reviewing which features still lacked CLI and public API support (urgent now that agents need to be able to use your tools, or you risk becoming invisible to them). The task had been assigned to the backend engineer, but the designer asked if he could take on the CLI work himself. The customer support rep in the squad asked if he could jump in too. The engineer who'd been assigned the task was delighted.

"Every week, something new happens where I just go: I really love my team,”

Dominique said.

The same fluidity has reached other functions. A customer support rep came to Dominique with a question a customer had raised: was a particular behaviour in the product a bug or intentional? Rather than answering, Dominique walked him through the process of getting a GitHub account, accessing the source code, opening Claude Code inside it, and figuring it out for himself.

That technique has since spread through the entire customer support team. The source code has become a resource anyone can query, and Claude Code is the interface they use to do it.

Opening the door for everyone to contribute creates its own challenge, though.

When 110 people have access to the source code and the tools to do something with it, the product team is still accountable for what ends up in production. Dominique is thinking carefully about how to direct that energy without blocking it. One idea currently in discussion is a pre-vetted backlog: a curated list of things the company knows are important but that aren't a current strategic priority. The goal is to have those available for anyone to pick them up and work on them, if they want, instead of working on other random tasks.

Interestingly, Doist doesn't track any metrics around AI adoption. According to Dominique, when a founder has been repeating the same message for ten years, it becomes part of the culture. You experience the benefits, but you don’t necessarily need data to know it is working.

Doist OS

The most original idea I heard in our conversation is something they're currently beta testing: Doist OS.

Most AI adoption focuses on individual leverage: you set up your personal assistant, your prompts, your workflows, and that works… for you. But if you work in a team, one highly leveraged person alone doesn't move the ball forward.

Doist OS is a shared GitHub repository that aims to improve that. When you open your agent inside it, it has access to everything: company strategy, vision, how the company communicates, etc. It's preconfigured with the full context of working at Doist.

The real power is in what that shared context enables. Anyone can build a skill (essentially a mini-agent that automates a specific task) and add it to the shared repository. From that point onward, every person at Doist has access to it.

Dominique gave an example: every Monday, each person at Doist writes a weekly snippet with what they achieved last week, what they're working on this week, and any risks or blockers. Someone wrote a skill that queries Twist and Doist's internal tools, pulls together the relevant information, formats it correctly, and posts it automatically. One person built it once, and now everyone has it forever. "If you have this common shared playground, every single skill you add is made available to everyone."

Dominique's Advice

When I asked Dominique what he'd tell a peer starting this journey today, his answer was: stop thinking about the engineers.

The reason is that they’re mostly capable of figuring it out themselves.

"If you're an engineer and you're not taking care of yourself, I think you'll be in trouble."

The real opportunity is everyone else. The customer success teams that have the highest touchpoint frequency with actual customers. The marketers, the finance people, the support representatives. People who know exactly why deals fall through and why users churn, but who have never had the means to act on that knowledge directly. AI, Dominique argued, changes that equation entirely, but only if someone opens the door for them.

His filter for who's ready: look for people who are curious, who know how to ask good questions, and who have ideas. Those three things are the real prerequisites, not technical background or proximity to the code.

"Give them space to explore, build the systems that catch mistakes before they become problems, and then prepare yourself to be amazed every single day.”

What I'm Taking Away

What stayed with me most was the relationship between patience and timing.

Doist had the AI mindset years before they had the means to act on it. But when the tools finally arrived, they still didn't rush. They took their time until it became the obvious next step rather than a forced one.

Doist’s success story was only possible because an entire organisation was willing to teach each other how to “catch fish” instead of catching the fish for each other. Engineers reviewed PRs and gave feedback instead of guarding the codebase. A PM team recorded their struggles and shared them as Looms. A customer support rep learned a new technique and passed it on to his whole team. It might seem like an expensive use of people's time. But the return shows up later in a customer support rep who no longer has to wait two days for an answer, or in a designer who can fix what he spotted without filing a ticket.

The other main idea I’m taking away is a pattern I’ve been spotting across almost every conversation in this series: in Doist, as in many other companies, the main processes haven’t changed. What changed is the specifics of how they do each task, the time it takes, and who gets to do what.

Which, depending on how you look at it, is either reassuring or the most disruptive thing of all.