During a recent round of feedback calls, our power users requested a workflow feature that would fundamentally change how our product operates. On paper, it solves a big problem for them but it moves our app away from the simple, focused solution we set out to build.
Balancing listening to your customers with sticking to your core vision is much harder in practice than in theory.
How do you handle conflicting user feedback? Do you adapt your roadmap to high value requests or stay firm on your original vision?
We started with a 14 day free trial, assuming urgency would push users to explore the tool deeply. Instead, most users signed up, got busy with work, and returned on day 13 asking for an extension because they never had time to test it properly.
Switching to a limited freemium model gave them breathing room but conversion to paid slowed significantly.
For founders who have tested both models: which one worked better for your product archetype, and how did you balance urgency with user activation?
When we launched our lowest tier, the goal was simple: lower the barrier to entry and get as many people through the door as possible. But looking at our churn data, this group had the highest churn and required the most support time.
It made us wonder if we were solving the wrong problem maybe a lower price point just invites users who aren't fully committed to the solution.
For those running SaaS products, how did you find your ideal entry pricing? Did you end up raising prices to filter for intent or did you keep a low entry point to build top to funnel momentum?
Early on, every time a user asked for a feature, we put it on the roadmap. We thought we were being customer obsessed. But a few months in, our clean dashboard turned into a cluttered menu, and new users started dropping off during onboarding.
Stripping back features felt terrifying because we were afraid of losing active users, but keeping them was confusing every new signup.
How do you decide when to say no to feature requests? Have you ever had to sunset a feature to save the core user experience?
Been working on a solid product n the launch of the product, but what's that we need to do to have a sustained spike and retain users who come in to explore the platform and convert them into power users. Been thinking about this and working closely with teams who have launched in the past and gone through the same problems, Happy to have this thread open to record my findings/ strategies. If there are specific questions, do post, happy to chat!
Are there any parents on Product Hunt? Looking to discover or connect with people that are doing both at the same time! Whats your routine and how do you manage both :)?
While building a competitor monitoring tool, I'm finding that collecting updates is the easy part. Deciding what matters is much harder.
If a competitor cuts its price, adds a major integration, or changes its positioning, how do you decide whether to respond? Do you have a rule for separating a real market signal from noise? Have you ever ignored a competitor move and later realized it was the right, or wrong, decision?
Lately I ve been thinking about how hard it s become to choose well.
Almost every category now feels overcrowded agencies, SaaS tools, AI products, consultants, even simple productivity apps. On the surface, there are more options than ever. But instead of making decisions easier, that abundance often makes everything feel noisier and harder to evaluate.
Most startup advice is heavily biased toward people who succeeded which makes the quiet struggles feel way worse than they are.
I constantly find myself second guessing basic decisions like whether to push prices up, change direction, or just admit a feature flopped. The hardest part is knowing if staying the course is actual persistence or just stubbornness.
How do you personally decide when to keep tweaking an idea versus shutting it down and moving on?
been thinking about this while working with LLM-based agents.
We still use retries, fallbacks, state machines and routing logic to make agents more reliable. But with newer models getting better at tool calling and handling failures, I wonder how much of this we really need to maintain ourselves.
Personally, I'd still keep permissions and critical actions deterministic. But for things like deciding the next step or recovering from a failed tool call, I'm not sure we need to hardcode everything.
Curious how others are handling this in production. Have you actually removed orchestration logic because newer models handle it better or has the complexity just moved elsewhere?
