There’s no question that managing teams of developers and engineers is one of the greatest challenges for a PM. Without the technical background, it can be hard to get things done without the help of engineers and developers. However, this doesn’t mean that technical knowledge is necessary for a PM to get their team to respect them.
– Heather Kurtz
Discussion
A] There are plenty of excellent suggestions here. Be frank and honest about your ignorance, and I’d include that as well. Don’t rely on others to teach you everything or go over concepts that are simple to understand on your own; instead, ask questions when needed. Make every effort to create a path that will allow them to concentrate and complete the assignment while adopting a servant leadership mindset.
– Ana Rodrigues
B] I can only think of the following:
Avoid being a snob. Not just the PM, but the entire team, is the product.
Make room for research, not only development, paying off technical debt, or general advancements. People can better feel connected thanks to it.
Look for opportunities to make them more prominent in front of the leadership. Not only present their work, but also help them prepare and deliver it.
– Maria Wilson
C] I imagine this is an unpopular viewpoint on this site, but I should pick up some technical knowledge. Many engineering teams won’t fully appreciate you if you don’t have a basic understanding of how applications and APIs operate. Obviously, a lot of this depends on the business and the engineers.
However, understanding how to create a simple application, some programming concepts, and how to use APIs is not a particularly challenging ability to pick up.
You can probably learn it for less than $50 in a 50–100 hour online course. Think of managing a restaurant without ever having prepared a meal. There are many things you’ll lose out on. I’m not saying that if you lack technical skills, you can’t be a competent product manager. I believe anyone would be better off if they learned some minimum skills.
I was scrolling the topics in this community the other day when attempting to understand more about my new profession and its background. I was fortunate enough to be able to transition into a Product Manager position after a little over a year of working in a more operational function inside a software company.
At my organization, PM is carried out a little bit differently from the “standard” (not that there is a norm); I am a PO for a dev team as well as a PM for x realm.
I’m having trouble figuring out what I SHOULD be doing as a PM right now. I doubt my actions every day, thinking “I should have done x, y, and z to be more like a PM,” due to my lack of formal training and the fact that I work for a company where I am left to fend for myself (something I don’t mind 90% of the time).
Because my Product Ownership doesn’t take up all of my time, there are times when I feel a little lost because it’s expected of me to assist with operational issues (or at least give some understanding of what might have caused them).
I ecause my Product Ownership doesn’t take up all of my time, there are times when I feel a little lost because it’s expected of me to assist with operational issues (or at least give some understanding of what might have caused them).
Any assistance is greatly appreciated.
– Natasha Martin
Discussion
A] After so many years in PM, I still feel lost, but I can’t say for everyone else here. Don’t let that bother you, keep getting better, and congratulations!
Don’t stress over what the “ideal PM” looks like, in my opinion. You might learn a lot working at a smaller company, which is what it sounds like you do. I’d advise you to look for opportunities to fill in the gaps on your staff. What can I do to offer value for the user and what can I do to make life easier for my team are fantastic places to start. Create ideas, rank them (for example, “create a roadmap”), and evaluate them using criteria you believe would indicate success.
I agree with Cracking the PM Career in terms of literature. Other books that have been useful to me are Extreme Ownership, Never Split the Difference, and Escaping the Build Trap. The majority aren’t PM books, but rather are focused more on communication, culture, and leadership, which I’ve found to be incredibly helpful in my professional life.
I’ve heard excellent things about the Reforge series if your employer has the funds, but I won’t be seeing it firsthand until the spring.
– Richardson Eva
B] True, being proactive sets exceptional project managers apart from average ones.
Three suggestions:
Join product twitter and start participating.
Read and follow blogs and product mailings.
Speak with other PMs
You can learn how to be the greatest, most proactive PM you can be for YOUR environment by doing these things.
– Jesus Rojas
C] PM is more art than science. It is closer to running your own business than say, writing code or managing a laundry list of features.
You are filling the gaps in every aspect of the product. Every product/company has vastly different resource pools. You may need to play the role of UX, data analyst, QA, marketing, sales or service depending on the situation. Just like a small business owner needs to be a cashier, inventory, waiter, marketing, etc.
Ultimately you need to focus on the following:
Is your product growing in revenue/users?
Is your stakeholder happy? (This often involves delivering things not important to you, but essential for someone senior)
Are you taking advantage of all the resources available to you to reduce your day-to-day operations so you can focus on more strategic things?
Hello everyone. I work as a PM for one of the larger tech companies in my area. PMs, in my opinion, are more concerned with business objectives, product strategy, and motivating developers and designers to achieve product objectives.
But ever since I started working, I’ve been highly involved in sketching out backend system ideas. When I recently sought comments, my boss actually said that I should sharpen my database design abilities and be more aware of how backend systems interact with one another.
Is this typical for PMs in general? Or is this the typical behaviour of a technical PM?
– Pouya Taaghol
Discussion
A] In my opinion, this is not typical for any PM, technical or not. I might join discussions if I believe that engineering has a strange design or something that might not support future use cases successfully. Still, engineering and your architect should be in charge of the database design to ensure that it fits well.
I may also create sequence diagrams to illustrate how I envision a process’s flow. Still, again, I’m not trying to design anything other than to demonstrate how it might work within the context of the design and the scenarios we need to handle.
Even in strictly backend PM work, the use cases you wish to address are everything. Define its intended use, not how its designed.
– Rob Martin
B] Hi – I have experience as a front and back-end B2B PM, and I believe that you should understand WHAT the API does, including WHAT data it gives, rather than HOW it does it.
The best way to approach this is to consider the API to be a product that merely enables other products to service users. Therefore, if you consider every use case that could be resolved, you can abstract that into a specification for the data that offers adaptability, durability, and robustness to address the issue, and then provide a good product need for the data.
For e.g., we are currently developing a particularly crucial API that provides specific types of metrics. Instead of only providing the metric that is required right now, we could easily provide multiple views of the important metric over a range of typical time periods as well as some raw numbers that could be used to contextualize the statistic for a variety of use cases.
– Naomi Nwosu
C] Not usually, but it can vary. It can be simpler to communicate with developers and establish confidence if you are aware of the ramifications of specific database formats and APIs.
If I hadn’t been able to comprehend various components of the database and how they related to one another, I don’t believe I could have been effective at my previous employment. It became a bigger issue when there were certain organizational changes.
I don’t know how to talk to some of these guys, the chief of the development team said at that moment. We can discuss the potential effects of modifications if I design some database structures for you to grasp while we are speaking. When I describe it to others, they don’t comprehend it, and I have no idea how to execute it.
A situation quite similar to APIs existed. Being able to examine the current APIs, comprehend how to translate customer expectations into API requirements, and discuss the effects of various implementation possibilities for new ones were all very beneficial.
Schemas and API documentation were never presented to me at past employment until I actively asked to see them. When I asked to see them, the developers were astonished because they had left that information out. This appears to be the more typical circumstance.
MVPM in no way implies that you need to achieve mastery of its skills to be effective, which is both impractical and counterproductive for someone starting out. Instead, view it as a syllabus of sorts for the course in product management that doesn’t exist.
As the head of product, you play a key part in developing the people on your team, creating an environment that helps them succeed, and improving the effectiveness of the product management function in the enterprise.
While product managers focus on the customer problem and solution (the what, the why, and what the customer experience should be), the core focus of engineering is the technical implementation details. These are two completely different perspectives. Bridging this gap is essential but it can be a messy process and the how is not often talked about.
__________________________
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.