What teams use Feature1 for
Six things product teams do in Feature1, with what happened when a real team did them.
Each use case is one job. Most teams start with one and pick up the others as the product context builds. Names are left out unless the team has agreed to be named.
- Decide what to build next
For founders and product leaders with a live product and a decision to make.
Feature1 works through your business goal, customers, competitors and current priorities and writes a one-page Product Strategy Narrative. Then it reads what the product can already do, shows the gap between the narrative and the product, and turns that gap into initiatives.
What happened: A team serving enterprise customers moved to AI-assisted development this year. Delivery got faster and the constraint moved to deciding what to build. They hired a second product manager, not a third developer, and now run planning off a written strategy.
- Turn customer signals into product decisions
For product teams whose feedback lives in the CRM, the support desk and three chat tools.
Voice of customer from the CRM and bugs and feature proposals from collaboration tools become context. Feature1 recommends ideas from them, and the product team judges each one against the goals and initiatives, weighing impact alongside urgency.
What happened: One team keeps target customers, competitors, initiatives and goals in Feature1 and lets the CRM and their collaboration tools feed it. A competitor pricing comparison surfaced this way prompted them to rethink their own entry tier.
- Write the spec before the agent starts
For teams using Claude Code, Codex or Cursor whose tickets are a title and a paragraph.
A feature is planned as a short PRD, then user stories with acceptance criteria. The coding agent reads that context through MCP, so it asks fewer product questions and builds what was meant.
What happened: At a scaleup, a couple of days went into the feature, stories and acceptance criteria for an MCP layer. A junior developer who started with almost no context on the feature built it in one day and it passed end-to-end testing. She reported far fewer product questions from the agent than usual.
- Take a prototype to a real product
For founders who built with Lovable, Replit, Bolt or Emergent and are asking what now.
Audit the prototype for launch, make it deployable, specify the enhancements properly instead of prototyping them, then launch and measure. mvpfy, our open-source companion, runs the existing product locally and ships each change as a pull request.
What happened: A food business had a store built on Replit that looked shipped. The backend was a single server file holding every endpoint, not wired to the frontend. The audit surfaced it. Then infrastructure, then properly specified enhancements, then a real launch.
- Keep the roadmap true to the code
For product leaders who suspect what was built no longer matches what was planned.
Feature1 reads the repository, keeps a picture of the product's capabilities and their maturity, and updates it when the software changes. The roadmap becomes capability changes, and you can see when the code drifts from the direction.
What happened: The gap check, does what you built match what you set out to build, is the step teams skip most. It is the same question the narrative ends on, run continuously.
- Ask the product from Slack
For teams that live in Slack and want answers without opening another tab.
Message Feature1 directly: how does our authentication flow work, what is the status of the sprint, what feedback do we have on onboarding. Turn a conversation into a bug, a feature or a user story in Feature1.
What happened: The conversation starts in Slack. The work lives in Feature1, on the same sprint board the rest of the team uses.
Start with the decision you are stuck on.
The first use case is where most teams begin. Free, no credit card.
Questions people ask
What do teams use Feature1 for?
Six jobs: deciding what to build next, turning customer signals into product decisions, writing the spec before the coding agent starts, taking a prototype to a real product, keeping the roadmap true to the code, and asking about the product from Slack. Most teams start with one and pick up the others as the product context builds.
How does Feature1 help decide what to build next?
It works through your business goal, customers, competitors and current priorities and writes a one-page Product Strategy Narrative. Then it reads what the product can already do, shows the gap between the narrative and the product, and turns that gap into initiatives.
How does a coding agent use Feature1?
A feature is planned as a short PRD, then user stories with acceptance criteria. Claude Code, Codex or Cursor reads that context through MCP, so the agent asks fewer product questions and builds what was meant.