What's something you believed for way too long because someone senior told you?
I will go first.
"Just launch. The market will tell you what it wants."
A senior founder told me that. He meant it as encouragement. Do not overthink. Ship. Learn from real users.
I followed that advice. We launched. The market told us what it wanted. Silence. No feedback. No users. Just quiet.
The problem was not the advice. The problem was that we launched too early. We had not validated the problem. We had not talked to enough potential customers. We had not built something people actually needed.
The market did tell us what it wanted. It wanted us to go away until we had something worth paying attention to.
I held onto that advice for two years before I realized I was using it as an excuse to skip the hard work of talking to people before building.
What is something you believed for too long because someone experienced told you?
Imed Radhouani
Founder & CTO ā Rankfender
Replies
I learned this the brand way too. Building quietly feels productive, but real conversations usually reveal the truth faster.
Rankfender
@graham_lewisĀ Building quietly feels productive because you are moving. Code is being written. Features are being added. Progress is measurable. It is also dangerous because you are not learning. You are just building.
Real conversations are uncomfortable. Someone tells you they would not pay for what you are building. Someone tells you they already tried something similar and it failed. Someone tells you your problem is not urgent enough. That is the truth. It is faster than any dashboard.
The hard part is having the conversation before you build. The ego wants to build first. The ego wants to have something to show. The ego wants to prove them wrong. The ego is expensive.
We learned to talk to buyers before writing a line of code. Not after. The truth hurts less when you have not spent six months building the wrong thing.
What is the most painful truth a conversation ever saved you from?
A lot of startup advice only works when context is included. Timing and validation matter more than people admit.
I used to think speed solved everything. Turns out direction matters way more.
Good reminder that launching is not validation by itself. People needing the product is the real signal.
Rankfender
@aurora_parkerĀ Exactly. Launching is an event. Validation is a process. You can launch anything. You can get upvotes. You can get first-day signups. None of that means people need your product.
The real signal is not the launch spike. It is the retention after the spike. It is the user who comes back without you emailing them. It is the person who pays before you ask.
We launched Rankfender without a free tier. People signed up for the trial. Most of them left. We thought the problem was the trial length. It was not. The problem was that people did not need what we built. They were curious. Curiosity is not demand.
We learned to test before building. Talk to buyers. Ask what they have tried. Ask what they paid for. Ask what did not work. That is the signal. Not a launch day upvote.
What is the quietest validation signal you have learned to trust?
"Don't think about it. If it does not work, the testers will tell you.'
This was, like, 18 years ago :)
Rankfender
@stoyan_minchevĀ That is the kind of advice that sounds efficient until you realize the testers are not there to think for you. They are there to validate what you already built. If you did not think about it first, they have nothing to validate. They just have a mess to report.
Eighteen years ago, that might have been survivable. The stakes were lower. The feedback loops were slower. Now? You cannot afford to hand off thinking to someone else. The testers will tell you what is broken. They will not tell you what you should have built instead.
What is the most expensive "testers will catch it" moment you have seen?
@stoyan_minchevĀ -That will kill motivation. If I spend time and money building something that I am sure is valuable, and never get recompensed, after a while, I will eventually need to look for a more lucrative way to spend my time.
"Don't push back on the founder. They have the vision, you execute."
I believed that for a while. Stayed quiet when I knew a UI decision was wrong. Watched features ship in ways that confused users because I didn't want to seem like I was overstepping.
The founder doesn't always know what's hard to use. That's literally why you're there. Your job isn't just pixels. It's to be the person in the room who says "users won't understand this" when everyone else is too close to the product to see it.
Rankfender
@raj_shekhar12Ā That is the quietest form of failure. Not the code that breaks. Not the feature that no one uses. The knowledge you have that you do not share because you are afraid to overstep.
The founder has the vision. The founder does not have the cursor. They do not watch users struggle to find the button they thought was obvious. You do. That is your job. Not just to execute. To be the one who says "this is confusing" when everyone else is too deep in the product to see it.
The worst part is that the founder usually wants to hear it. They just do not know how to ask. They hired you to see what they cannot see. When you stay quiet, you are not being polite. You are depriving them of the one thing they need most.
What is the most important thing you have said that the founder did not want to hear?
@imed_radhouaniĀ I told a founder that the apps onboarding was too long and had too many steps. He'd spent months building it and didn't want to hear it.
We did some secondary research and decided to cut the steps in half. Numbers got better immediately.
This hits incredibly close to home because Iām stuck in this exact trap right now. I built my product based entirely on a problem I experienced myself, telling myself, 'If I have this issue, other people definitely do too.' As a result, I rushed headfirst into building and completely neglected talking to customers. Thanks for the wakeup call.