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
have you ever misunderstood what customer wanted? @monatruong_murror
@anthonywrinqsb All the time, honestly. This sharing feature was probably our biggest example. We've since accepted that our first interpretation of any request is probably wrong. Now we treat every request as a clue, not an answer. It's made us much better at building what actually helps people.
how many times do we build what users ask instead of what they need? @monatruong_murror
@bradywilfaqn More often than we'd like to admit! I think the instinct to just build what's requested is strong because it feels productive. But we've learned that a 5-minute conversation saves weeks of building the wrong thing. The hardest part is slowing down when you're excited to ship.
what insights came from users who never accepted partner invites and could their feedback improve onboarding even further?
@joan_garcamo Really thoughtful question. Users who declined partner invites often said they weren't ready to "bring someone else into it yet." That told us the solo journaling experience needed to feel complete on its own first. We're now improving the solo path so the partner invite feels like an expansion, not a requirement.