Ask your agent why, and get an answer
No more “show me where it says that.”
Friction between engineering and product lives in the spec, and it’s no one’s fault: the spec is the only thing that crosses over. With Grove the spec arrives checked against your code, with outcomes your team can test and the decisions behind them, so there’s nothing to argue about at the end.
- Product strategy
- Feature
- Every decision
- Threads
- UI prototype
- Spec
- Feature
Reads the spec
Code has GitHub. Product decisions have Grove.
Code lives in one repository. Grove gives product decisions the same shape, down to each project’s outcomes: what has to be true once it ships.
- NotificationsFeature
- P-240 Approve from emailProject
- Plan
- Approve by email
- Works on any phone
- In the audit trail
- Delivery
- #88 Approve links
- Plan
- P-240 Approve from emailProject
- One tap approves up to $5,000, no sign-in
- Over $5,000 goes to the second approver
How it works
Grove keeps the plan and the code in step
Grove shows what a requirement will cost before anyone commits to it
Grove reads each requirement against the code while it’s still cheap to change, so whoever decides sees the cost first and less work gets rebuilt.
Project: Removing a teammateGrove checked the plan and found 1 issue- Feasibility1
Tasks have no owner field yet, so this needs a migration.
- Plan quality✓
Every outcome can be checked.
- Overlapping work✓
Nothing else touches removal.
Grove keeps your coding agents working on the latest plan
Before they write a line of code, your coding agents check Grove for what was decided since, and why, so they build on the latest plan.
- Read the project plan in Grove
- Assess recent changes
- Update the phase 2 implementation plan
Grove answers the why your code can’t
Anyone on your team can ask Grove how something works. It answers from the code, with the reasons from your projects in Grove, so the answer no longer has to come from you.
You review the code. Grove checks it does what was planned.
When a pull request lands, Grove reads it against the plan’s outcomes and says in plain language which ones work and which aren’t there yet. Code review stays yours.
Project outcomes (2)One project outcome is ready for product review.- Removal signs the person out everywhereReady for reviewLinked pull requests#57End every session on removalMerged#58Revoke refresh tokens on removalMergedGrove read #57 and #58, and it holds.
- Admins see what will change before confirmingBuildingLinked pull requests#59Confirm button for removalsOpen#59 adds the button, but no preview yet.
GitHub access is read-only. Grove never writes, merges or runs anything.
The product department you don’t have
Product work wasn’t meant to be the CTO’s second job
At enterprise scale, a whole department writes the requirements, answers the questions and checks what shipped. On a founding team that’s you, after hours. Grove runs it as one system, and the decisions stay with your people.
- Specs for your agents
- Answers from the plan
- Checks every pull request
We know because we ran those departments. The team behind Grove led product, design and engineering at IBM, Procore and MetLife, and built Grove to be a partner for a founding team as it grows.
About Grove →What founding SaaS teams are saying
OliveAs a technical co-founder who uses coding agents for everything, I want one place for the why and how of our product. With Grove, my co-founder and I each look at our own side of the coin, but at the same data. That’s what keeps the loop closed.
Dan HarrisonCo-founder and CTO
Trade AgentFor a small team, the hard part isn’t building, it’s taking a flood of customer requests and understanding what’s the right thing to build. A lot of requests are small things, and the big ideas get buried. Grove helps us focus on capturing, scoping, and deciding which ideas are worth moving forward.
Nic WidhalmFounder and CEO
ProofmapBefore, product moved forward when the rest of the business slowed down and I had time to dig back into product strategy and planning. With Grove I keep up, bring more people into the process, and still drive the decisions that matter.
Andy StaufferFounder and CEO
Questions CTOs ask
What does Grove need from our GitHub?
Read-only access to your repositories. Grove reads the code to size the work and answer questions about it, and reads pull requests to check them against the outcomes. It never writes to your code.
How does Grove help my dev team?
Your developers get written requirements they can build from, without chasing anyone for them. Grove helps the product lead write the plan and checks it for gaps and contradictions before it reaches your team, so the questions that usually come up halfway through the build are answered first. When something is still unclear, the developer asks from their coding agent and the answer comes back there. Less time in threads and meetings working out what to build, more time building it.
Do my developers have to change how they work?
Very little. They keep working in their coding agents, on their own branches, with their own review. What’s new is Grove’s command-line tool: their agent reads the plan and the decisions through it, and raises a question through it when the plan doesn’t answer something.
We already write specs in the repo for our coding agents
Keep them. A spec in the repo says what was decided on the day it was written. Grove holds the decision behind it, made with the people who aren’t in the repo, with what it serves, what was turned down and what has been decided since. Your agent reads both, and knows what not to build.
How is Grove different from a PRD?
A PRD is usually goals, non-goals and a few outcomes, and figuring out the rest falls to whoever builds it. In Grove that happens together. Your team shapes one living plan, the why and the what, not the how: diagrams, user flows, detailed business rules and high-fidelity designs built from your own UI. When a coding agent hits a question the plan doesn’t answer, the answer goes back into the plan.
Won’t this give us two systems next to Jira or Linear?
Grove is not a second place to track work. Your developers’ work stays where it is today, in a tracker or not. Grove is the step before it, deciding what the work should be, and the step after, checking it came out that way.
Review is still the bottleneck for me
Code review stays yours. Grove takes the other half, whether the work does what was decided. It reads each pull request against the outcomes, says what works and what isn’t there yet, and keeps the reasoning beside it, so whoever picks up the product review has the reasons in front of them.
Won’t Claude just build this?
It may build parts of it, and you should use everything it builds.
What Grove adds is the product process around the decision: one place where your team and its coding agents take it from the idea to what shipped, with the reasons kept and every plan checked before it’s built. The further Claude goes into the building, the more that process matters.
Where does our code go?
Grove reads your repositories with read-only access and never writes to them. When Grove’s agents need to understand your code, it’s copied into an isolated sandbox where the agent can search and investigate it. Portions of your code can also end up in the traces of the agents’ work, which are stored with Arize.
Does Grove train AI on our data in any way?
No. We don’t train models on any of your data, and Anthropic doesn’t train on data sent through its commercial API. We do look at how Grove’s agents perform on your work, and what we learn may lead us to improve some of our prompts.
Do you have SOC 2?
Not yet. A SOC 2 Type 2 report is planned for 2027. In the meantime we follow established security practice: separation of duties, tightly limited access to production systems, and every change to production tracked. Grove’s access to your repositories is read-only.