We built the wrong feature for 3 months. Our most-requested feature told us.
For three months, the #1 feature request in Murror was "let me share my journal entries with my partner."
It made perfect sense. Murror helps you understand your emotions and relationships. Sharing seemed like the obvious next step. Our roadmap was built around it. We designed the UI, built the sharing flow, even wrote the notification copy.
Then we actually talked to the people requesting it.
What we found: they didn't want to share what they'd written. They wanted their partner to start journaling too -- separately. The "sharing" they were asking for wasn't about showing their entries. It was about getting their partner to have the same experience they were having.
The feature they were requesting and the problem they were solving were completely different things.
So instead of building entry sharing, we built "invite your partner" -- a separate onboarding flow where someone's partner gets their own private space, with no visibility into each other's journals. The only shared element: a weekly "relationship reflection" prompt that both people answer independently, then get a combined insight.
The result? Partner invites converted at 34%. Couples who both journaled had 2.3x the retention of solo users. And not a single person has since asked for entry sharing.
The lesson we keep learning: feature requests are symptoms, not diagnoses. "I want to share my entries" really meant "I wish my partner understood what I'm going through." If we'd built exactly what they asked for, we would have solved the wrong problem.
Now our process is: every feature request gets a 5-minute follow-up. One question: "What would be different for you if we built this?" The answer almost never matches the request.
Anyone else been saved by not building what users asked for?
Replies
@monatruong_murror how do you find the real problem benied a request?
how many times do we build what users ask instead of what they need? @monatruong_murror
have you ever misunderstood what customer wanted? @monatruong_murror
@monatruong_murror do you trust feature request or dog deeper first?
This really resonated with me. I have learned that the first feature request is often just the starting point, not the actual destination.
i like how you focused on the outcome people wanted instead of the feature they described. That usually leads to a much better product.
I have made the same mistake before by assuming I understood what users meant. A short conversation usually reveals much more than a long feedback form.