Technical Expertise for Competitive New PMs

By Leslie Cook
Posted on January 2, 2024

Welcome to our Product Newsletter, a biweekly email highlighting top discussions, and learning resources for product managers.

What We Will Cover In This Edition:-

Top Discussions:

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

2) Am I really unlucky or have bad company-picking skills during interviews?

3) Estimating a story

Top Learning Resources:

1. Build, Measure, Learn: the Product Management Lifecycle Loop

2. Leading Through Shared Goals

3. Overcoming Impostor Syndrome in the Product World

__________________________

Top Discussions

Question 1) 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?

– Juan Allo

Discussion

A] 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.

– Marco Silva

B] 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.

– Tina Greist

C] 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.

– Karan Trivedi

__________________________

Question 2) Am I really unlucky or have bad company-picking skills during interviews?

I have been a Product Manager for almost five years and have experienced job turnover in three different companies. The first company was a large corporation where they grew tired of office politics and eventually left. Then I joined a startup, but it only lasted six months before layoffs occurred due to funding issues. Then, I am now at a medium-sized public company for seven months, but there are rumors of potential layoffs. I speculate that my experiences might be due to a combination of bad luck, bad timing, and possibly not asking the right questions during job interviews.

– Kane Morgan

Discussion

A] You might want to consider the fact that changing jobs frequently is more common and pays better all around. Having said that, you must have held a PM position for at least a year for me to think you had a big impact. Frequent job changes are increasingly prevalent in today’s dynamic job market, driven by various factors such as career growth opportunities and higher compensation.

However, it is crucial to note that while changing jobs frequently may offer financial benefits and diverse experiences, it is essential to demonstrate stability and longevity in a Product Manager (PM) role to prove significant impact. Holding a PM position for at least a year showcases your ability to navigate complex projects successfully and make substantial contributions to the organization.

– Bobby Duncan

B] The phrase “my team got laid off” is a completely acceptable excuse for being unemployed. Kind of OK. From the recruiting manager’s perspective, it’s neutral to favorable because it’s a simple victory if we succeed in bringing good people onto the team. Additionally, it shows that the individual was part of a team and had experience working collaboratively. However, it is important for the candidate to also highlight their individual contributions and achievements during their time with the team to further impress the recruiting manager.

– Whitney Chard

C] @WhitneyChard, make sure you can explain what you would have done to make a profitable pivot with sufficient resources. A good story can turn it into a positive, as someone with a 6-week employment record on my résumé can attest. In order to make a profitable pivot with sufficient resources, I would have conducted a thorough market analysis to identify emerging trends and potential gaps in the market. This would have allowed me to align my skills and experience with the demands of the industry, increasing my chances of success. Additionally, I would have networked extensively with professionals in the field, seeking mentorship and guidance to gain valuable insights and advice on navigating the new venture. By leveraging these resources effectively, I could have developed a solid business plan and implemented it successfully.

– Dianne Stinger

__________________________

Question 3) Estimating a story

As a product manager, there are several procedures I follow when estimating story points with my teams. Firstly, I ensure that we have a clear understanding of the user story and its requirements. This involves collaborating with the development team and stakeholders to gather all necessary information.

Next, we break down the user story into smaller tasks, or sub-stories, to get a better grasp of its complexity. This helps us identify any potential challenges or dependencies that may affect the estimation process.

Additionally, I encourage open discussions and involve all team members in the estimation process to ensure a more accurate and collaborative effort. This approach fosters better understanding and alignment among the team, ultimately leading to more reliable estimates.

As a product manager, what procedures do you follow when estimating story points with your teams?

– Cathryn Cui

Discussion

A] It’s ironic that this is an important project management skill. I mistakenly believed that product management didn’t conduct project management, but it does by being able to accurately estimate the work for a project or product roadmap and report it back to management for how long things might take.

Scale the difficulty up using the Fibonacci sequence, and then use sprint planning to get your engineers to come up with a number. Divide your stories into manageable chunks.

The issue arises when one development team is working on several products and engineers are divided among them. This situation is made worse in large company settings when one team depends on the output of another. Then you plunge into the demonic enterprise-scale agile framework, or more accurately, waterfall with agile lipstick.

You can go back to hour estimation and then have the developers clock time against each task if you have a strong engineering manager who is realistic about how long excellent developers should actually take. This is challenging because competent engineering managers who understand this are hard to find.

– Felipe Bibeiro

B] This is our challenge now. Flat organization with teams working across multiple domains and products. Also, we currently don’t have an EM, scrum master, or project manager. A lot has to rely on the senior developers to help refine and keep to some sort of time line, which can be challenging without dedicated management roles. Without dedicated management roles, the team may struggle to effectively coordinate and prioritize tasks. This can result in missed deadlines and a lack of overall progress.

– Natasha Martin

C] Just now, I brought up the subject with my lead. It will never be entirely correct. When you look at it from a high level, it’s really just a mechanism for us to make an estimation of how much can fit into a sprint, but it’s not a precise representation of how much work a developer must actually complete. Generally speaking, it’s relative but not quite accurate.

Gaining a general understanding of effort is, in my opinion, somewhat beneficial, but it can’t be taken as gospel. As the number increases, the accuracy of the Fibonacci sequence decreases due to divergence.
Use it as a tool, but don’t take two 3-point stories as being absolutely equivalent in their efforts.

– Elvin Henriques

__________________________

Top Learning Resources

Build, Measure, Learn: the Product Management Lifecycle Loop

The build-measure-learn loop is at the core of the Lean methodology. Learn how to use this framework to create continual value for customers and your team at every point of the product management lifecycle.
Build. Measure. Learn.
Each of these concepts is core to the way product managers and teams categorize their work. Teams flow in and out of these concepts throughout the product development lifecycle—each expanding on the last to help create value for your customer.
Each step of this build-measure-learn loop helps your team deliver continual value to customers faster, without sacrificing quality or adding complexity to your process.

Leading Through Sared Goals

As the person in charge of a product, you are responsible for achieving product success. But can’t do it on your own: You rely on the help of the development team and stakeholders who design, implement, test, market, sell, and support the product. To ensure that their work results in a successful product, they must move in the same direction. Otherwise, the product features, the marketing messages, and the sales channels might either be wrong or they might not fit together.

Overcoming Impostor Syndrome in the Product World

We’re here to teach you important skills and methodologies for Product Management, and having good mental health is as important an asset to any PM as data skills and tech know-how.
Impostor syndrome is the feeling of not being good enough or that you’ve somehow blagged your way into your job. You may feel as if you’ve tricked your colleagues into thinking you’re capable of getting the job done, despite not actually having the skills needed.

__________________________

If you enjoyed this newsletter, please consider sharing it with a friend by asking them to sign up here.

Who’s Prowess? We are optimist product managers, engineers, and educators working on creating a world where merit meets opportunity. On Prowess, aspiring and experienced product managers showcase skills, learn from the community, and connect with employers to advance their careers.

How can you grow with Prowess?