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
how many times do we build what users ask instead of what they need? @monatruong_murror
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.
have you ever misunderstood what customer wanted? @monatruong_murror
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.
@monatruong_murror do you trust feature request or dog deeper first?
Murror
@carolina_ellen Always dig deeper first. Feature requests are valuable signals, but they're rarely the full picture. We now treat them as conversation starters, not specs. A quick follow-up call usually reveals the real need in under 5 minutes.
This really resonated with me. I have learned that the first feature request is often just the starting point, not the actual destination.
Murror
@mathew_chang Well said. The first request is a signal, not a blueprint. We learned to ask why three times before writing a single line of code. That extra digging almost always reveals the real need hiding behind the surface-level ask.
what insights came from users who never accepted partner invites and could their feedback improve onboarding even further?
Murror
@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.
What process will you use to keep validating future requests and could short customer interviews become a required step before development begins?
Murror
@nathan_jake Great question. We now run a quick 15-minute call with 3-5 users before greenlighting any feature. We ask them to walk us through the problem they are trying to solve, not the solution they want. This catches misaligned assumptions early. Short interviews are becoming a required step for anything that touches core user flows.