SatoriXR
Delivery got faster once their developers worked with coding agents. Then deciding what to build became the slow part, and they hired a second product manager, not a third developer.
Your developers build faster with AI. Deciding what to build hasn't caught up.
Feature1 puts your product strategy next to what is actually happening in your product. Your team decides what to build from that, and writes it down as specs with acceptance criteria. Your developers' coding agents build from those specs, so they build what you decided instead of guessing.
- Decide from evidenceYour strategy sits next to adoption from Amplitude or Mixpanel, errors and Apdex from Sentry or New Relic, and what customers say in Intercom or Zendesk.
- Specs your agents can build fromFeatures, user stories and acceptance criteria, read by Claude Code, Codex or Cursor over MCP.
- See if it workedAfter release, the same signals show whether the change moved anything.
Works with GitHub, GitLab, Bitbucket and your existing workflow.
See it in two minutes.
From a goal, to the roadmap, to the specs, to a coding agent building it.
Building got fast. Deciding didn't.
Once developers work with coding agents, code is no longer the slow part. Working out what to build, and writing it down clearly enough for an agent to build it, is. We saw the same thing at each of our customers.
Quantem
A developer new to the product built an MCP layer for it. Four to five days went into writing down what it had to do. One day went into building it, and it passed end-to-end testing.
JarShare
It started as a Replit store with one server.js file that nobody had written down. Feature1 read the code, mapped what the product could already do, and the next features were planned from there.
Decide from what is happening in your product.
A strategy doc tells you where you want to go. Product signals tell you where you are. Feature1 puts them side by side, so a roadmap item comes with the evidence for it, and after release you can see whether it worked.
Adoption
Which parts of the product people use, and which they stop using.
Amplitude, Mixpanel, PostHog, Heap
Product health
Error rates, slow pages, open alerts, and Apdex where your tool reports it.
Sentry, Datadog, New Relic, Rollbar
What customers say
Support tickets, calls, surveys and bug reports, linked to the part of the product they are about.
Intercom, Zendesk, Freshdesk, Gong, Delighted, Typeform
How one change moves through Feature1.
From the first signal to the result after release. Each step stays linked to the one before it, so anyone can see why a change was made.
- 1SIGNALCustomers raise the same problem in support, and usage of that part of the product is dropping.Zendesk · Amplitude
- 2GOALThe team links it to an objective in the strategy, instead of starting a new one.Objective
- 3SPECFeature1 checks the request against what the code already does, then writes the PRD and the open questions.PRD
- 4CRITERIAAcceptance criteria written as Given / When / Then, each one testable on its own.Given / When / Then
- 5BUILDThe coding agent reads the criteria over MCP and builds one criterion at a time. The developer reviews each one.Claude Code · Codex
- 6RESULTAfter release, Feature1 rescans the code, and adoption, errors and support volume show whether the change worked.Amplitude · Sentry
Open any shipped change and you can see the signal, the goal, the spec and the acceptance criteria behind it. Nobody re-types anything.
The same loop, on screen
Strategy to roadmap to a Claude Code handoff, in two minutes.
The questions your product team should always be able to answer.
Feature1 keeps the answers in one place, for your team, for your coding agents, and for whoever asks six months from now why something exists.
- What does our product actually do today?
- Why are we changing it?
- What evidence supports this decision?
- Does this duplicate or contradict something that already exists?
- Which part of the product needs to improve?
- Is execution still aligned with the original decision?
- Did what we shipped actually work?
- What did we learn, and what changes next?
The reason stays attached to the work.
Writing a spec is the easy part. Feature1 keeps the decision, and the evidence for it, attached from the first signal to the merged code.
It asks before it plans
Feature1 asks the product, technical and strategy questions a good PM would, checks the request against what the product already does, and lists the assumptions before a PRD is approved.
Open questions come up before the build, not during it.
Agents build inside the criteria
Developers and their coding agents get the objective, the intent of the feature, the acceptance criteria and the constraints. Not a one-line ticket.
The agent builds what was agreed.
Everyone works from the same picture
Each team and each coding agent reads the same record of what the product does, why the last change was made, and what customers said about it.
Nobody rebuilds the context every sprint.
Plan from what the product does today.
Start with what the product can already do, say what you want to change, and plan only the work needed to get there.
Current capabilityBulk order managementDepth 3 / 5
ObjectiveReduce enterprise onboarding time by 40%Required depth 5 / 5
Planned changes
- Bulk validation
- Bulk editing
- Error recovery
- Progress reporting
Your roadmap should know when the code changes.
When a change is merged, Feature1 can rescan the repository and update what it knows the product can do. The strategy stays tied to the software as it is now.
- 01Product intent recorded
- 02Implementation lands
- 03Capability scan triggered
- 04Capability evidence updated
- 05Strategy remains grounded
Your existing stack stays where it is.
Feature1 connects to your code on GitHub, GitLab or Bitbucket, to your analytics, monitoring and support tools, and to the coding agents your developers already use (Claude Code, Codex, Cursor) over MCP.
GitHubGitLabBitbucketClaude CodeCodexMCPAmplitudeMixpanelPostHogSentryDatadogNew RelicIntercomZendeskSlack
Plans are scoped to the product team, not every person who reads a ticket.Talk to us about pricing →
Manage. Build. Grow. One product context across all three.
Feature1 manages the product. mvpfy builds it. BeyondWebsite takes it to market. All three work from the same understanding of your product, and our open-source tools extend them.
Growth engine
LaunchedBeyondWebsite
Take what you have built to market and keep it current.
View product →
Open-source PM IDE
Open sourcemvpfy
Help PMs and founders safely work against real codebases.
View product →
Open-source system
LaunchedAgentify by F1
Turn software APIs into conversational agents.
View product →
Open-source system
Launching soonChatify by F1
Turn organizational knowledge into conversational interfaces.
View product →
Product teams building with Feature1
What the platform has produced so far.
Feature1 has been in production use since 28 December 2025. Every figure below is counted from the production database, not estimated. No customer is named and no number is broken down far enough to identify one.
- 6,770criteria
- Acceptance criteria written Counted on live, non-draft stories
- 1,933stories
- User stories planned Everything planned on the record, including work later dropped or still in draft
- 145documents
- PRDs generated From 350 features taken through planning
- 12,931tasks
- Coding-agent runs Each one dispatched against a written acceptance criterion, not a chat prompt
- 31repos
- Codebases analysed Repositories holding a completed analysis; ones deleted since are not counted
- 1,012threads
- Assistant conversations 6,285 messages across the product record
- 15sprints
- Sprints run end to end Completed; a further 12 are planned or still running
Recorded 9 October 2026 · 285 days of production use
Sharper thinking for product delivery.
PRODUCT STRATEGY
From feature shipping to capability evolution
Manage durable capabilities instead of disconnected feature output.
FEATURE PLANNINGStop using ChatGPT for feature planning
Feature planning needs context, collaboration and executable output.
ENGINEERINGDriver-navigator pair programming in the AI era
Keep AI-generated code aligned with intent and review quality.
Questions people ask about Feature1.
What is Feature1?
Feature1 is product management software for teams whose developers build with AI coding agents. It puts your product strategy next to real product signals, helps your team decide what to build, turns that into specs with acceptance criteria, and lets coding agents such as Claude Code, Codex and Cursor build from those specs over MCP. After release, the same signals show whether the change worked.
What problem does Feature1 solve?
Coding agents made building fast. Deciding what to build, and writing it down clearly enough for an agent to build it, did not get faster, so it is now the bottleneck. Feature1 helps product managers and founders make that decision from evidence and hand it to developers and their agents in a form they can build from.
Which product signals does Feature1 use?
Adoption from Amplitude, Mixpanel, PostHog or Heap. Product health from Sentry, Datadog, New Relic or Rollbar, including error rates, latency, open alerts and Apdex where the tool reports it. What customers say in Intercom, Zendesk, Freshdesk, Gong, Delighted or Typeform. Deals and accounts from HubSpot, Salesforce, Pipedrive or Zoho.
Which coding agents and code hosts work with Feature1?
Any coding agent that supports MCP, including Claude Code, Codex and Cursor. The Feature1 MCP server exposes 114 tools for strategy, planning, stories, acceptance criteria, sprints and repository context. Feature1 reads code from GitHub, GitLab and Bitbucket, and is listed on GitHub Marketplace.
How is Feature1 different from ChatPRD, spec-kit or Jira?
ChatPRD and GitHub spec-kit write a spec document. Jira, Linear and Productboard track work after it is decided. Feature1 holds the decision itself: it checks a request against what the code already does and against product signals, keeps the strategy, roadmap, specs and acceptance criteria connected, and lets the coding agent read them directly.
Who is Feature1 for?
Software companies, usually 11 to 200 people, where developers already use AI coding agents and the product managers or the founder have become the bottleneck. It is built for the product manager, the head of product or CPO, and the founder who decides what gets built.
How much does Feature1 cost?
Professional is $199 per product manager per month, or ₹14,999 per product manager per month plus 18% GST in India. Each product manager seat includes four collaborator seats for engineers, QA and leadership. Enterprise adds on-prem and private deployment and is priced per deployment. There is a 7-day free trial with no credit card.
Bring your roadmap. Bring the repo.
On a call we take one real goal of yours, look at your code and your product signals, and plan the first feature with you.