In a private community last week a "non-technical" product manager asked:
"As a product manager, is a 3-month coding bootcamp (full-time) a good investment of time and money? I sometimes feel limited by my tech skills. Thoughts?"
Yes I have thoughts! I'm not sure that bootcamps are always worth the money whatever your goals are, for example. I replied to the original question in the thread and decided to write up my answer as an article on prod.fyi.
Interestingly, the original asker responds:
"For some reason, I feel like all people with programming knowledge advise against coding bootcamps and many people who started without programming knowledge say it is very helpful. It's a paradox that I haven't fully made sense of yet!"
Here's my perspective, as a "technical" product person:
A technical background can be your secret weapon as a product person if you can use it to get an advantage. Marty Cagan says: “Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible.”
Can your technical knowledge give you the edge? Can you combine your deep technological understanding with your strategic view of the market to come up with that great “just now possible” product idea?
Read the rest of this article here: https://prod.fyi/articles/should-you-learn-to-code
Hit reply if you've got any feedback, good or bad. I'd love to hear from you.
- James Browne, prod.fyi
Hi! Much writing about digital product is tactical - it’s easier to write tactically. The problem space is contained. You’re likely to be able to suggest a process that will help. Most work early on in the trenches is tactical, so you’re likely to have direct hands-on experience. At the other end - the strategy end - it’s more of a challenge. Processes certainly exist, but the problems are less well-formed. You also don’t make big strategic decisions every day, so hands-on experience is...
Service is Noble: Responding to Empowered Agile, a respected agile practitioner points out that “‘service’ is a bit of a loaded term. He’s using it in a negative sense… and he prefers empowered agile teams with a product mindset”. That’s a fair criticism - reading the article back it looks like I’ve cast “Service Agile” as a villain against our hero “Product Agile”. What I really think is that you should use the right tool for the job. I’m a big Simon Wardley fan, so to quote from his...