There are a number aspects to your question. For the most part, I do not believe you need to pick up programming. You'll never to get your team's level of expertise to be able to make effective technical decisions, and anyway, that's what you have them for.
First, laying out a product roadmap should not be encumbered by technical challenges. The product roadmap should highlight major themes -- customer problems / market opportunities to target, and high-level solution elements -- and sequence them out in terms of short-term vs. immediate-term. (At most, lay them out quarterly.) Your product and go-to-market investment levels should also line up accordingly. If there's a particular urgency to get product to market by a specific time, work with the tech team to make them understand this.
The only variation to this is if you've got some major re-architecting to do. If that's what needed to meet your market demand and get to market successfully, then it will have to be prioritized accordingly.
However, if by product roadmap you mean a release schedule with (projected) dates, that's a different thing.
Second, you could carve out a portion of the development capacity to handling bug fixes and technical maintenance stuff. It could be 5-30%. The amount depends on the frequency and severity of bugs you're seeing, the complexity in resolving them, and trading off keeping existing customers happy vs. developing new features for new customer acquisition.
Third, with respect to bugs, establish a set of criteria to determine their severity: blocker, major, minor, that sort of thing. That will help in prioritizing how bugs are tackled.
Third, if they're not already doing so, encourage your technical cofounder to explain the impact of technical challenges in customer or business impact terms. For example, let's say a one-time use case and a cronjob both use the same class for data processing, and the technical team highlights this as a concern. Now, that sounds like a lot of techo-jargon. So I'd focus on understanding the customer impact of that system design, and the severity and frequency of the impact. That will inform my decision on whether it's severe enough to fix now, or a "debt" we'll incur for the time being to be fixed later. In other words, I'd ask A LOT of questions.
Finally, a suggestion: if you're willing to learn programming, is your technical cofounder willing to spend time with customers and learning the business (if they're not already)? An effective relationship should be a bidirectional thing.
Feel free to give me a call if you'd like to discuss in more detail.
