Absolutely not. There are countless examples of entrepreneurs with low GPAs / grades. GPA is merely a metric for academic achievement. There are many, many other factors that go into entrepreneurial success.

I agree with Tom Williams answer. Joining a top-tier consultancy will make you a better analyst and possibly communicator, maybe even think more "strategically". But it won't teach you anything about how to create a product roadmap, how to work with engineers, how to launch a product to market, how to empower marketing and sales, how to prioritize a product backlog, or write requirements, all of which are core elements of any product manager job.

Hi Aidan.

Lots of good answers here:
https://www.quora.com/How-do-you-get-into-a-product-management-role-with-no-prior-experience-as-a-PM

Also, I had a PM guest post their experience on my blog:
http://streetsmartproductmanager.com/how-i-became-a-product-manager/

You'll have to see what works in Australia. There's a PM consultancy called Brainmates in Australia, led by Adrienne Tan. You could contact her to get the take on things in Australia.

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.