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!
Latest comments (27)
A PM should
Not micromanage them,
Trust them with the task
Don't give unexpected deadlines
Listen to them
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?
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.
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.
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.
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.
Bad PM
A good PM
As someone who's doing a bit of dev, and project management, the comments are all super insightful!
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.
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!
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!