Beta Users Gave Feedback That Ruined V1 - Separating Workflow Problems from Feature Requests
Beta Users Gave Feedback That Ruined V1
You ship your beta. Users try it. They give you feedback. You implement every suggestion. Three months later, your product is an incoherent mess that tries to do everything and does nothing well.
This is one of the most common mistakes in early-stage products, and it comes from treating all feedback equally.
The Two Types of Feedback
Workflow problems are when users cannot accomplish what your product is supposed to help them do. "I tried to automate my email workflow but the agent kept losing context between steps." This is gold - it tells you your core value proposition is broken.
Feature requests are when users want your product to also do something else. "Can you add a calendar integration?" "What about Slack notifications?" "It would be great if it could also manage my todo list." These are distractions disguised as helpfulness.
How to Tell the Difference
Ask one question: "Is this person trying to use the product for its intended purpose and failing, or are they trying to use it for something else?"
If five beta users all struggle with the same workflow step, that is a real problem you need to fix. If five different users each want a different integration, that is noise.
The V1 Survival Rule
For V1, fix every workflow problem and ignore every feature request. This feels wrong because you are "ignoring your users." But you are not - you are prioritizing the users who need your core product to work over the users who want a different product.
Feature requests become relevant in V2, V3, and beyond - once your core workflow is solid. Adding features to a broken core just gives users more ways to be disappointed.
The products that survive are the ones that do one thing exceptionally well before expanding.
Fazm is an open source macOS AI agent. Open source on GitHub.