Why we started Grove

This summer, Kathryn and I set out to redesign how people find their way around Grove. Every initiative and project would get a home page, an official record of what had been decided, and a separate space for loose explorations. So we did what everyone does now. We described it to Claude, and Claude built us a working prototype. It looked right. It clicked through. It felt finished.

We even wrote the idea down in Grove. Then we skipped straight past it, handed the prototype to our developers with a few paragraphs and a link, and said, more or less: just build this, it’s figured out.

It wasn’t.

What was under the prototype

The first pull request landed two days later, built faithfully against the prototype, right down to its colours. The next day it was rebuilt, because we had already changed the prototype. Statuses got new names. “Record” became “Plan”.

Over the next two weeks the questions kept coming, and each one had an answer we had never written down. What does a project’s status mean before anything is built? What should the sidebar show when a document doesn’t exist yet? Where does a work item’s name live: the top bar, the sidebar or the breadcrumb? The prototype showed buttons for things that didn’t exist yet, so they got built, and then we took them out again.

Our developer made a reasonable decision every time. Many of them weren’t the ones we would have made. That wasn’t his failure. We had handed him a picture and kept the decisions in our heads.

Two weeks in, we stopped and did what we should have done first. We broke the work into what became twelve projects in Grove, wrote down what each one had to do, and settled the open questions on the plan instead of in pull requests. The decisions got short and checkable. One outcome from that work reads: “Up steps to the parent; Back retraces history.” One sentence, settled before anyone built it.

The cleanup ran on for weeks. By mid-August the new navigation had taken more than a hundred pull requests, and most of the ones after we stopped were Kathryn’s and mine, cleaning up. The strip that shows a project’s lead and dates was designed three times. A way of grouping the project list was built and replaced within a week. We had ended up with two breadcrumbs, built separately, that behaved differently. And the three-tab top bar at the heart of the prototype, the part we were most sure about, was gone.

We build Grove for a living, and we still fell for it.

A prototype is only the tip of an iceberg. The constraints, dependencies and tradeoffs sit below the waterline, and a polished prototype is more dangerous than a rough sketch, because it makes everyone believe the details are settled. Coding agents have made the tip almost free. You can have a working demo by the afternoon. What they haven’t changed is the rest of the iceberg, and somebody still has to decide what’s down there.

The bottleneck moved

Deciding what’s below the waterline used to be a department’s job. Kathryn, Rob and I spent our careers leading product, design and engineering at IBM, Procore and MetLife, where whole teams existed to make sure hundreds of developers built the right thing: questions before the build, written requirements during it, reviews after it. Building was slow, so there was time to decide, and a bad product decision could hide behind a slow delivery. Even then, we watched talented teams’ great ideas wither. Decisions got made too late, under pressure, or not at all, and teams paid for it in rework, misalignment and lost momentum.

Then coding agents changed the slow part almost overnight. Five developers can now build at the pace a department used to support, with no department behind them. Development sped up. Product decision-making didn’t. Deciding what to build, and checking that what shipped is what you meant, take as long as they always did, and both land on one person, usually a founder who is also selling, hiring and raising. When the wrong thing ships, there’s no slow build to blame anymore. It traces straight back to the product decision.

What happened to us happens at almost every team we talk to, and it follows the same path. It starts with a spark: an idea, and a prototype by the afternoon. Then the iceberg shows up, all the details nobody has worked out. The middle gets messy, as AI fills the week with specs, prototypes and tickets nobody has time to read closely. Developers hit the gaps inside their coding agents, far from the outcomes the product lead thinks in, and deadlines force rushed decisions. The work lands late or compromised, adoption is flat, and the team has already moved on to the next build. Then someone asks the question we hear more than any other:

None of this is new. Software projects missed their outcomes long before AI. But AI speeds up every stage, and it bakes the guesses into code before anyone notices.

So we built Grove

The answer isn’t to slow building back down. It’s to give small teams the discipline a product department used to provide, without the department. Three beliefs shape how we do that.

Deciding stays human. AI can draft, ask the hard questions and check the work. It shouldn’t make the call. Everyone has the same AI now. Nobody else has your judgment about your customers.

Founders should keep making the big decisions. The usual advice is to hand product off to your first product manager once you have traction. Hire the PM, but keep the bets. What the founders know is the company’s edge. The PM makes the calls inside each bet and brings the founders the ones that would change it.

Hand off the work around the decision. That means the hard questions before the build, the write-up, keeping the plan current while the build moves, and checking what shipped against what was decided.

That work is what Grove takes on. It’s product management software for founder-led startups whose developers build with coding agents. You bring an idea, even a half-formed one. Grove works it into a plan with you and asks the questions a product department would. Before anyone builds, it checks the plan against your code and flags the gaps. While your developers build, their coding agents read the plan from Grove and ask when something is unclear, instead of guessing. When a pull request lands, Grove reads it against what you decided and tells you what’s there and what isn’t.

Your developers keep their own tools. Grove reads your code and never writes to it. And the decisions stay yours.

Our prototype was a good idea, and building it was one of the best afternoons of the summer. The mistake was thinking the spark was the whole fire. The spark is the best part of building something, and our job is to make sure it reaches your customers intact. Great ideas deserve to flourish.

We bring on a few teams at a time, and one of the three of us works through your first feature with you. If that sounds like your team, request access.