Hi Ravi, congrats on getting your first 40 customers! It’s an achievement to get there 
I think the core problem that you’re having, with sticking to your roadmap, is that you’ve got a release plan, not a roadmap. It’s very common for teams to conflate the two, but it runs into problems like you’re outlining.
Things like bugs and customer requests shouldn’t live on your roadmap. If they are, then it’s more likely that you’ve got a list of ‘things to do’ vs ‘time’, which is essentially a release plan. Now, there’s nothing wrong with having a release plan, as it’s an important document! But the problem comes when you start planning things further and further out, making up potential release dates as you go. What you’re actually doing is overcommitting your team to building a bunch of things, without providing the flexibility to measure and learn between iterations. Your release plan should only look at what you plan on releasing in the short term, as in work that’s already been prioritised and is in progress.
You won’t find Product-Market Fit by just following all of your customer’s change requests and fixing all of their bugs. To get to PMF, you’ll need to take a big step back from the delivery mindset, and spend time discovering: What sort of problems do your customers really have and are willing to pay for? What sort of obstacles will you run into if you tried to solve those problems? Use your roadmap to outline your assumptions about these problems. The roadmap, as you validate it (as in, iterate and check it with more and more stakeholders to make sure your assumptions make sense!) will help shape your release plan.
You’ll never finish all those bugs or complete all those change requests. As your product matures and your customer base grows, you’ll find yourself having to say no to more and more, simply because there’s never enough time! Imagine the requests you’ll get when you have 1000 customers 
Instead, your roadmap will help make sure that you’re saying yes and no to the right things, therefore wasting less of your precious time. This is why we call it a Lean Roadmap (lean means to reduce waste).
Now, to your point about your team not progressing as fast as you’d like… remember that this is subjective, and frankly, you’ll never move as fast as you really want. Building great products does take time. That said, there are things you can do to speed things up:
- Give the team clear direction and autonomy. They should understand the vision, and the problems on the roadmap, and how the business is being measured, and should be empowered to do their part in pushing the company forward. Sometimes the biggest bottleneck in a company is a founder who gets too in the weeds and has to give directions at every step.
- Ditch arbitrary deadlines. Sometimes it feels like giving something a deadline will help hustle the work along to completion, but it actually has a detrimental effect. First of all, anyone working to a deadline is going to know to add some buffer to their estimates, or else run the risk of not giving themselves enough time. This then leads to the issue that work expands to fill the time allotted. You rarely see projects come in under, but you often see projects pick up scope creep and go over. If work is rushed through to a deadline, you can be sure one of two things is happening: either the scope is reduced and you end up with less of what you were hoping for, or more often, the quality is reduced. Oftentimes, you won’t even see this reduction in quality. It’s just a little bit of extra tech debt, but that stuff adds up. Over time, it’ll slow down your team from being able to deliver as fast as they could when the codecase was new and less buggy. Ditching timelines takes an element of trust in your developers, and you’ll need to work with them to have a shared understanding of what ‘done’ is, and how much time is reasonable to spend on any problem, so you don’t end up lost down rabbit holes. But you’ll end up with better quality and faster deliveries as a result of ditching deadlines. I spoke and wrote about this in more detail here: Tech Debt Talk: Decisions Debt and Other Dilemmas
- Make releases less scary. If your releases take a multi-day song and dance and only happen every few weeks (or god forbid, every few months!) then each release is fraught with stress. It creates a deadline for everyone, as if this release is missed, then the work won’t see the light of day for another long time. It creates stress, as if something isn’t perfect and needs to be iterated, there’s no easy way to do that. This means that the team spends more time planning and checking their releases, rather than just batting it out the door. A lot of companies think of continuous deployment as a tech exercise, but in reality it has huge value for the bottom line of the business. A team that can deliver with ease can switch between iterating and delivering and discovering, without the stressful build up of a big-bang launch. Our team here at ProdPad launches twice a week, like clockwork. For a team without deadlines, we sure get a lot done: Release Notes - ProdPad Help
I hope this helps! Best of luck with the next stages of your journey Ravi 