Alex Rechevskiy’s Post

Let’s talk about how technical you have to be as someone who is starting their journey as a product manager. This was a common question I got in the sessions I hosted last month, and the truth is at the beginning you are not expected to know how to code but you must have enough knowledge to hold technical conversations. While this is commonly known, I think where people struggle with is knowing where to start. Please do not take a java or HTML for dummies crash course 😋 My advice is to start with the basics, before you pay for a fancy course, begin by understanding the key technical roles in a tech company. What are these roles, and what are they responsible for? By doing this, you start to unearth common terms used by these teams and things start to take form. Next is to actively sort out knowledge on these terms, as we all know there is nothing you can’t learn on YouTube. Search for videos, create playlists attributed to each thing you want to learn i.e an APIs playlist (I have one myself) and start from there. Freecode Camp on YouTube has a lot of resources that break down the most complex concepts into easily digestible content. Lastly, is to remain curious. Curiosity is a key skill needed for growth as a Product Manager. Pay closer attention to the tools you use daily especially from a technical standpoint. For example, that 404 error you encountered, why has it happened and what does it mean? Other things you can check out that occur daily to expand your knowledge are: ✅ How are you able to use your Google credentials to sign in once and then sign into other applications without needing to input your credentials again? ✅ Why is it that sometimes when you try to load a website you encounter the error ‘dns not found’? What even is dns, start from there. ✅ How come Uber is able to pull out locations and show people how long a trip will take based on traffic? Did they build their own ‘Google Maps’? By constantly asking questions and doing some research on your own, with time things will start to make sense. I hope this helps. If you have any further questions, you can send me a DM. 

Last week I completed my second capstone project of the year During the last few meetings I had with my team, when finalizing the development of our product I had asked for a report on everything they did regarding the system design and implementation So when they started throwing terms like “React” “Flutter” and “Dart” I had to quickly google the terms so I could understand them better, I realized that having a basic understanding of technical terms and concepts is crucial for a product manager As someone who transitioned from a non-technical background, I know how overwhelming it can be to get into the technical side of things. But fear not, I've put together a list of basic "tech stack" concepts that can help those transitioning into product management gain a foundational understanding of technical terms without getting overwhelmed. Check out the attached carousel for more details. As a product manager, it's crucial to have a basic understanding of technical concepts. It will help you communicate better with developers, understand user interface design principles, and make well-informed decisions. A few benefits for understanding tech concepts 💡 Understanding how front-end technologies work will help you communicate better with front-end developers and understand user interface design principles. 💡 Understanding back-end development will give you insights into how server-side processes work. 💡 Learning about databases will help you understand how data is stored, retrieved, and manipulated in web applications 💡 Understanding version control, product managers can track changes, review code, and coordinate with developers more efficiently 💡 Understanding how cloud services work will help you make informed decisions about deployment strategies, scalability, and cost optimization. 💡 Understanding web frameworks helps you assess feasibility, prioritize features, and communicate requirements effectively with development teams. If you're looking to transition from a non-technical background to a product management role, take some time to familiarize yourself with these technologies With dedication and hard work, you can become a successful product manager, even if you don't come from a technical background Ps: Share in the comments if I missed anyone out #Day38of100

Great insights! I appreciate engineers who take the time to understand the why" behind a project. It's important to have a shared understanding of the problem we're trying to solve and the goals we're trying to achieve. Collaboration between engineers and PMs is key to creating a solid plan that aligns with user needs and company goals. And as you mentioned, reading the PRD carefully and questioning assumptions can help catch potential pitfalls early on.

Have you ever looked at a project name on your roadmap and thought, “What on earth does that mean?” Recently, I found myself in a meeting where our new feature names were so cryptic, even I struggled to keep up. It hit me hard – if I’m lost, how can I expect our stakeholders to understand? As product managers, we often get caught up in the technical jargon we use with our engineering teams. But when it comes to the broader business, we need to speak a language everyone understands. This isn’t just about naming features and projects clearly; it’s about how we report on them too. Imagine presenting a roadmap where every project name tells a story of its value to the business. Instead of “Project Phoenix,” you have “Customer Retention Improvement.” Instead of “Google Doc Tools - phase 1” you have “Allow highlighting in Google Docs” Simple changes, massive clarity. Clear communication bridges gaps, builds trust, and drives alignment. Let’s keep our language straightforward and our goals clear. It’s a small shift that makes a big difference, especially in remote cultures where every word counts.

"I'm confused about the skills I need to learn to land my first/next PM role" "I'm confused about how to write my resume to land a new role" "I just got a new PM job and I need help with a 30-90 days plan" "I'm struggling in my PM role and need some advice" If you are in any of the above categories, please read on! PS: Please tag an aspiring pm or share with PMs in your networks My PM journey hasn't been a smooth one. I had to learn by trial and error. My journey would have been way easier if I had a mentor. This is why I will be having free 1:1s with 5 (aspiring) PMs. You can ask anything about product management on the call. PS: You have to be subscribed to my free newsletter to book a slot. Book a free slot here https://bit.ly/3UNxJOq. Bonus resources in my newsletter 💡 a playlist on how to become a PM by Google, Facebook, and Microsoft PMs at Product School 💡 Free books by Product School to learn more about product management Follow me and turn on your notification bell to know when I create new resources. PS: What question do you have about Product management? Let me know in the comments

Here I am, two years after signing up for my first product management training. At the time, I knew nothing else and was only certain about one thing: I didn’t want to write code, even though I wanted to work in tech. My motivation was simple — to change the way people work and experience life using technology. Armed with determination, I signed up and completed my first training. Fast forward to the next year, I sought opportunities to intern and volunteer, as I always do when exploring new career paths. I secured an opportunity, and on the first day of standup, I showed up with all the knowledge I had. We got to work, but I soon found myself battling self-doubt. After all, this product was going to be used by real people. That wasn’t enough to stop me, though. Then, the technical jargon began to creep in. We had the classic front-end versus back-end scuffle, and I had my heart in my mouth every time I heard terms like “400 error,” “404 error,” “500 error,” and, of course, “documentation review.” I even questioned whether I was still a product manager. I remember joining late-night debugging sessions, armed with Google, just so I could follow the engineering conversations. Now, two years later, here I am, up at 11:30 p.m. WAT, reviewing a documentation and stumbling across error codes that once scared me — and chuckling. It brings back fun memories and proves how much I’ve grown as a product manager. I believe every product manager may eventually become a “technical” product manager or a product marketing manager.

Code Like a Girl Code Like A Girl Looking from the outside, one might assume I’m a big deal. I've launched many products starting with an idea and earned a big-ticket promotion to Google Engineering Director. My work made a difference to millions of people. But had you spoken to me a year before that fancy promotion, you’d have seen a frustrated Engineering Leader trying to offer value to their users (Googlers) by changing the approach to software development. I tried everything I could. I brought Agile methodologies into Google, to my teams’ dismay. I got Marty Cagan, a product management thought leader, to inspire us to do Dual-Track Agile. Those helped a bit, but it wasn’t enough. Then, I discovered a game-changing product development framework. I know frameworks are often overhyped, but this one helped me drive a positive change in our approach to product development and helped me earn my promotion. I believe it can do the same for you. Let’s dive in. How did it start? My friend, an avid learner, frequently shares valuable insights. Sensing my frustration with traditional product roadmaps, he sent me an article titled: “Why you should stop using product roadmaps and try the GIST Framework” by Itamar Gilad . https://lnkd.in/dWWaEFuP

I just learned about Microsoft Leap today—an immersive 16-week experience for those with a foundation in technical training who are looking to upskill. Excitingly, they’re still accepting applications for both the Product Manager and Software Engineering cohorts! The best part? It’s a paid program, and it doesn’t seem to be limited to just the U.S., so you can take advantage even if you’re located elsewhere. If you’re interested, check out the links below: - Product Manager Cohort => https://lnkd.in/eqWZFic9 - Software Engineering Cohort => https://lnkd.in/ehMNybyg #MicrosoftLeap #Upskilling #ProductManagement #SoftwareEngineering

When teaching product management, I always took time to bust the myth about “the technical PM”. I love how this diagram focuses on the lesser importance of tech knowledge. I would argue, that the PM also needs market expertise more than the UX. Some must have skills for a PM, that are somewhat related to tech knowledge are: ✅ Analytical mindset ✅ Ability to see business/growth limitations of an architecture ✅ Filtering insights from various sources, including data-driven ones You don’t need coding skills. You need to communicate the problem well to people who have better coding skills anyway. You don’t need to know how to work with big data. You need to ask the right questions and choose what’s worth measuring. In fact, the best teams I worked with didn’t care how fast I would write an SQL query. They relied more on me to provide the business and market guidelines to the decisions we *collectively* design. What domain expertise do you consider a must for PMs? #productmanagement

𝐄𝐯𝐞𝐫 𝐟𝐞𝐥𝐭 𝐥𝐢𝐤𝐞 𝐲𝐨𝐮’𝐫𝐞 𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠 𝐭𝐨𝐨 𝐜𝐥𝐨𝐬𝐞 𝐭𝐨 𝐚 𝐩𝐚𝐢𝐧𝐭𝐢𝐧𝐠, 𝐧𝐨𝐭𝐢𝐜𝐢𝐧𝐠 𝐞𝐯𝐞𝐫𝐲 𝐛𝐫𝐮𝐬𝐡𝐬𝐭𝐫𝐨𝐤𝐞 𝐛𝐮𝐭 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐭𝐡𝐞 𝐰𝐡𝐨𝐥𝐞 𝐦𝐚𝐬𝐭𝐞𝐫𝐩𝐢𝐞𝐜𝐞? When transitioning from a technical role, like software development or design, into product management, you might think, "With my technical background, I’ve got a head start." And while those skills can be incredibly helpful, they can also become unexpected traps. One recent example: during a product research session, my developer instincts kicked in. Before I knew it, I was knee-deep in code analysis, checking integration feasibility, and even troubleshooting code issues. Valuable as these skills are, I realized I was drifting from my core PM responsibilities. In product management, time is precious, and getting caught up in technical details can pull you away from the bigger picture. Here are a few strategies I’ve found helpful in staying focused: - Lean on team’s expertise: Instead of verifying everything yourself, ask the right questions to gain the insights you need. - Set Boundaries: Allocate specific time slots for technical checks, then quickly pivot back to high-level tasks. It’s all about balance—knowing when to lean into your technical skills and when to step back. This awareness keeps you focused on driving the product forward and seeing the full picture.