A few months into my first position as a PM. Engineering led culture and pretty much only PM for now. I’m a technical PM and my stakeholders are engineers, not end users.
I am involved with projects that increase developer productivity and cross-functional coordination. I’ve conducted user interviews, run meetings, and acquired feedback thus far.
By facilitating workshops and working on prioritizing issues, I’d like to promote a more involved and cooperative approach so that I can then build a roadmap. I haven’t been able to do that up to this point because I’ve seen how the engineers can handle communication through Slack and agreement on a proposal.
I’m not seeing the value I bring to the table and am looking for original concepts or patterns that could aid in reducing conflict between the teams working on the client side, operations, and development.
There isn’t much theory out there that I can use other than what I can think of on my own because it seems to be geared more for end users.
In my opinion, I should build up my credibility by achieving few rapid victories and releasing a feature internally. I’ve successfully managed a few projects that I thought were quite straightforward, but nothing that called for a Product person.
When I try to follow up more than once, some tech leads don’t respond to my slack messages. I’m not sure how to handle this situation.
I agree @QuinnGomez; initially, I had a lot of views, but I gradually humbled myself. To meet an approaching deadline, the organisation, however, underwent a significant amount of reorganisation, and a large number of new hires were welcomed in the most recent months. It’s a good place to be in terms of developing strong processes, but challenging because the culture is driven by engineering and there are no PMs to lead it.
It sounds like you’re doing a lot of the right things already! As a new PM, it’s common to feel like you’re not making an impact or not sure what value you’re bringing to the table. Here are a few suggestions that might help:
Keep learning: Even though you have a technical background, there’s still a lot to learn about product management. Make sure you’re reading books and blogs, attending webinars or conferences, and networking with other PMs. You can also consider taking a course or certification program to deepen your knowledge.
Get feedback: Ask your stakeholders (especially your engineers) for feedback on your work. What do they think you’re doing well? What could you improve? This will help you better understand how you’re perceived and where you can focus your efforts.
Identify quick wins: Look for opportunities to make small improvements that will have a big impact. For example, is there a process that’s causing a lot of frustration among the team that you could streamline? Is there a feature request that’s been sitting in the backlog for a long time that you could prioritize and ship quickly?
Be persistent: If someone doesn’t respond to your messages, it’s possible they’re just busy or didn’t see it. Follow up once or twice, but if you still don’t get a response, try reaching out through a different channel (e.g. email, phone) or looping in a manager or someone else who might be able to help.
Collaborate with the team: It’s great that the engineers are communicating well on Slack, but there’s still value in bringing people together for a workshop or meeting. Try to find opportunities to collaborate with the team in person or virtually, and be open to their feedback and ideas.
Focus on outcomes: Remember that your goal as a PM is to drive outcomes for the business, not just to manage tasks or processes. Make sure you’re clear on what success looks like for your projects and how you’ll measure it.
Finally, don’t be too hard on yourself! It takes time to build credibility and establish yourself as a strong PM. Keep learning, stay persistent, and focus on delivering value to the business.
Ask questions, even if they feel dumb, until you develop deeper insights on topics (ideally customers and their needs) than others have.
If you’re working on a platform product, the engineers are your users and you need to be expert in what they need.
looking for original concepts or patterns that could aid in reducing conflict between the teams working on the client side, operations, and development.
This is project management, not product management, I’d be careful about focusing your time here. There’s much better things for you to do.
Some tech leads, as you indicated, don’t reply to your messages. You should focus on developing stronger connections with these people, in my opinion. I really can’t offer advice without knowing the dynamics of your team. Attend any stand-up meetings or other Scrum gatherings? Try following up during such meetings, if you can. You use your scrum master’s assistance in motivating the team if you have one. Engineers occasionally experience extreme busyness, which could account for their lack of response. Also, if the technical staff is accustomed to doing things their way, trying to convince them to do something else will be extremely difficult. In order to build relationships with people who can aid you in achieving your objectives, I would strive to understand team dynamics.
@KaneMorgan, I do go to standups, but because I deal with over 8 teams spread across 3 engineering organizations, I find it difficult to keep track of everything. My top concern right now is to prevent it from happening even though I’m attempting to be more organized and things tend to get lost in the weeds.
I work with a TPM, however it’s only for one organisation.
I’ll follow your advice and make more calls rather than set up further meetings.
The first step is to learn how to take notes exceptionally well. I am the TPM for four teams, therefore I can’t possibly remember everything all. I’m attempting to visualise managing and planning the workload for eight teams.
I would almost choose the opposite path after that. You’re going to have to start delegating (even) more and picking favourites if you’re having trouble keeping track of everything and your organisational system isn’t the issue.
I devote an excessive amount of my time on a small number of tasks that bring the most value. My developers oversee all scrum-related tasks. The exception is backlog prioritization because squirrels can’t focus on anything for more than a sprint without reminders and are hence the only exception. I then concentrate on the areas where I can provide the most value to the firm. Check out the rest.
Are all of your stakeholders at your company engineers? An anonymous survey regarding work habits, processes, cross-team collaboration, management efficacy, onboarding effectiveness, etc. is one thing you might start doing that would be useful and offer you something to monitor over time. They provide a starting point for improvement and are highly helpful / visible for management. It’s a touch self-indulgent, but that kind of behaviour can provide an internal PM some visibility and establish you as a dev-friendly PM as their integrated collective voice.
The additional benefit of an internal PM—even at a large company—is that you simply have much more insight into the motivations, demographics, abilities, etc. of your users because you are aware of the entire population of your potential users as opposed to a B2C or B2B product where you have a total addressable market, but you’ll never reach 100% of them.
Treat everyone like a customer. I view PdM as a servant leader. So I’m always looking for how I can help everyone.
Have you tried meeting 1:1 with the tech leads and understanding their needs so you can see how you can help them?
And showing them how helping you would help the product (and hopefully them)?
Until they talk to you face-to-face, you may “seem” like a bot to them, emotionally You’re just some rando Dm’ing them on Slack.
My Experience:
It took me a few months for folks to consistently answer my questions. I think it’s a combination of them:
realizing who you are and what you do
how you can help them or at least the product
establishing some rapport
E.g., one way you might help tech leads is by helping them push back and say no. They may see that they are getting requests that don’t seem helpful to the user. You can help with that.
In addition, I now oversee a product team after working as a developer. So, I might be better able to respond.
There are three main job duties: Design|Tech|Business. One of a product manager’s numerous duties is to fill in the gaps between these three. You switched from development to product, thus I’m assuming that the product might be very technical. When you claimed that your stakeholders are engineers, what did I miss? Is your product designed with developers in mind?
If that is the case, then translating technical points for business use cases or the corresponding translation for design may be an even bigger issue. The product demand doubles at this point. I’ve encountered this problem far too frequently; engineering would create features and capabilities, but sales would only have rudimentary knowledge of how to apply them to customer use cases, unless the product would chime in with the appropriate user flows, documentation of the use cases, and associated KPIs. Recognize that even if you are not developing, developers may already be dealing with the issue and may already have an idea of the product that is needed.
Just one follow-up is required. It can be annoying to receive the same message multiple times on the same day. Establishing a relationship with the tech leads is crucial.Product managers must LEAD WITHOUT AUTHORITY, which cannot be accomplished by merely requesting updates. This is crucial to comprehend and is of utmost importance to every product organisation.
Determine the value of the data, and then. For improved results calculation, for any features, and for additional improvements, data must constantly be tracked. Merely that the method of data collection could vary. You have amplitude/mixpanel for a B2C or B2B SaaS. To achieve the greatest outcomes, you might need to transform input into key data points (KPIs) that can be distributed throughout the organization especially developer-centric businesses like yours where direct data collecting is challenging. Ultimately, there is a reason why success is attributed to the product. To ensure a successful deployment, there must be no gaps between business, design, and technology.
Simply acquire the support of the leadership team before working with select technical leads to resolve the issues so they can ease the transition with their teams. As surveys are typically viewed with distrust on both sides, you don’t want the results to trigger a crisis when you’re just looking for some useful information. Our quarterly employee satisfaction survey frequently disrupts our entire workflow since only the irate employees fill it out, leading leadership to believe that a catastrophe is imminent while in reality just 5% of the workforce is upset.
That’s what I’m currently trying to do @BinaCampos. I’m trying to work with a leadership person right now who is not being very responsive. My work is stalling because of this and am thinking of raising this to my manager, who is above this person.
This is a great idea, I can do this through slack polls or in real time during collaboration meetings. Yes my stakeholders are internal engineers.
It is hard to win trust with Engineers so stay in there and don’t get frustrated
Connect with each one on a personal level. Help them help you. Since they are also your target user learn their processes. Figure out their problems since you said you are improving developer productivity
Talk to other teams as possible and share that data which may lead to them opening up to you
Tell the team that, in order to develop an ideal solution, we must find solutions to the restrictions—that is what issue solving is—when there are conflicts or constraints during execution.
I’m ok with 1 and 2 but not with 3, I can measure that with how quickly/slow changes are made, or measure how certain tools are slowing down developers. Would need more metrics to measure for dev effectiveness. I’m not very experienced working with data, I was developer before being a PM. I’m interested in taking a data course such as the go practice data simulator. What sort of data are you referring to? We don’t have a data team.
I wonder if information like “how many of our users experience this difficulty” would be a good place to start.
I’ve brought data-based judgements here, and even the most fundamental information, such as “how many of our consumers use the iPhone? or speak only Spanish?” has had a significant impact without the need for statistical research.
Example
An enthusiastic stakeholder requested a Spanish version of our product from us. According to their observations, there were more than 50% of users who spoke Spanish. They are the bilingual person who is referred to them by Spanish-speaking users, so sampling bias, I discovered when I looked into it. The percentage of people who spoke Spanish overall was about 20%. Significant, but still far less significant than that individual. (And a significant portion of those 20% were successful in using the English version with the help of a friend or a multilingual coworker.)
@ElvinHenriques, Yes, that’s a very good data question to ask and IMO; the most important to start with. If the customer quantum is low, then it makes no sense to solve that problem against another where the quantum is high.
You’re just some rando Dm’ing them on Slack.