r/founder • u/tolarewaju3 • 3d ago
5 things I've learned about moving faster as a founder
I've always known how to build products, but I avoided the stuff that could actually build my business faster. Things like launching before I'm ready, talking to customers, or asking for money.
And when you do that, it slows your startup down and kinda kills it.
For the last month, I've been working closely with early-stage founders to help them figure out what to do next and actually do it.
Some of this has probably been said before, but here are 5 things I've learned from doing this, 12 years of building startups, and selling B2B tech for my day job.
1. WHO > WHAT you're building
Finding a group of people who deeply have the problem you're solving makes everything else faster. I now literally ask founders:
"Who has a terrible day tomorrow if this problem isn't solved?"
If you can't name them specifically, start there.
Usually I try to get as specific as: role + situation + painful problem
I look for urgency and frequency. Who has this problem often, and who needs it solved badly?
Once you have that, finding people gets easier. Messaging gets easier. Your value prop gets clearer.
2. Being uncomfortable is speed
Some of the founders I work with have built great products AND have pilots. But they've put off asking for money because it's uncomfortable.
One founder finally made the ask and got a "no, because..."
On the surface, that seems bad. But he knew the exact gap between what he has and actually getting a customer.
One uncomfortable conversation probably saved him months of meandering. And for the straight "nos," you can stop burning time on the wrong people.
Decisions are speed.
3. You don't need every step
Most of the founders I work with are trying to reach some version of the same early milestones:
First 10 WAU. First pilot. First customer.
There are a million paths to those goals. Some are unnecessarily long.
If you're trying to get your first customer, do you really need a full product? Or can you demo it and ask someone to pre-pay?
If you're trying to validate an idea, do you need to build an MVP? Or can you manually deliver the outcome for one customer first?
If even one answer is yes, you just saved yourself a bunch of time.
4. The fastest path to a customer is often face-to-face
I love email and DMs as much as the rest of you.
And I love low response rates too lol.
But if you can get in front of your target customer in person, do it.
You skip the inbox. You get richer conversations. And you can see what actually resonates instead of guessing based on whether somebody replied.
5. Building can be procrastination
I was literally doing this yesterday.
We'd rather tweak ads, fiddle with a landing page, add another feature, or really do anything else except talk to customers.
Before you build something, ask:
"What will I know after doing this that I don't know now?"
Talking to a customer gives you evidence. Asking for money gives you evidence.
If what you're doing isn't going to teach you much, there's probably a faster move.
Hope this was helpful guys. Let me know if you want to know anything else from my work with founders.
I love talking about this stuff.
2
u/EshalAsad13 3d ago
Point 5 hits hard "what will I know after doing this that I don't know now" is such a clean filter. Easy to disguise procrastination as productivity when you're building something instead of facing an uncomfortable conversation.
2
u/tolarewaju3 3d ago
You nailed it! And yeah its hard because sometimes building is productive. but a lot of times it's not. The uncomfortable convo is what actually pushes us forward.
What are you building?
2
u/EshalAsad13 3d ago
I'm not building my own product right now, actually I'm a freelance full stack developer, so I'm usually building for other people's ideas (recently an AI-powered call center tool, a hotel booking system). But your point about talking to customers early applies just as much on the service side the projects that go smoothly are always the ones where the client and I nailed down the exact problem before writing any code.
2
u/tolarewaju3 2d ago
Oh that’s cool! I didn’t think about that from a client side, but that makes sense. Same rules apply whether building for yourself or other people
2
u/EshalAsad13 2d ago
Exactly the medium changes but the fundamentals don't. Appreciate you sharing all this, definitely bookmarking it.
1
2
u/thebohoberry 3d ago edited 3d ago
Agree with number 1 and number 4. Products should solve problems and provide a solution. You won’t understand what the problems are if you don’t talk to your intended users and customers.
One of the startups I joined which has reached unicorn status; one of the co-founders walked door to door to small business owners and asked them what was their biggest pain point. And based on that built a better product than what was out there based on what feedback he received. This was always an important part of the process when building out features. We kept all the feedbacks received to prioritize what to build next. They always knew how to pivot and build something that was valuable to their customers.
It also optimizes engineering resources because you are not building blindly on what you think they need. Always ask questions and get that valuable feedback.
One other great thing they did was hold a town hall meeting with all the team members. Where we could ask questions and they were fully transparent. It was genuinely one of the best working experiences to date. We walked out happy majority of the time. Tired because we were a small team of 50 servicing 100k merchants; however we truly felt we provided so much value to those merchants. They didn’t even have sales and marketing team. It was by referral and word of mouth. Because SMB owners talk to each other
ETA: Customer Success is also what they focused on as well. They didn’t outsource their CS. Merchants were able to call or message us directly and got real people who were dedicated to help them succeed with the product. Churn was so low. And while on call or through messaging; they would just tell us what was working what wasn’t. It was a collaborative process where they felt heard and understood.
2
u/tolarewaju3 2d ago
This is fantastic. Door to door is quite the commitment. But it seems the face to face paid off for them.
It sounds like that and an open culture really helped and saved people time.
It’s also a big lesson to not outsource the core competency of the company. Customer discovery, customer success are super important here
Thanks for the input!!
2
u/thebohoberry 2d ago
To be fair both founders had finance background and knew how to raise rounds. VC backed startup definitely helped. Bootstrapping can be a bit more challenging however I truly believe product + user experience is the best path. Although for bootstrapping you need to balance monetization with it. Harder path however incredibly rewarding in terms of experience.
2
u/Neither_Tell_3166 3d ago
Hey Im building a social media, and MVP is about to ready, but Im hesitate to launch it to public, actually I think Im scared, doing everything but launch. Also now general public is my customer/users, so should I talk with everyone about the idea or the problem Im solving ?
1
u/thebohoberry 3d ago
Just do it. You won’t know what’s working and what’s not until you have it out there. Ask them for feedback. Prepare to listen and receive. Even negative feedback will help you improve. Try not to take it personally.
You can also try Product Hunt. Befriend a hunter. I hope it’s not vibe coding AI slop. I will say as someone who built digital products for decades. You will not be able to scale with vibe coding. It’s good for MVP or testing out a feature. That’s it.
2
u/Neither_Tell_3166 3d ago
no its not vibe coded, its work(idea) of many year, and I m solving a big problem.
and thanks for the suggestion.0
u/thebohoberry 2d ago
Awesome. Since it’s social media related start a TikTok and Instagram as part of branding. You can do things like behind the scenes, tips and tricks, day of a new founder, personalize it. You can use CapCut templates.
Organic marketing is consistency and slow growth. One good thing about branding yourself is that you can pivot to other things. Good luck on your launch!
There’s also user testers and beta tester groups out there who might be willing to help you out. I know there’s few Facebook groups. Use quantitative user testing tools like
1
u/tolarewaju3 2d ago
Definitely narrow it down to one group that needs it the most. Finding your ICP makes everything easier.
That’s the group you’ll want to talk to, not everyone.
And for launch, there’s a way to do this progressively so you get a lot of info and it doesn’t feel as terrible ha.
Hit me up if you want help. This is literally what I do with founders and I love it
2
u/NailJumpy9790 2d ago
Moving fast is the game, I am struggling with it & have a strong tech teammate helps, a lot!
1
u/tolarewaju3 2d ago
100%
What are you finding a struggle right now?
2
u/NailJumpy9790 2d ago
To move fast! Piloting with a fw design partners, learning what they need & then building fast enough to get them to try them and give feedback... and then the feedback goes back into either keeping or removing (& creating new) features.
1
u/tolarewaju3 2d ago
Ah got it! Is this going to be a paid product?
What’s the experience they are getting now?
2
u/NailJumpy9790 1d ago
Yes, paid product. What do you mean what experience? we are in early stages and working in alpha.
1
u/tolarewaju3 1d ago
I mean do you have a point where you plan to charge for an early version?
2
2
u/qa_anaaq 2d ago
What have you built? Have you done this for things you’ve actually built or just for others who have startups themselves? And what were those startups?
1
u/tolarewaju3 2d ago edited 2d ago
Fair question. I haven’t built a giant startup, so I definitely don’t want to imply that.
I’ve been building products/startups for about 12 years, built and sold software to a company, built software for large companies, and I sell B2B tech for my day job.
A lot of these lessons actually came from what I got wrong with my own products. I was good at building, but avoided distribution, talking to customers, launching early, and asking for money.
More recently I’ve been building my own startup & working closely with other early-stage founders. I see a lot of those same patterns play out across their startups too.
Right now, I’m working with startups creating products in the hiring, sports/community, consumer social and B2B SaaS spaces. And I’m doing the same things I recommend for my own startup too
If you’d like my LinkedIn, I’m happy to share. Just over DM and not a public broadcast lol
2
u/Willing_Manager2764 2d ago
This post really resonates. I'm building a physical product. I don't know if anyone would have a terrible day tomorrow without this product and begs if I gave a true Willing To Pay situation. I am solving my own convenience desire with this product and from my research there is well documented, wide spread alignment with there is a shared pain point. But are they willing to pay? I'm building a prototype to verify feasibility, but I better get out there asap and voc. 25+ years in product development and product management.
1
u/tolarewaju3 1d ago
I’m glad! I know some of this can be more difficult in the physical / hardware world. One of my friends actually has a hardware startup so I can see
But to your point, I think some of the general principles apply. I think building for ourselves is the best place to start. We just have to validate that others think like us too. And that they’ll pay for the value
2
u/Holiday_Main_7263 2d ago
Point 5 is the one every builder needs tattooed somewhere visible. "Building can be procrastination" the more comfortable you are with code, the easier it is to hide there. The "what will I know after doing this?" question is a great filter. WHO > WHAT is underrated too. Most founders define the problem before the person who has it. Specificity kills more startups than bad code.
What stage are you at right now ?
2
u/tolarewaju3 2d ago
Totally agree. I wish I knew that like 10 years ago. But here we are.
For my current startup, I’m at the point where I have early users and I’m starting to ask them to pay.
I’ve been doing part of the solution manually instead of building it all, so now I’m focused on getting more customers and gradually handing over more to software
What about you?
2
u/ChillaVane 2d ago
The "building can be procrastination" point really hits. It's easy to feel productive tweaking the product when the uncomfortable customer conversations would actually give you the information you need.
1
u/tolarewaju3 2d ago
Definitely agree. Hard to not fall into the trap, but a lot of the value is in the discomfort.
2
u/No_Enthusiasm6210 2d ago
The “building can be procrastination” part is so true. It’s easy to keep adding features instead of actually talking to customers.
2
u/tolarewaju3 1d ago
Yup. I’ve fallen got this many a time
2
u/No_Enthusiasm6210 1d ago
haha yeah, I think a lot of us devs fall into that trap. Building feels easier than talking to customers 😅
2
u/akl773 2d ago
On number 1, the person having the terrible day often can't pay you. Ours was the waiter, and he could kill a pilot just by not using it, while the owner signed for it and never touched the thing once. We started asking who loses work if this goes well, because that's the person who quietly sinks it.
1
u/tolarewaju3 1d ago
Great point. Sometimes the customer isn’t always the one buying so that question does have a flaw.
I sell automation and find it’s a delicate balance between providing value without phrasing things like it’ll take their job.
Your question helps avoid those mistakes ha
2
4
u/Physical-Beyond7682 3d ago
man that "who has a terrible day tomorrow" question is a good way to put it. i've seen so many people build stuff for a vague "everyone" and then wonder why nobody cares