Do Agile Project Managers fit into a product world?
As a practicing Agile Project Manager in a consulting firm I often wonder about the place that Agile PMs have in the world of product development where Product Managers are a key element in a startup businesses success.
I often browser hacker news and Indie Hackers and similar sites wondering about how the skills that Agile Project Managers have fit into this SAAS product development world?
I know from personal experience that the skill set that (Agile) Project Managers possess are quite broad, we deal with everything from team building, one on one personal staff management, financial management, meeting and event planning and management to tricky stakeholder management.
Yet so often I see the idea of project management or managers and especially 'agile' being maligned as a topic on Hacker news.
What's everyone's opinions on how Agile Project Managers (and agile in general) fit into the product development world?
There are many definitions here.
Product Manager = Why and What you're building.
Project Manager = How, When, and Who is building it. (Usually shared with an engineering manager or technical program manager role)
The reason why PMs are looked down upon in places like hacker news is because majority of people there have had very negative experiences with them. That's because most PMs don't realize what value they actually provide in a group. Those who do, will have engineers behind them rallying because they do so many things engineers don't have to worry about. You'll probably see people even say "I've worked with a good PM once and when they left, everything sucked".
You're missing another job. A "TPM" which is a technical program manager. They are very familiar to the "project manager" you're describing today and follow the "How, When, and Who" idea.
In the product development world, and especially as an indie hacker, having product manager skills is ideal. Being a TPM or project manager is less ideal unless you're joining a team where you can provide value through the collaboration of others.
The best of both worlds are "product engineers" who can do PM & engineering work.
In our consulting world (at least - the way we do it), is to set out three important roles:
The Project Manager, who has overall accountability for the project.
The Business Analyst, who digs into the detail, writes stories with acceptance criteria, engages with the client to discover what's required / needed and facilitates sprint planning / estimation and showcase sessions.
The Lead Developer or Solution Architect, who understands the technical side of what's to be or is being developed and can help steer the team (including any client representatives) away from bad / impossible / 'would take a long time' ideas.
While you can get people who do maybe two of those three roles well, we've stopped giving them both those roles (despite their skills) because it creates a conflict. We need the PM there to monitor scope and time and budget, we need the BA there to ensure the details is correct and very much be the voice of the customer and we need the lead developer to ensure the solution that's developed is a good one but also maintainable, secure, and of a high quality etc.
I wonder if in the product development world these roles are by necessity sometimes merged into a single or two people (as you sort-of indicate)? I wonder what interesting conflicts or outcomes that causes at times (it's not really a bad thing, just different and interesting nonetheless).
👋 Michael
My (irrelevant) opinion is:
🍻
This comment was deleted 4 years ago
That's a very interesting perspective.
In my experience, you have time, budget and scope, the client (or team) can pick two of those, but occasionally when things go really badly, they end up only picking one of them.
Project (or product development) constraints always exist, whether you acknowledge them or not. Maybe you only have one or two developers? That's a constraint right there, couple that with a limited budget and suddenly you'll find yourself prioritizing features and functionality (scope).
There's nothing contradictory about the term "Agile Project Manager". I've run many very successful development teams using an agile methodology. The client and our business analysts along with the senior developer or solution architect work together to prioritize the backlog, and everyone works within the constraints that exist.
Developers have the flexibility to choose stories they like, and they work standard hours during the week without being pushed to do overtime. Standups occur every day and that gives everyone a chance to communicate and help each other out.
The difference here though is that as an Agile PM, I set standards both with the team and with the client that ensure transparency, engagement, communications, and regular client involvement ensure a successful outcome for everyone involved.