Hi everyone!
I've been a PM for eight months and am fortunate to have a wonderful working relationship with the analysts and developers on my team. I've learned an incredible amount from them.
I've heard from other people, however, that some tension may exist between product managers and developers. Why is that the case?
I'd like to hear from you all: What has worked well? What could have been improved? I'm looking to understand this from the developer side of the equation and how both roles can be better partners to each other.
Share your thoughts in the comments!
Top comments (27)
Some of these explanations are oversimplified. HMU if you want to discuss in more detail.
Estimating dev work is hard
A PM might think that a new feature will take two weeks to complete. In reality, devs don't really know that answer up front. Often times, we need to actually start building the new feature in order to determine its complexity, whether or not it impacts other things, and how long it would actually take to complete.
Deadlines are important, but devs generally get frustrated if the PM doesn't understand the above workflow and its nuance.
Software development is part art
Some days, devs could be in a flow state and get a lot of things done. Other days, we're just not there mentally and need to unwind. PMs could get frustrated about this reality if their tendency is to micromanage.
Gaps in technical knowledge
Sometimes, the technical gap between dev and PM could be too wide to the point that devs get frustrated trying to constantly dumb down explanations so the PM could understand.
We are very opinionated
Sometimes, our egos get in the way. If a PM suggests something that would be an improvement in user experience, even if it's backed with data, we'll still have our own opinions about it.
Appreciate the response! I feel the estimating dev work problem acutely since our partners (Marketing) are always asking for timelines. :) Thanks Eddie.
A bit of context, I was a team lead for 15 months on my previous job so I had a lot of interface with my then product/project manager.
Usually programmers get more involved in the project and perform better when they know why they are working on said task/story/feature. A good PM always backs his/hers users stories with a solid, business oriented reason.
Communication is key, and that goes both ways. The best PM that I've worked with held pretty strong standards on deliverable quality, but was also a great listener when the team argued that something couldn't be done due to technical limitations, or when a requirement had to be changed/negotiated.
Generally speaking programmers hate when the project scope changes. If the change was big or really far down the project, they hate it even more. Shit happens, we all know that, but a good PM always does his/hers homework on project risks and keep the team aware of the risks before they turn into real problems.
A good PM trusts... Once that trust has been earned. Your team has a great record of shipping fast and with great quality? Good, lay down the requirements, stories and acceptance criteria and let the team do the job. On the other hand, if their performance is spotty you may want to pay attention to that and act if that compromises the project delivery in any way.
The best PM that I've worked with was extremely organised and always kept the team aware of current project status and clear next steps. We may not always agreed, as expected, but always respected each others opinions and decisions.
I'd also add that a BAD PO relationship could involve PO telling you WHAT to do instead of the desired outcome. We had a scenario where we were being asked to store a piece of data that has nothing to do with our other data, and isn't created by our applications. The addition of that data would create an EXTREMELY large feedback loop that would most likely create more issues than it solved. The team that generated that information and whose information was actually relevant to it ALSO had a means to be queried, and doing so on THEIR part would close all of that funky feedback loop nonsense. Business team had no clue that their 'requirement' was problematic, but they still attempted to have the dev team do that work.
A GOOD PO would have brought the desired outcome to the team/lead and asked if there was a good way to make this happen on our side.
What a thorough and thoughtful response, Vitor. This is exactly the level of detail I was hoping for. Thank you!
Glad I could help 😄
What has worked well?
I'm a software engineer. We use a Scrum-like process, except we don't have Scrum Masters and the PMs take on parts of the role of Product Owner.
The PMs prioritization of the work has worked really well.
What could have been improved?
Our code base has had some neglected necessary maintenance. Which means we have a lot of technical debt. Which means feature development takes a lot longer. Yet we never have time to take care of the technical debt. The PMs equate technical debt with bugs, but those are separate from one another. Bugs are user-facing; technical debt is developer-facing.
Also, I think it would be interesting to try to do by the book Scrum. Just for a year. To see what it is like. But I don't think that will happen where I work.
Last but not least, we use Jira. I am not a fan of Jira. It's slow, cumbersome, awkward, and models the workflow poorly. But I do not know of any tool that is better than Jira.
I've thought the exact same thing, Eljay! We unfortunately have a traditional waterfall process and while we've adopted "Agile-like" and "Scrum-like" elements into our workflow, it's not a replacement for the real thing. The longer I'm in my role the more evident it has become that Scrum might help us become more innovative and get things out quicker. But that's just my assessment. :) Thanks for sharing!
If you do get a chance to do by the book Scrum, there is a short series of blog posts by Kelly Waters called How to Implement Scrum in 10 Easy Steps.
The website lists them in reverse chronological order, and I suspect their internal links are broken when the blog posts were archived.
Nice. I have my Professional Scrum Master certification and have a foundational understanding of the framework. But I am keen on understanding how it looks like when applied (especially in large companies that have always been waterfall).
Just wondering if you're an engineer yourself. I've found that a scrum master with no (software) engineering experience is woefully inefficient in organising work as they can't understand how some stories fit into the dev stream. It often consumes a lot of dev time in assisting the SM to organise this. Any insight into how a scrum master works well would be really appreciated 😁
Truth be told, or part time scrum master doesn't really know scrum, so that didn't help
I’m not an engineer myself but my situation is different; I actually sit on the engineering team, and I know the engineer’s work stream because our team processes were built around it. In practice my role is a blend of product management and technical program management. In fact, what prompted me to ask this question was less about my own experience than it was about understanding how this has worked for other people. I have an excellent working relationship with my developer colleagues; we all complement each other and our skill sets very well.
And based on your description, it sounds like your SM was actually a Project Manager? Scrum emphatically differentiates between an SM and a PM, with those on the development team responsible for organizing their own work. But I know in practice this is not always the case.
Agree wholeheartedly on Jira. It's powerful, but there's a lot you usually don't need. It's so much easier to link Trello, Git[whatever] issues, and a user feedback form that creates cards in Trello, and you can even categorize based on bug/feature request/whatever. IFFFT helps for a lot of integrations too. Or just use Trello internally and nothing else. Or just Git[Hub/Lab] issues/projects.
As for "by the book" anything, I disagree. I often tell people, "Project management methodologies are just sets of tools. Use the ones that make your life easier, and ignore the ones that don't make sense. If you follow any PM methodology like religious dogma, then you've missed the point entirely."
Oh, and there's really no reason to have a standup meeting anymore in 2020. Set up a DailyBot or similar where everyone submits their worked on/working on/blockers by a certain time in the morning, and you get an actionable dashboard of all of them in one place, no 15-minute meeting required.
PM: "How long will this take?"
Me: "I will look at the specs and get back to you."
Me (later): "It will take X amount of time."
PM: "Oh, that's too long. Can we reduce the amount of time somehow?"
Me: "If the client cannot have any slip in due date, that's the amount of time it will take. It might be less."
PM: "I'll tell the client 'less'"
I really don't know how to fix this dynamic, other than to be honest with the client. Tell them the maximum amount of time it will take, and when it takes less time then charge less. This will exceed expectations.
Haha I've come across this a few times.. it's about communicating WHY it will take that long. Explaining that certain frontend changes are actually quite complex because they involve rearranging many different elements for example.
Also, disconnecting from the PM helps. Be firm in how long it takes. If you've quoted 50 hours for a job, but the PM sells it to the client at 25 hours, stand your ground and make it clear it will take you 50 hours. You literally cannot do the job quicker. It then becomes the PM's problem for underselling the job.
I agree with this completely Natalie. I personally tend to be very conservative with estimates and how I even share that out with the client (stakeholder); I'm also a PM on an engineering team so that could explain the dynamic (I know how long things take and why). I have to have several conversations with stakeholders to explain the feasibility of building something as asked and it's been a journey and it's ongoing. It's encouraging to hear, at least, that I'm not alone in this!
I think others have touched upon it here, but communication is the most important thing. The good PMs I've worked with have been able to communicate the project outcomes, the timeline, and specs very clearly. Beyond this they stick to their specs unless a very good reason comes up. I really appreciate this as a dev. One of the things I hate is redoing things unnecessarily. This happens if the PM hasn't been clear enough on the specs and they come up with things midway through the project (aka scope creep).
Another great aspect of a PM is being able to work cross functionally. The ones I've seen have been able to get resources to their devs if needed. Or have been able to unblock devs by connecting them with other teams. For them to be able to do this they need to have a pulse on the team. I don't mean micromanage, but they should know what's going on with work progress and any potential blockers. I've had a few PMs who have just stayed high level trying to develop business goals and continually working on specs. While this is great for planning, this forces me as a dev to step up and start prioritizing work. Which is not going to end well, especially since I don't always know the business priorities.
Finally, a great PM trusts their team and lets them work without pushing them to a deadline. I absolutely hate it when a PM tries to get me to commit to a hard date. A great PM will take information from the team to figure out a deadline to set. And be able to push back against business if someone from above is pushing a deadline on them.
Great question Stephanie, I hope all these answers help!
Bad PM
A good PM
Well, I had experiences with three projects and I had the same feelings about them. First of all, I like being a developer because I use to see it as a creative job. Then, more than liking to just code, I really like to build the software in its concepts and having some opinion about it and this has been the source of tension between me and the PO´s.
In the first project I just thought to myself that I would never use the app that was being proposed. I communicated it but the PO but he insisted that it was what the client wanted. When it happens it affects my engagement in the project, since I don´t believe in what I am building and there is no much space to make suggestions. I think one of the most interesting things in software development is when you see the software as your product, almost your "baby". In that case the PO took away the creative part of the job. In this particular project, after some sprints it became clear that the proposal was not really good and then they had to change the scope to something that was very close to what I wanted to suggest before. So, for me as a developer it was like a waste of work and re-working.
I found this pattern in the other projects too. Sometimes it is kind of obvious that the idea and requirements are not really good, but they expect that you as a developer just to do it. Then, in the future they ask to change or re-do things as it was the normal flow. But I think this argument is exaggerated. In my particular case they always justify with some ready-made phrase about agile but it was more a lack of understanding and since the developers are the ones who really have to do the work again they don´t care much about it.
In resume, they treated us as mere executors as we would not get bored or frustrated just coding whatever they asked with no regards to the idea of the system itself.
In some cases I felt like the PO was just a bad intermediary.
It was like if someone get sick (the client) and goes for a doctor (to find the solution, the software), but instead of talking to the doctor who knows how to identify and solve the problem, the patient had to talk to an intermediary, and then, this intermediary repasses the info to the doctor and then repasses it back to the client and so on. If we really think about this example, many confusions are going to happen and could be solved if there was no intermediary. This is an extreme example, but I think it can relates sometimes.
I believe it's all related to the top most managers and how work is rolled into action. As the customer's and time-to-market demands get higher, the backend engineers are doomed to failure; except for one thing. They must focus on reusable components and the product manager can help to run interference on that because it's really the number 1 way to get to production faster. Does your department have a component library?
One of the most important things is:
Make crystal clear feature requirements.
Thanks Terry! I know this varies by team/product but what are some must haves that every feature req should include? What makes a good feature req and how does it differ from a terrible one?
This is a bit contrived, but it happened in real world as well.
Bad: Use a nice indigo color on this button.
Good: Use #5A67D8 as background color for the button, and #7F9CF5 when mouse over.
I've had PMs that act like technical literacy is beneath them but then get upset when things don't go how they plan and basically shut down the conversation if anything as technical as API is mentioned. That's a bit of an extreme case but I think understanding roles and responsibilities is important. Each should understand the others job enough to empathize, and evangelize for the other. But i think it's also important to know where the lanes are. My PM can tell his thoughts and opinions on pubsub vs Kaftka if he has them but at the end of the day it's my job as the lead (with my dev team) to choose the architecture. Likewise I can explain and reason prioritization of 2 features but at the end of the day that's the PMs domain and they get the final say. Without that empathy and understanding though my PM can't understand the value of tech debt tickets, and i wouldn't understand why my PM is pressuring us to creep scope.
100% this; thanks for sharing!
As someone who's doing a bit of dev, and project management, the comments are all super insightful!
A PM should
Not micromanage them,
Trust them with the task
Don't give unexpected deadlines
Listen to them