At a large public company, I am a young PM with a non-technical background who presently owns a platform product.
I hold a business degree and gained one year of technical sales experience at a smaller startup in the same industry (SaaS ERP) prior to beginning this position two years ago.
I am willing to develop my inadequate technical expertise.
Any advice is highly appreciated.
I shall describe what I did.
Learn SQL. Begin by enrolling in a course and examining some of the tables of features that you frequently utilise. Perform some rudimentary queries to obtain the desired results from the first table, then study joins with two or more tables, and so forth.
Install Sourcetree and local code on your computer. Obtain it in an Ideation as well, or utilise Notepad++ or Sublime. Examine any flaws. Constantly reproduce them, become an authority on certain features, and ensure that you are personally present to inspect for defects. Determining which line of code (or section) a problem fails on will teach you a great deal; you may even be required to request access to the logging. You will eventually deduce that a portion of them are null/nill errors. Understand fundamental data types such as string, integer, and decimal.
Become proficient at calling an API endpoint. Commence with a leisure period. Following GET data, offset, and pagination, you post/put. Gain an understanding of how xml and Json function. Determine how to resolve problems there as well.
Request that developers demonstrate how they think and do. Particularly when half of what they say is beyond your comprehension. Minor components of the puzzle gradually gain coherence.
Greetings from a PM who will begin working as an integration specialist next month. Stakeholders and hippos, farewell.
Totally agree. Learning SQL is a great entry point as it will provide a solid foundation for understanding and manipulating data in databases. Additionally, familiarizing yourself with different database management systems such as MySQL or PostgreSQL can further enhance your skills in working with data. These skills will be invaluable as an integration specialist, allowing you to effectively retrieve and manipulate data from various sources to meet the needs of stakeholders.
SQL is OK but what you really need is to understand algorithms conceptually. Query languages are just that - syntax for asking questions of data. Understanding algorithms conceptually is crucial for becoming a proficient integration specialist. It allows you to think critically and strategically when designing efficient data retrieval and manipulation processes. While SQL and query languages are important tools, having a strong foundation in algorithmic thinking will enable you to optimize these processes and solve complex data-related problems effectively.
They (SQL courses) are considerably more than that. They provide data, allowing you to support your arguments with facts rather than sentiments. One can enhance their robustness and validate certain aspects. And in many cases, it will provide guidance even in the event that you are unable to retrieve or manipulate the data directly. Additionally, having a solid understanding of data analysis and interpretation can help you uncover patterns and trends that may not be immediately apparent. This can lead to valuable insights and informed decision-making in various industries, such as finance, marketing, and healthcare.
A comparison to algorithmic processes is akin to contrasting fruits and pears. Additionally, algorithms are not required for all tasks. It is my belief that every novice to intermediate PM requires SQL and should devote some time to working with data to better comprehend it and its potential impact on their projects. Furthermore, being proficient in SQL allows project managers to effectively communicate with data analysts and engineers, ensuring that the right data is collected and analyzed for informed decision-making. Ultimately, incorporating data analysis skills into project management can greatly enhance a PM’s ability to drive successful outcomes and deliver value to stakeholders.
BTW, What’s an integration specialist??
I think, @MartyRoss, someone in charge of integrating their app with a third-party app is called an integration specialist, in my opinion. They will collaborate closely not only with the engineer but also with the partnership team, as there will be considerable agreement-making to occur there.
An integration specialist is a professional who specializes in integrating different systems, applications, or technologies to ensure seamless data flow and interoperability. They are responsible for designing, implementing, and maintaining integration solutions that enable various software and hardware components to work together efficiently. Integration specialists play a crucial role in bridging the gap between different departments or teams within an organization, ensuring that data is properly synchronized and shared across systems. Their expertise is essential in streamlining business processes, optimizing workflows, and maximizing the overall efficiency of an organization’s IT infrastructure.
In which areas do you perceive the most significant deficiencies reside? Does your lack of comprehension pertain to the architecture of your product? Do you encounter difficulties in comprehending the technical obstacles or compromises that the development team is deliberating? Are your consumers primarily technical in nature? If so, do you encounter challenges in comprehending their requirements or practical applications?
An exceptionally vast array of technical knowledge is accessible to any PM. However, it is possible that a more limited range of factors will have the greatest influence on you, contingent upon the requirements of your position.
If you want to learn more how things work on a high level, then you should learn “systems design”. Check out the System Design Primer and walk through all of it
If instead you want to understand more of the coding side of stuff, I recommend the following
Technical doesn’t necessarily mean coding or program language.
Find a good solutions architect and learn to interpret ADDs.maybe.
Sponge and ask around the nested HOW stories to the what
Learn to link the translation from user need to technical solution. At a high level. Then peel the onion.
Maybe around scaffolding. Got a DevOps CI CD guy. ?
It’s all situational
This type of subject fascinates me because it is contingent upon the definition of “technical” and your own expectations. Typically, the reason you feel insufficiently technical is because of the following:
You observe that other individuals in your role are more “technical” in nature than you are.
You are engaging in discussions that you do not completely comprehend (or only partially comprehend). If your issue is with 1. I would seek out that individual and make an effort to comprehend how they arrived at that point in order to determine whether or not it makes logic to follow in their footsteps. if not! Should the issue lie with 2. Feel free to raise your hand and inquire about the meaning or operation of the given term, for example. I “learned” technical information through inquisitiveness, attending a QA session on a backend feature, and posing a thousand questions. Additionally, reading engineering journals is extremely beneficial. Individuals who elucidate the process of construction. Observing tech lectures (pydata, media.ccc.de, and the NDCC conference are all highly recommended): I used to have a bi-weekly meeting with a developer from the team at a previous employer, during which we would each bring a product or development-related topic for discussion. He defined what an API is; I attempted to summarize and comprehend it thoroughly, among other things.
However, keep in mind that your primary responsibility and expectation is to identify the issues rather than to find solutions. You may actively communicate and interact with the engineering team when you encounter or discover a problem, but that is ultimately beyond their purview.
Following my graduation from business administration school, I began working in OPS/incident support. I progressed from Business Analyst to Product Manager over time. This experience was extremely beneficial to me. I mention this because, prior to beginning OPS, I had no knowledge of technique.
I believe that problem-solving, speaking, and experience are all beneficial. Consult with your OPS colleague and request an explanation of the incidents that are taking place. Attempt to comprehend the situation by inquiring about the numbers and the workings of this. Continue asking (ignorant) queries; eventually, something will make sense in your mind; therefore, you should not be concerned with your lack of comprehension; rather, persevere.
Participate actively in technical meetings by posing inquiries. Certain project managers are indifferent to the technical “how,” while others find it excessively complex. A few people firmly believethat they have no place in such discussions, for whatever reason. However, it is important to actively engage in technical meetings and ask questions to gain a better understanding of the incidents and their impact. By seeking clarification on the numbers and mechanics involved, you can gradually piece together the puzzle and make sense of the situation. Don’t let your initial lack of understanding deter you from continuing your quest for knowledge. Remember that some project managers may not prioritize understanding the technical aspects, while others may find them overwhelming. However, it is essential to recognize that everyone has a role to play in these discussions, regardless of their background or expertise.
Don’t be too technical; pride kills any chance of growing into product leadership. Instead, focus on actively listening and asking questions to gain a deeper understanding of the technical aspects. By doing so, you can bridge the gap between your expertise and the technical team’s knowledge, fostering collaboration and effective communication. Embrace a growth mindset and be open to learning from others, as this will ultimately enhance your ability to contribute to product leadership. Remember, it’s not about showing off your technical prowess, but rather about leveraging your skills to drive successful outcomes for the project.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.