Questions

As a non technical founder, I am trying to manage and align the progress of the non technical team and the technical team towards our milestone. The challenge that I am facing is mapping out the product roadmap. Because of my limited technical knowledge, I can't see as far as I'd like to while taking into account bug fixes or technical challenges that we are facing. I am now working with my technical cofounder more closely in terms of understanding our product's technical stack so that I can better predict the challenges and potential of our product and work together to lay out the roadmap. I was thinking of picking up basic programming so I can at least understand what my dev team is telling me instead of trying to imagine it. Is this the right approach?

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.


Answered 8 years ago

Unlock Startups Unlimited

Access 20,000+ Startup Experts, 650+ masterclass videos, 1,000+ in-depth guides, and all the software tools you need to launch and grow quickly.

Already a member? Sign in

Copyright © 2024 Startups.com LLC. All rights reserved.