Obviously that wouldn't hurt, and there are likely benefits to doing so. The thing to consider is will doing this save you time and make you a better leader or will it take time away from leading, growing and building a vision for the company? Only you can answer that.

Being in a technical industry myself there is no way that I can know as much as my team knows. They are the ones in the trenches and understand the details better than I ever could. But I still need to have an overall grasp and understanding of how each of their roles applies to the projects and coordinate how they work together to get the job done. I could spend more time digging into the details, but ultimately that would take my time away from leading the company.

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.

I can relate to you as I am a Non-Technical founder. The way to handle it is ask questions to both your Technical founder as well as the engineers.

You allow your Technical founder to manage the tech team.

You are the product manager so what you need to understand are the the complexities of different items so you understand the time it will take.

1. Short term items: bug fixes, optimization, etc
2. Long term items: features based on your product roadmap.

Long story short, you let your technical founder run the engineering team. You don't manage them.

As a "non" technical founder on a tech team, I really relied on our team to help drive product roadmaps and timelines. I think you can do the same.

As a non-technical product manager who has wrestled with this exact question, I think I can add value to this conversation. Given the answers from other folks, I'll only comment on the aspects of your question that haven't been covered.

Namely, YES, you should pick up basic programming skills if you can spare the time to do so. It will help you in a number of ways, including the ones you alluded to. The more conversant you can be, the fewer instances where you will be confused in meetings with customers (where gathering requirements can get technical). Also, by being more technically competent, you'll spend less energy and time getting explanations and summaries from your tech guys.

You don't need to be a programmer to manage a technical team, especially if you are a competent product manager, who understands the user and business side of the product and roadmap. It's best to ensure you have a solid relationship and good communication with your technical people, especially your technical co-founder.

So, for the most part, learning some code will help YOU a lot. But in terms of management, you wouldn't need to know programming to lead unless your communication/relationships are not as healthy as they should be. Then it can help you cut through some obfuscation behaviors that sometimes come up when business and tech don't work in concert as well as they could.

Final point: learning some programming skills requires time. So does running a startup. It's challenging to do both without sacrificing the quality of your learning, or the outcomes of your efforts. In my opinion, setting aside time for this is only worth it if you have no other options. It seems like you have a technical cofounder that will help you. From a resource standpoint, that is far more effective and less disruptive than learning to code.

I would suggest that you do not distract yourself with trying to become more technical. First of all, the value you bring to the company is representing customer needs and the strategic direction of the product. If you become too mired in the technical details, you start making decisions based on technical facility as opposed to what you can offer the market. If you do not produce something that the market demands, you might as well shut down the company. Your technical leads will advise you on what is possible and reasonable, and you will always have that healthy push and pull between "desired" and "practical" and those two forces should work together to help you build a roadmap that serves both your customers and your business.

Secondly, your technical knowledge will grow organically as you gain experience building a product. I consider myself very technically well-versed but I am not a technical resource. I don't have any formal technical education but I can speak knowledgeably about architecture, platforms, design and implementation to a certain point at which I will actually be detrimental to my team if I try to venture into any further detail. I hired them and chose to work with them because I can throw problems and issues at them and they will design the best solution. I don't want to debate their technical challenges. All of my technical knowledge has come from years of working with technical teams and designing products. I have it, I like having it, but I never let it govern decisions I make as a product owner and manager.

My advice to you is to stay out of the weeds and do what your team needs you to do - advocate for the vision and the market potential of your product and let a strong technical lead drive the architecture and technical roadmap. You will be in constant healthy negotiation around prioritisation and a good technical lead will "get" the business demand and value and work to find the best plan for implementation.