Should a non-technical founder learn to code?
Here's a (repeated) question. I want to get the perspective of IH.
Should non-technical founders learn to code? I run www.DragApp.com and am a non-technical founder. I am interested in perspectives on whether it's right for me to learn (I am by the way) to code or, because the product is trading with a development team, that learning to code would be a waste?
Interested to get everyone's views and more importantly, if thumbs up to coding, what the practical applications would be given my set up?
Like Elgar asked, why do you want to learn to code?
If you feel like the only way to add value is to write code, then you should look harder at your contributions. See intercom blog post about product management (tl;dr make sure you do everything you can to validate the team is build is building the right product, not just your shower ideas.) https://blog.intercom.com/great-product-managers-dont-spend-time-on-solutions/
Or, get out there and sell, customer discovery, etc.
If you learn to code and spend your time doing those things (which is valid as a career choice), who is going to perform those functions?
I definitely don't feel the only value is writing code. However, informed decisions may be better made by having a fundamental understanding to lead both commercial AND technical teams.
The way I see it is that SaaS is software/code/programming. This is the core, your product. Being commercial and driving the commercial elements of the business is fine. But leading with strategic commercial and guide (better) on technical, I believe is a winning combination.
I have sales, marketing and technical functions in the business. All are quite autonomous, hence why it has left me thinking around bolstering up tech. knowledge :)
My interpretation of your reply is that you want to help guide the technical team into making decisions that align to the medium and long term product roadmap? You can do that without being "technical" in the "write code" sense.
Hopefully you can work with your cofounders to help them understand where you think the product is going. For example:
A) We're building this feature as the first step of 5. Here's where we plan on going, so don't build us into a hole in step 1.
B) We're just building this one thing to test a hypothesis, so don't over-engineer it (knowing that there will be debt to clean up if we validate the idea.)
Also, SaaS is not just software/code/programming. What's your custom acquisition strategy? For example, SMB don't really spend their time googling for solutions to their problems.
Disclaimer: I am a software engineer by background, but there is a lot of value in the business side. However, it's very easy for the business side to just point fingers at the engineering side as they are the folks making things real, where it's the easiest/most concrete to point out problems (as opposed to the wrong strategy to begin with.)
I agree with A and B as clear parameters to identify. It's something we do not do consistently enough and a very valid point, thank you.
As mentioned, customer acquisition strategies, sales growth, revenue models are my bag. I have a number of SaaS (Whoisvisiting.com, ReplyUp.com, Found.ly and DragApp.com) so this side (growth) is good to scale and has clear planning around it.
My main consideration is around your last point. I am all too aware that engineering are scapegoats. I believe this generally stems from non-technical having a lack of understanding on product engineering and production which leads to divide. This leads me back to my original question, should a non-technical founder learn to code.... :)
It's not a bad question at all. One of the things I've noticed working is that business / dev teams tend to struggle understanding what each other do. This doesn't mean you need to learn to code though - maybe just the basics.
What you need to understand is how business requirements translate into development work. For that, you only need to understand the architecture of the product, and to manually go through the process with a developer a couple of times. I.e. "Hey, can we add e-mail marketing templates to our service." translates into "We need to find or build a marketing email template service, evaluate the cost of that, refer back to the business team, then start implementing it with our code base." Misunderstandings between these teams tend to stem from time estimates - all you need to understand is why adding an email marketing template could take 2-5 days. Learning to code will not help you do this.
If you have a growing team, and solid engineers, I'd stay away from code. I'm a big believer in the concept of "balanced teams," where the product-minded people help answer what gets built, designers answer why and how the users interact with it, and engineers answer how it gets implemented.
I've been a product management consultant for several years, and the best teams I've seen operate where the engineers are trusted to do what they do best. You don't want your team to be limited to your own understanding.
Yeah, it's mainly to be able to guide the business in a more structured, informed way. The thing is, we have a lot of developers now and feel that I can better serve the team with the capabilities myself.
I understand that it is not optimized to be the most proficient but fundamental technical is a requirement?
For what reason? Just to understand more of the inner workings or to actually contribute to the code base?
If the former, I would just learn the basic architecture of the product. There's no real need to know the ins and outs of how the code works.
Yeah, it's mainly to be able to guide the business in a more structured, informed way. The thing is, we have a lot of developers now and feel that I can better serve the team with the capabilities myself.
I understand that it is not optimized to be the most proficient but fundamental technical is a requirement?