There are five of us, three of them developers. This year we completed 42% more issues than last year and answered 388 customer requests from nearly 100 organizations. All while the engineering team welcomed two babies, which meant several months of leave.

Last year, we shared our method: unanimous or nothing. We've kept that principle. But we no longer vote on the same things, and AI agents now play a very different role in our code. Which raises the question every product team is asking right now: when AI speeds everything up, what's left that's actually our job?

Our answer fits in one line: AI speeds up execution, not decisions.

Three tracks: fix, polish, cut

Quality comes first. Bugs flagged by our monitoring tools and by support jump the line and get handled as they come in. On Wednesdays, the team leans into fixes, so no one forgets that's the priority.

Next come the small improvements customers ask for. They take a few minutes or a few hours, no vote needed, and they polish the product like a diamond. "Whenever I spotted something off and sent feedback, it was fixed within 24 hours. That's royal treatment," says Yacine Benameur, construction administration engineer at Unanime Architectes.

Then there's the vote. Every six weeks, it picks the bets that cut a new facet of the diamond. Each one is roughly two weeks of work for one developer. What ties the tracks together is the underlying problem: when several requests point to the same problem, it becomes one line among the 1,000 topics.

From 1,000 topics to 100: preparing the vote

Our list has changed shape four times. First, features sorted by stage of the customer journey. Then a column for each key customer, to give each one its true weight, until we had a 765-row matrix nobody voted on seriously anymore. Then 100 rows prepared with AI, each scored for impact and confidence. Today, we don't vote on features. We vote on well-framed problems, with the expected outcome and the reason to act now.

Before each vote, I rebuild the list of 1,000 topics on my own, with AI, and narrow it down to 100. I cross-check:

• past votes: why some topics made it and others didn't (problem framing, expected outcome, timing);

• issues closed in Linear, with their wording and size, to calibrate the granularity of the new list;

• the voice of the customer: support tickets, sales and customer success calls, emails, to get a feel for what's on people's minds and borrow their vocabulary;

• actual usage, feature by feature, to spot what's working and what isn't;

• what we keep an eye on: technical libraries, horizontal B2B SaaS and AI by product area, contech, and our customers' industry;

• strategy: deals that could accelerate the roadmap, board decks, and product direction.

I rewrite the topics, then rank them with several scoring methods, like RICE. It's how I stay close to the product and to customers. Then, together, we go from 100 to 10.

From 100 to 10: the vote

Every six weeks, on a Monday from 9:00 to 10:30 a.m., all five of us set the product commitments for the cycle.

1. The briefing: I walk through new constraints and a ranked Top 100.

2. The vote: everyone tags each line Now, Next, or Later, with a reason if they want (value, timing, scope, evidence, capacity).

3. The sort: Now is worth 2 points, Next 1, Later 0. Ten to twelve topics come out unanimous.

4. The review: we check that we all understood the same thing and size the effort from XS to XL. An XL gets dropped or split.

5. The pick: each developer takes three topics, sharpens their scope, and puts them in order.

6. The plan: we choose the target plan and write the feature the way it'll appear on the pricing page.

Scores reset at every vote. A topic that keeps scoring low is badly framed, so we rewrite it. A topic that rises, drops, then rises again is usually just a fad.

At the last vote, 11 topics were unanimous, and the team logged 293 "not now" reasons. Timing came first (83), ahead of evidence (72), value (70), and capacity (56). Scope came last (12). We disagree about the "when," rarely about the "what."

When we do disagree about the "what," the problem needs more discovery. That's how the proof PDF was born. We couldn't figure out why some users downloaded the PDF only to send it by hand from their email. Interviews surfaced several problems behind that one habit, and we were able to tackle some of them.

Ten bets: two weeks, one video

We call them bets because a problem always has several solutions, and each solution several ways to reach the user. So a developer doesn't disappear into a tunnel for two weeks. In week one, they present their solution in a short video and gather the team's feedback. In week two, they fold that feedback in and dig into the most promising direction. That's where the team learns by building.

AI in the code: output isn't the product

The big shift this year came from the code. Tickets are now written to be handed off to AI agents, and a human reviews the work.

Agents changed the heavy lifting first. Migrating a UI component library meant going back over a large share of the codebase: tedious work that dragged on for months and left the product with two styles. Now developers kick it off themselves, no sign-off needed. Foundational work (tests, tooling, migrations) has more than tripled, bugs fixed have nearly tripled, and quality is going up. Linear sees the same thing at a bigger scale: its agent fixes more than a thousand tickets a month, mostly small issues. Hard problems are still hard.

And it's speeding up. Last week, the team closed 81 issues, nearly double its September pace. Half were resolved less than a day after they were created. It won't slow down anytime soon, for two reasons. Frontier models get better with every release, in both performance and cost. And we're learning to orchestrate agents better, automate our loops, and design with AI.

Yet our changelog still lists one or two new features a week. What went up is improvements and fixes. But each new feature takes on a bigger problem, with wider scope than before: importing your reports, search, the proof PDF, creating a document from a note. We can place bigger bets, and our Top 100 has to change granularity to match.

Karri Saarinen, co-founder of Linear, puts it this way: work produces two things, the product and what you learn building it. The industry is obsessed with output, but customers don't buy lines of code. If AI does the executing instead of the team, you split execution from learning, and your edge gets diluted. Our rule: we hand agents the work we learn little from, never the choice of what we build. Arguing over the what, the how, and the for whom is how the team understands its customers. And even the day agents can code everything, we'll still be the ones accountable for what we ship.

So the time we save isn't for shipping more. It's for staying close to customers and taking care of quality. What AI does for our customers on site, taking away the tedious parts to give back attention, it does for us too.

Where the work went

We sorted the 2,069 issues completed since September 2024 by stage of our product: the note, the document, sharing, the archive, and the handoffs between them.

Year 1 laid the foundations: the mobile app, the doc, sharing. Year 2 moved the effort to the document and to the handoffs between stages: importing your reports, "Create follow-up," and note merging. Improvements to existing features nearly doubled, while new features dipped slightly.

Construction blocks sum up that choice. We build the building blocks (tasks by trade, attendance, progress, headcount), and AI sorts what was said in the meeting into them. It also knows when to add none at all: often, the right interface is a sentence.

One number surprised us. The share of work going into notes was cut in half, mainly because the developer who owns them was out for a good part of the year. Yet this is the year usage took off: four times more notes in September than the yearly average. Higher standards, or a solution that hit the mark? Probably both. One thing is certain: our boldest bets were on the mobile app, and the boldest of all was taking things out.

Choosing is the real work

The easier it is to build, the easier it is to build the wrong things. Ronny Kohavi, who led experimentation at Microsoft and then Airbnb, made the point in Lenny's Newsletter: roughly two out of three ideas don't move the metric they target. When AI speeds up everything else, this is where the difference gets made.

It also means admitting a solution failed without giving up on the problem. Three lessons from the year:

• Sometimes removing beats adding. A product manager's reflex is to patch a solution with more features. On the mobile app, removing two of three entry points did more than any feature could. Removing is a solution in its own right.

• The entry point matters as much as the feature. The document's AI block, which rewrote notes you dropped into it, never caught on. The same capability, offered from the note as "Merge into document," worked much better. Handoffs between stages are the trickiest part: you can come at them from several angles, and nothing tells you in advance which one will find its users.

• A good idea can show up at the wrong time. Our browser extension isn't catching on, even though every major AI assistant now has one. The idea isn't wrong. The timing is. That's why timing tops our "not now" reasons: a topic set aside today can come back to the vote tomorrow.

Karri Saarinen draws a rule from this that we've made our own: every feature has to earn its place. Building costs almost nothing now. Keeping a feature always costs something, in interactions, bugs, support, and user expectations. The real trap isn't failure, which you pull quickly. It's the feature that succeeds just enough to survive.

Context becomes the product

That leaves one conviction, which Karri Saarinen puts better than we can: for a product team, context becomes the product. What you know about your customers, your market, your past decisions. That's what our ritual keeps alive.

It's also a lesson for our product. On a project, the context already exists: it's the meeting report, week after week, for 18 to 36 months, shared across fifteen to thirty companies. What we do to make decisions, we do for our customers: gather the context so people decide better, and leave the repeatable work to AI.

We tell the story of what this method produced on site, and of our next big bet, the reader, in There Is a Loop.