What technical expertise should a new PM learn to be competitive?

Despite the fact that I manage operations and collaborate closely with our product team, I have never held a position in product development. I would prefer to move into product after five years in operations without having to start from scratch, though.

Everyone online appears to advise against purchasing a product course because it is either seen as a waste of time or a sign that you are a beginner on your resume.

Are there any technical abilities I should hone to help me find a job? For instance, would taking a SQL course be beneficial? How do I learn Jira? Study CSS? enroll in a UX course? Etc.

Before switching to product, I’d like to spend the upcoming months expanding my skills and building my resume. What is the best way for me to spend my time?


IT-related skills are not crucial for product creation. It all comes down to communication. The great software Product managers are also familiar enough with development, quality assurance, and devops activities to talk intelligently and recognize when an estimate is inaccurate, but none of us are required to be proficient in any of those tasks. To correctly determine whether a design is good or great, you should understand a little more about UX. The most crucial ability is, by far, communication. Be an excellent writer of specifications, product descriptions, and associated marketing material. Be an excellent seller and presenter.

You must persuade executives—who create features based on hearsay—that well-researched features that address customer pain points are more important than their flimsily considered concepts. You must be correct. Be the best interviewer in the world and avoid forcing your opinions on the subjects that interest your audience. Observe body language and facial expressions during the interview to decide what questions to ask next. Create brevity-focused questionnaires with high response rates and precise instructions.

Although other people can run the queries for you, you are skilled at analyzing data on product consumption. You can support any design choice if you are aware of your users’ needs, wants, and pain areas. Get comfortable using your power and influence in a cordial manner. It is “everybody’s” product, but you are the one who must pay for it.


In the end, this inquiry is what it feels like it is—a novice question. What or where is the best place or method to polish requirements writing?

My company is small and doesn’t strictly adhere to many standard practices (although they claim to be “agile” and use SCRUM). I switched from front-end/analytics to PM after working in web content. Currently, I’m working on two significant projects. The first is a lengthy technical requirements document for a sizable website redesign that might end up being 100 pages long, depending on how many criteria need to be outlined. And a simple request to update functionality we already have, although it will require modifying the web and the database.

I am unable to tell when I am doing one of these two very distinct things too little or too much. We delayed the small request a little because the major rework was more important, but even if it were only a few lines, I would be afraid about the reaction of the stakeholders. Things like, “This is what we waited months for?”

As deadlines approach, I feel disoriented and anxious since it seems like they require new structures and degrees of detail. I fear that I haven’t truly mastered this ability the way I thought I had.


I think @MarcoSilva and @TinaGreist are right.

IMO, hold meetings, write stories, organize requirements, and capture requirements. As you sort through the stories, you’ll probably consider details that the group might have overlooked and develop more demands or talking topics for subsequent conversations and/or sessions. Ensure that all requirements are approved through email so that you can go back to them as necessary.

Even an entire group of people will occasionally fail to meet the requirements, which lessens the impact of subsequent failures and reduces the likelihood of blame games. Whether you need more than a few lines of requirements—the stakeholders at those meetings will let you know—or whether that is enough, is ultimately up to the project team to decide.


If you want to avoid waterfall development, avoid writing a 100-page requirements paper. Decide on some simple starting steps as your goal. Describe the conditions for those. It’s okay if the initial stages are too short to solicit feedback from stakeholders.

Making a website where users can log in is something I like to do. You can establish goals, check to see if you’ve reached them, etc. When you log in, nothing appears, but it’s a step. After that, you decide what to do next. The page might provide some information. Instead of attempting to define the site all at once in one shot, you gradually build it up over many steps.

When you have enough, you may start allowing users to provide feedback. Based on the comments, you make changes. As the input increases, you add additional concepts. This is a more flexible strategy where you adapt what you already have and what is on the way based on actual usage. Additionally, it enables you to deliver incremental value because you don’t have to wait for everything to be specified, scoped, built, deployed, etc. before using some features.


It appears that your company has already committed to these two projects. Because you and your teams may choose what to create without conducting a lot of additional research, it makes the following phases a little easier. I would meet with the team several times if I were in this situation. Talk through a design and a plan in each meeting, and designate one person to act as a scribe so you can concentrate on guiding the conversation. You will be able to create stories from the meeting notes once you have read through them. There are undoubtedly several kinds of strategies that might be effective in this circumstance.


Sincerely, it really comes down to expectations and communication.

Stakeholders in the business want X. At least, that is what is said. Can the validity be supported by data and ROI? Can it be evaluated through study, evaluation, interviews, mockups, or prototypes? What kind of value will it produce, and how can you check to see if it’s coming in?

Then you construct it. Do your teams have a plan for what to design and construct? Are the specifications clear? What about user stories, as there are several user types and various user journeys? How do you know when something is finished? Do analytics need to be added? What kinds of important metrics … and so on.

Don’t then just fire and walk away. You started it off. Did it carry out as predicted? Was the ROI what was predicted? Have your users responded? Do you need to modify anything? How do your metrics make you feel? What can you discover?

Frameworks (waterfall, agile, scrum, etc.) and specific tools (Jira, Miro, etc.) change with time. Use the proper tool for the job at hand, but don’t become fixated on it. If they are damaged, fix them; if they don’t function, replace them. However, it’s beneficial to read the Scrum Guide to gain a sense of how the PO functions inside a normal team from that angle.


Just exercise your ability to define user and business success for a product, and then design things that achieve or aid in that accomplishment.

Every tool is only a means to a goal; there is no one instrument that will always be useful for the function. SQL is merely a popular method for obtaining and modifying data; it has no inherent value. If sacrificing a goat in a ceremonial way allowed you to draw conclusions from the data, that ability would be just as helpful as SQL.

Less attention should be paid to tooling, and more attention should be paid to the goals that those tools are intended to achieve.


It’s a toss-up between debugging abilities and writing SQL queries if I had to recommend just one talent. But that is only a tiny part of the job. You need a variety of abilities, such as marketing, business writing, communication, leadership, project management, strategy, business analysis, and much more. You must be able to transition seamlessly from speaking with readers of your blog to emailing CEOs. Yes, this work is not simple, and you may not know as much as you believe. and just when you believe you have a good handle on the responsibilities, they add another task to your plate. It’s a terrific career if you have a great workplace and some great mentors; if the company culture is one that reinforces negativity, it will be rough.


What sort of PM are you hoping to become? technical or platform?

Then you want to concentrate on SQL, Python (basics), a brief introduction to Git, and some fundamentals regarding data structures as pipelines. Experience will teach you the rest.

Core PM with a front-end emphasis? Start by studying Figma or a program of a similar nature; you might also want to study MixPanel and user journey instrumentation. Develop system design skills to provide value there. It’s useful to have HCI theory.

By enabling you to do a first pass on solution ideation and to write better acceptance criteria that are succinct and hit the right notes for engineers to understand the need and what to change in the software, these skills, in the end, highlight your core competency of understanding the customer.


Working at a small software company with fewer than 200 employees offers a unique opportunity to accelerate your learning curve. With a smaller team, you will have more direct exposure to various aspects of the software development process, allowing you to gain hands-on experience in different roles and projects. This dynamic environment fosters a collaborative atmosphere where you can quickly expand your skills and knowledge base.


Find relevant people on LinkedIn who have had similar journeys as yours. And reach out to them to understand how they transitioned to PM and what they learned. Connecting with professionals on LinkedIn who have gone through a similar career transition can provide valuable insights into their journey and the lessons they learned along the way. By reaching out to these individuals, you can gain a deeper understanding of the steps they took to transition into a project management role and gather valuable advice on how to navigate the process effectively. Their experiences and knowledge can help you make informed decisions and accelerate your own learning curve as you pursue a career in project management.


Prioritization techniques and communication (presentations, individual and team) These two skills are essential in any professional setting. Prioritization techniques help individuals and teams effectively manage their workload and focus on the most important tasks. On the other hand, communication plays a crucial role in conveying ideas, collaborating with others, and ensuring that everyone is on the same page. Presentations, whether to a small group or a large audience, allow individuals to showcase their work and articulate their thoughts clearly. Overall, mastering these skills can greatly enhance productivity and success in any professional environment.


SQL is a great tool. The data can be used as you like to aid in decision-making or uncover opportunities. Additionally, you shouldn’t bother engineering with your data requirements.

My PM is capable of using SQL, and it is beneficial at least once per week. The regular use of effective data analysis and well-informed decision-making can be made possible by having a PM who is skilled in SQL. Additionally, it eliminates the requirement for ongoing technical team involvement in data-related queries, saving time and money. Having a PM who is proficient in SQL allows for efficient data analysis and informed decision-making on a regular basis. This not only enhances the overall effectiveness of the team but also reduces the need for constant technical support, resulting in cost and time savings. Furthermore, the ability to customize data visualization and reporting based on individual preferences empowers the PM to uncover valuable insights and identify potential opportunities.


Designing interactions.


The one thing that will immediately benefit both sides of your communication map and raise the caliber of everything that results from comprehending it is that one thing.

You can kill as many “birds with a single stone” with it as you can because it is also the node around which the majority of the depth and breadth of the product revolves (goal: all, and yes, it is achievable).

Good luck!

1 Like