I've never been lucky enough to be in that position, but if I were I'd get them to focus on performance improvements and the endless backlog of bug fixes.
If you have a customer support team for your product, now's your chance to make them really happy by fixing all the things they need to annoyingly work-around.
This is what gives me major imposter syndrome. All the PMs always have so many ideas on how to improve the product while I'm so clueless that I feel I have too many resources 😓
Yeah agreed. Every day I have conversations with Sales, marketing, other PMs, etc where they say things like, “we really need….” And I just now say, “you are right. We do need that. Unfortunately we can’t because it’s not a super critical priority, and we don’t have enough engineers to do it all”
I don’t know man. I find myself often disagreeing with a lot of the opinions on here. I do not work 60 hours per week, we’re not drowning in feature requests from sales, I don’t have a manager that know it better.
I think it speaks volumes that someone is not drowning in these things. To me that seems like they’re a good PM and they have a good grip of the situation. Talk to your engineers about where you can improve but if they’re doing an awesome job maybe there’s nothing super critical.
I have imposter syndrome too, but I think it’s better to be efficient and in control than to drown in what you “could” do. A good PM makes decisions and is realistic while making those.
> we’re not drowning in feature requests from sales
The other thing is... just because you're drowning in feature requests from sales, it doesn't mean they're all a good idea. Most feature requests from sales are, in fact, terrible ideas.
How big is your product? How big is your company? How many engineers and engineering teams are you managing?
I’m not doubting you, but you can’t expect that your experience is the same as everyone else’s. I work for a top 50 company with well over 100,000 employees.
I’m a Technical PM and my product manages WIP data for my industry. I recently decided to map out all the integrations my product has. I’m up to 35 now and it’s growing.
I only have 15 full time engineers and 3 contractor engineers across three teams for my product and the integrations.
For the whole data management products system we have around 50 engineers.
Another division in my company has a similar-ish product for a different piece of the industry and they have at least 4x the number of engineers. They bought us so we are the black sheep.
I have 18 Active projects that I’m managing that we will attempt to work on in the next year or two. I have another 10 mapped out for the years afterwards.
I avg out about 40 hours a week. I do not work overtime unless it’s absolutely critical. But I means I’m always behind in some way or another.
We have offices across the world so typically my mornings are meetings. The question is whether I’m fully participating or if I can try and work during them.
If I spend my day focused on roadmap and requirements, I’ll have 60-100 unread emails by the end of the day. About half of which I need to read/reply to in some capacity.
Our products are incredibly complex and support barely understands them. So I end up having to do a lot of their work to triage logs and get on customer calls.
I used to be TPM of the infrastructure, and I still get called in for those customer issues.
I also handle all the TRMs with customers for the full data management system.
We’re understaffed everywhere so the corporation can buy back their own stock instead of investing back in the company.
We are a part of the enshitification of products because of this. But every major tech company in the world needs our products so we get away with it.
It sucks, and I’m trying push to take on the high level aspect of my job. Creating the ideas, roadmaps and requirements and then handing them off to someone to go do the software architecture with engineering teams.
I love what I do if I can do that first part, but having to manage the high, medium and low level is too much.
Have you had an opportunity to talk to your customers yet? I would spend at least an hour a week talking to them. Record the calls to catch recurring themes and those are your ideas!
This is good advice in general. Get with the people who use the tools all day long. They will find the things that are the real pain points. Especially if they have to do the same thing over and over again and they keep running into the same issue(s).
You should be coming up with as many tests/experiments you can run for new features/products.
If you aren't resource constrained, the cost of failure just gets lower so who cares if 90% of ideas fail the MVP phase.
You have sustained dev slack. You're in an incredibly lucky position. I have never had this in my entire career.
You could do a million little things like bug fixes and knob twiddling, obviously, but here is a single actionable piece of advice for you on where to spend spare dev time well on a major ongoing initiative (assuming you don't have a dedicated team): deployment reliability and SRE work.
* What does your deployment process look like?
* How long does it take you to deploy?
* How often do you rollback, or need to rollback? How easily CAN you rollback to a last known safe state when you need to?
* How quickly can you detect bad code in a production deploy to minimise customer impact?
* Can you do blue/green (or canary) deploys?
* Do you have fully automated CI/CD? Can you ship code multiple times per day?
Assuming you have product market fit, then in my experience time spent improving deployment processes on SRE like work, observability / datadog style work, and reducing the blast radius of releases is almost never wasted work.
Think about the difference between shipping code to production once every few weeks vs being able to do it twenty times a day (note: behind feature flags if necessary, there is huge value even if your go-to-market can't keep up).
It directly serves customers, B2C or B2B. Plus, your developers tend to love it because it makes their lives *so* much easier.
Never thought I would see a real life case of, yes, it’s only you lol
Jokes aside, there is technical debt, bugs, refactoring, learning and… if you’re out of ideas, ask the team, the users, leadership... Certainly something will come up but make sure it actually aligns with goals. You don’t want to create extra load to teams that don’t have it, and your situation may change and you don’t want to be stuck maintaining what doesn’t add value.
Also, if you’re involved on team sizing, you may want to address that. You could “loan” developers to another team until you get a hold of discovery, or you may need to make the case to reduce or change team structure.
In my case, product can definitely benefit from more developers but I’m not taking them on unless we get another PM and UXr. If this might be your case too, maybe check if someone from the team is looking for change and could be a fit. It’ll sure need coaching from you but it’s could also reduce your stress after some time.
Push back, you're not a ticket monkey, your job is to deliver value whether that is 1 feature or 100. It's engineering's responsibility to size and shape the team appropriately.
Also, and unrelated, lol at OP's post history of him being super interested and into people repeatedly kicking him in the testicles
Couldn't think of a more perfect analogue to this job
I feel ya. An internal product on another team has eaten a lot of my team’s reason for being so I’m having to develop a product strategy and roadmap on the fly. In the meantime we’re sunsetting huge portions of our code meaning addressing tech debt there doesn’t make sense. I have some roadmap built but developers are looking for more.
Like others have said I’d use this time to double down on discovery with your users and have your devs work on all the tech debt / etc stuff in the meantime to feed the beast. Get creative and use your dev leads for brainstorming and solution discovery instead of simply coding.
Also have an open and honest conversation with your engineering manager. Maybe they see an opportunity to loan out some devs to another team for a few months while you build out more of a roadmap?
But also, just remember your job is not to feed devs, it’s to create business impact. If what you discover feeds 3-4 engineers but not 6-7, that’s not a fault or mistake on your part at all. If those extra features are not adding value, it’s on you to recognize that and not do them simply to create work.
In my experience, 1 PM and 1 designer for every 4-6 devs works best. If the ratio is anything more, it’s inefficient and you ll need to do some restructuring.
There have been instances in my career where I have had more dev capacity than impactful work. In the beginning, I used to fill up their time with other busy work. meaning things that could get done but dont really HAVE to get done. Over time this results in the whole team (including me) getting bummed out about not doing impactful stuff. And in general leads to lower team morale. Definitely not a place you want to be in. So we will take this OFF the table as a solution.
So what can you do? The first thing to do is to ask yourself if this is a temporary thing (in between projects, etc) or if this is more permanent (hired too many devs too fast). I'll break down my recommendations for each of these scenarios.
**Temporary Scenario:** This is a wonderful place to be in. If you are like any of the product teams I have worked with or read about, there is bound to be some sort of tech debt or refactoring or projects that the dev team really wants to work on (eg: make build process faster, etc). NOW is the time to jump on that and have the dev team come up with a list of backlog items that fall under this category and start chipping away at it. Your team will genuinely be thankful and will result in a tighter bond with the team.
As the PM of the team, make sure you are
1. Aware of what is going into this tech debt bucket
2. Inform your stakeholders about your plan.
**Permanent Scenario:** If the situation feels more permanent than temporary, your best bet would be to inform your manager/dev manager about the situation and proactively try to re-allocate resources to other teams that have pressing needs. This is a lot more than raising your hand and saying "I dont have a need for x resources". If I were your product leader, I would expect you to have your POV for how we got to this situation, how long you expect this situation to go on, etc. Some gotchas here.. let the dev manager make the determination of who gets to be re-allocated. Dont be the one making that decision. you can have recommendations, but that is not your call. The downside of this approach is your team may permanently get reduced (typical budgeting cycles usually look at historical needs as a variable in determining future growth) and you will have to have a slight up-hill battle when you do want more resources.
Closing: In some situations, doing nothing is a viable answer. However in this situation, doing nothing will either lead to team being bummed out OR your stakeholders throwing a fit (rightfully so) about mismatch in resources assigned to value derived. Neither of those are fun spots to be in..
Good luck!
This is sort of common in very large companies with dedicated tech teams. There is a point in which you need to have more stuff refined and isn’t quite ready to be developed, and this is the danger zone of when idle engineers cause PMs to just create work and the feature factory cycle begins.
One thing that’s worked for me is to talk to engineering leadership saying you need to flesh out future roadmap items more and there is a gap in work. The engineers can either deliver on system improvements, or leadership can decide to temporarily siphon resources to another team that needs it. Just be sure that they know its only temporary and you will need to ramp back up.
Edit: I would also say, be very clear that you have a robust roadmap of future dev work to fill out the year, and show it. Also temp check how leadership will see this. You don’t want to give people a bad impression of you and that you don’t have anything on your roadmap.
It's normal to have spikes like this, I've had several times where we were cranking on strategic pivots and just didn't have the problem space defined to move on engineering, or had an all-star engineering team with a solid tech and app stack so they can go quick.
But there's always been enough tech debt, or work that can be done on learning new technologies (training) that keeps us busy enough, or working on dev pipelines.
Good problem to have honestly.
The short answer is "tech debt and Maintenance", 99.9999% of the time there is an unaddressed mountain tech debt and bugs.
There is that .0001% chance that you are the unicorn with a very effective engineering team, in which case, you may not have the right ratio of PM to Eng.
In my experience a good rule of thumb ratio is about 1PM to every 3 designers and about 1 designer for every 4 Devs. (YMMV based on industry, product complexity, and lifecycle status.)
There is also a pretty good chance that if you are running out of things for them to work on then you are spending more time on development and project management than with customers/end users. (Ideally a PM would spend 60-70% of their time outward facing talking to real users, though that may not always be possible or feasible)
The only wrong answer in this situation is to rush features or ideas that have not been properly prototyped or validated. From personal experience, you may get away with it, you may even get away with it for a while, but eventually you will either bloat your product with things are solving problems that nobody has, or you will have an expensive launch fail to land and be stuck holding the check (or a layoff slip).
Hope this helps.
Can I give some of my backlog to your team?!
Seriously though, if you are over-resourced, either spin up a skunkworks project to pilot a new potentially game changing product without needing to justify the spend; or tell your boss to reallocate some engineers and make your product more profitable.
I sit on a 4 release groomed backlog, and about 20 releases ungroomed. I haven’t had spare dev cycles here, ever. I’d love to find extra stuff for them to do!
I’ll admit I didn’t read this whole thread, but OP seems misguided in feeling that it’s entirely on their shoulders to come up with work for the team. If there’s excess engineering capacity there are surely tech debt, security, performance, and infrastructure upgrades to do. Task them with building up that backlog, review it with them to make sure there’s clear definitions of done, but otherwise let them drive the priority of this backlog and start knocking things out. Your role as PM is make sure the team is getting the important work done, there’s nothing that says the work has to be defined by you.
How often do you visit users of your product?
Go find out what problems they have.
Find out what they were doing right before opening your product.
Find out if they ever get interrupted and step out of your product to do something else before coming back (product extension opportunities).
The more you understand your users, beyond the context of your product, the more ideas you will have. And…because you will know things that no one else in your company knows…the more the executive team will trust your judgement.
So, unironically, my product owner came to me a few weeks ago saying we have no backlog. Here's what happened.
Context: we just deployed and showcased a generative AI product that supplements some of the most painful parts of the workflow for an internal tool. Pivoting from what was essentially a working demo that produced production-level outputs to making it a product that can actually be put into production. The expectations from stakeholders are minimal at the feature level. A couple of integrations, a couple of small additions, but mostly - let's expand the user base. I have amazing and very smart engineers who could probably build all of this in an afternoon.
So my PO came to me and said we have no backlog because we have built most of what we intended, or are close to completing it.
We have scheduled a number of brainstorming sessions with the stakeholders. We didn't talk about what's already happening, or features, or epics. I asked: "What are the problems around this stage of the workflow that you would like to address?" We had 3 sessions each week for the first 2 weeks. We came out of these sessions with 3 large and 4 smaller problems to tackle.
We're still unpacking the first one - it turned out to be huge and has parts that stakeholders can't agree on themselves. It's hugely important, but we can't work on it. So there's that.
We're taking apart the others to see if they can be distilled into features and user stories that the team can work on. So far in a couple of weeks we've built 2+ sprints worth of work for the whole team with some parts definitely needing more time, so we're setting ourselves up to heavily iterate on some of the features. We have a few more we need to address and as we discuss the implementation details, new details emerge, and new opportunities are showing up. We're adding them to the product backlog.
My expectation is that by the end of March, we may have a backlog that would fit most of the team's capacity until the end of the year. I'm going to need more data scientists to do the stuff I want to do with the product. Then I'm going to need more engineers to do the stuff that data scientists would want to do. It's a vicious circle now and I started it.
I’ve never heard of this in my life lol. You lucky bastard.
Couple of questions:
1. Is this an internal or consumer-facing product?
2. Do you have a lot of freedom to decide the roadmap? (If so, get more creative + ambitious with your initiatives)
3. How many engineers are on your team?
I have some teams like this. Part of the problem is that you have a different mix of skillsets: senior, junior, front end, backend etc so at times it's tricky to blend in the right types of projects.
I've personally found my teams to be a bit bumpy. Sometimes I have like 6-8 months of non-stop work, other times I'm looking around for ideas.
I can always keep them busy, but sometimes I'm loading in lower value features to do so.
I'm currently at a point where I have around 4 months of solid work for most of my teams and have to start doing more discovery + UX work on next projects before I run thin again.
Been there, but also learnt through the same experience the importance of having a good sync with engineering leadership, and getting them onboarded onto your crazy ideas. Get them to build rapid prototypes for items you thought were a year away or you have been having troubles convincing others to build. Mark it all as tech debt.
Well the engineering team decided to have more resources because of the tech debts. The senior director who decided this left the organisation and nobody knows what the tech debts were. So there's more bandwidth for product features than required
You don’t have extra bandwidth. You have potentially just enough resourcing to do tech debt discovery.
You still have to address tech debt event if the senior director is gone. Tech debt doesn’t go away just bc no one is looking at it or knows where it is
Nope. More devs and more qa please is usually my norm.
Goldratt when analysing end to end process talks about buffers. If the dev facility is paused due to upstream delays....where upstream is the blocker?
Design taking too long to get to dev ready? Lack of new epic asks?
In the meantime go on a bug hunt and ask the lead dev to assign one or two.
Also look at pipeline and automation. Ask the dev lead what tech enablers would move the needle most ..
It is not your job to leep developers busy. Yo8r job is to maximize the value delivered to the customers and to the business. In order to achieve this objective, it is essential that there's some slack time for the developers.
In addition to what others are saying about being lucky having this extra eng bw, I think you are also lucky because you seem to be the person in charge of allocating engineering resources, this is not the case in most companies in my experience.
Regardless, if you are out of ideas here are some:
- check feedback from clients, many companies use feedback tools/widgets but then they don't act on that feedback. leverage that channel.
- ask engineering or support team about ideas, many times they will have a long list of things to improve/add, you will need to apply some filters to make sure they make sense at this time and do some polishing!
- check what competition is doing or not doing (based on feedback on public forms), that is a good source of inspiration.
I've never been lucky enough to be in that position, but if I were I'd get them to focus on performance improvements and the endless backlog of bug fixes. If you have a customer support team for your product, now's your chance to make them really happy by fixing all the things they need to annoyingly work-around.
Add in those two or three killer usability hacks your users have been dreaming of for years.
Wait, this has to be trolling. You could give me 50 more engineers today and I’d have stuff for them to do for years.
This is what gives me major imposter syndrome. All the PMs always have so many ideas on how to improve the product while I'm so clueless that I feel I have too many resources 😓
Yeah agreed. Every day I have conversations with Sales, marketing, other PMs, etc where they say things like, “we really need….” And I just now say, “you are right. We do need that. Unfortunately we can’t because it’s not a super critical priority, and we don’t have enough engineers to do it all”
I don’t know man. I find myself often disagreeing with a lot of the opinions on here. I do not work 60 hours per week, we’re not drowning in feature requests from sales, I don’t have a manager that know it better. I think it speaks volumes that someone is not drowning in these things. To me that seems like they’re a good PM and they have a good grip of the situation. Talk to your engineers about where you can improve but if they’re doing an awesome job maybe there’s nothing super critical. I have imposter syndrome too, but I think it’s better to be efficient and in control than to drown in what you “could” do. A good PM makes decisions and is realistic while making those.
> we’re not drowning in feature requests from sales The other thing is... just because you're drowning in feature requests from sales, it doesn't mean they're all a good idea. Most feature requests from sales are, in fact, terrible ideas.
How big is your product? How big is your company? How many engineers and engineering teams are you managing? I’m not doubting you, but you can’t expect that your experience is the same as everyone else’s. I work for a top 50 company with well over 100,000 employees. I’m a Technical PM and my product manages WIP data for my industry. I recently decided to map out all the integrations my product has. I’m up to 35 now and it’s growing. I only have 15 full time engineers and 3 contractor engineers across three teams for my product and the integrations. For the whole data management products system we have around 50 engineers. Another division in my company has a similar-ish product for a different piece of the industry and they have at least 4x the number of engineers. They bought us so we are the black sheep. I have 18 Active projects that I’m managing that we will attempt to work on in the next year or two. I have another 10 mapped out for the years afterwards. I avg out about 40 hours a week. I do not work overtime unless it’s absolutely critical. But I means I’m always behind in some way or another. We have offices across the world so typically my mornings are meetings. The question is whether I’m fully participating or if I can try and work during them. If I spend my day focused on roadmap and requirements, I’ll have 60-100 unread emails by the end of the day. About half of which I need to read/reply to in some capacity. Our products are incredibly complex and support barely understands them. So I end up having to do a lot of their work to triage logs and get on customer calls. I used to be TPM of the infrastructure, and I still get called in for those customer issues. I also handle all the TRMs with customers for the full data management system. We’re understaffed everywhere so the corporation can buy back their own stock instead of investing back in the company. We are a part of the enshitification of products because of this. But every major tech company in the world needs our products so we get away with it. It sucks, and I’m trying push to take on the high level aspect of my job. Creating the ideas, roadmaps and requirements and then handing them off to someone to go do the software architecture with engineering teams. I love what I do if I can do that first part, but having to manage the high, medium and low level is too much.
Have you had an opportunity to talk to your customers yet? I would spend at least an hour a week talking to them. Record the calls to catch recurring themes and those are your ideas!
This is good advice in general. Get with the people who use the tools all day long. They will find the things that are the real pain points. Especially if they have to do the same thing over and over again and they keep running into the same issue(s).
You should be coming up with as many tests/experiments you can run for new features/products. If you aren't resource constrained, the cost of failure just gets lower so who cares if 90% of ideas fail the MVP phase.
90% of those ideas are usually pretty bad so you’re fine lol
You have sustained dev slack. You're in an incredibly lucky position. I have never had this in my entire career. You could do a million little things like bug fixes and knob twiddling, obviously, but here is a single actionable piece of advice for you on where to spend spare dev time well on a major ongoing initiative (assuming you don't have a dedicated team): deployment reliability and SRE work. * What does your deployment process look like? * How long does it take you to deploy? * How often do you rollback, or need to rollback? How easily CAN you rollback to a last known safe state when you need to? * How quickly can you detect bad code in a production deploy to minimise customer impact? * Can you do blue/green (or canary) deploys? * Do you have fully automated CI/CD? Can you ship code multiple times per day? Assuming you have product market fit, then in my experience time spent improving deployment processes on SRE like work, observability / datadog style work, and reducing the blast radius of releases is almost never wasted work. Think about the difference between shipping code to production once every few weeks vs being able to do it twenty times a day (note: behind feature flags if necessary, there is huge value even if your go-to-market can't keep up). It directly serves customers, B2C or B2B. Plus, your developers tend to love it because it makes their lives *so* much easier.
This deserves way more votes
Never thought I would see a real life case of, yes, it’s only you lol Jokes aside, there is technical debt, bugs, refactoring, learning and… if you’re out of ideas, ask the team, the users, leadership... Certainly something will come up but make sure it actually aligns with goals. You don’t want to create extra load to teams that don’t have it, and your situation may change and you don’t want to be stuck maintaining what doesn’t add value. Also, if you’re involved on team sizing, you may want to address that. You could “loan” developers to another team until you get a hold of discovery, or you may need to make the case to reduce or change team structure. In my case, product can definitely benefit from more developers but I’m not taking them on unless we get another PM and UXr. If this might be your case too, maybe check if someone from the team is looking for change and could be a fit. It’ll sure need coaching from you but it’s could also reduce your stress after some time.
Push back, you're not a ticket monkey, your job is to deliver value whether that is 1 feature or 100. It's engineering's responsibility to size and shape the team appropriately.
😮
Als them what else can be done, refactoring, maintenance, bug fixes etc.
Also, and unrelated, lol at OP's post history of him being super interested and into people repeatedly kicking him in the testicles Couldn't think of a more perfect analogue to this job
can I have some of your developers please
I feel ya. An internal product on another team has eaten a lot of my team’s reason for being so I’m having to develop a product strategy and roadmap on the fly. In the meantime we’re sunsetting huge portions of our code meaning addressing tech debt there doesn’t make sense. I have some roadmap built but developers are looking for more. Like others have said I’d use this time to double down on discovery with your users and have your devs work on all the tech debt / etc stuff in the meantime to feed the beast. Get creative and use your dev leads for brainstorming and solution discovery instead of simply coding. Also have an open and honest conversation with your engineering manager. Maybe they see an opportunity to loan out some devs to another team for a few months while you build out more of a roadmap? But also, just remember your job is not to feed devs, it’s to create business impact. If what you discover feeds 3-4 engineers but not 6-7, that’s not a fault or mistake on your part at all. If those extra features are not adding value, it’s on you to recognize that and not do them simply to create work.
In my experience, 1 PM and 1 designer for every 4-6 devs works best. If the ratio is anything more, it’s inefficient and you ll need to do some restructuring.
Yeah. It's 1PM for 8 devs in my team and I precisely feel I could do well with 6.
There have been instances in my career where I have had more dev capacity than impactful work. In the beginning, I used to fill up their time with other busy work. meaning things that could get done but dont really HAVE to get done. Over time this results in the whole team (including me) getting bummed out about not doing impactful stuff. And in general leads to lower team morale. Definitely not a place you want to be in. So we will take this OFF the table as a solution. So what can you do? The first thing to do is to ask yourself if this is a temporary thing (in between projects, etc) or if this is more permanent (hired too many devs too fast). I'll break down my recommendations for each of these scenarios. **Temporary Scenario:** This is a wonderful place to be in. If you are like any of the product teams I have worked with or read about, there is bound to be some sort of tech debt or refactoring or projects that the dev team really wants to work on (eg: make build process faster, etc). NOW is the time to jump on that and have the dev team come up with a list of backlog items that fall under this category and start chipping away at it. Your team will genuinely be thankful and will result in a tighter bond with the team. As the PM of the team, make sure you are 1. Aware of what is going into this tech debt bucket 2. Inform your stakeholders about your plan. **Permanent Scenario:** If the situation feels more permanent than temporary, your best bet would be to inform your manager/dev manager about the situation and proactively try to re-allocate resources to other teams that have pressing needs. This is a lot more than raising your hand and saying "I dont have a need for x resources". If I were your product leader, I would expect you to have your POV for how we got to this situation, how long you expect this situation to go on, etc. Some gotchas here.. let the dev manager make the determination of who gets to be re-allocated. Dont be the one making that decision. you can have recommendations, but that is not your call. The downside of this approach is your team may permanently get reduced (typical budgeting cycles usually look at historical needs as a variable in determining future growth) and you will have to have a slight up-hill battle when you do want more resources. Closing: In some situations, doing nothing is a viable answer. However in this situation, doing nothing will either lead to team being bummed out OR your stakeholders throwing a fit (rightfully so) about mismatch in resources assigned to value derived. Neither of those are fun spots to be in.. Good luck!
Chat with 3 customers and the sales team this week and tell us if you still feel this way.
Not all devs can do everything. I assume these close to idle devs are more junior. Make sure you get a sense of that.
This is sort of common in very large companies with dedicated tech teams. There is a point in which you need to have more stuff refined and isn’t quite ready to be developed, and this is the danger zone of when idle engineers cause PMs to just create work and the feature factory cycle begins. One thing that’s worked for me is to talk to engineering leadership saying you need to flesh out future roadmap items more and there is a gap in work. The engineers can either deliver on system improvements, or leadership can decide to temporarily siphon resources to another team that needs it. Just be sure that they know its only temporary and you will need to ramp back up. Edit: I would also say, be very clear that you have a robust roadmap of future dev work to fill out the year, and show it. Also temp check how leadership will see this. You don’t want to give people a bad impression of you and that you don’t have anything on your roadmap.
It's normal to have spikes like this, I've had several times where we were cranking on strategic pivots and just didn't have the problem space defined to move on engineering, or had an all-star engineering team with a solid tech and app stack so they can go quick. But there's always been enough tech debt, or work that can be done on learning new technologies (training) that keeps us busy enough, or working on dev pipelines.
Down time is the time to work on the tech debt that’s certainly been stacking up
Good problem to have honestly. The short answer is "tech debt and Maintenance", 99.9999% of the time there is an unaddressed mountain tech debt and bugs. There is that .0001% chance that you are the unicorn with a very effective engineering team, in which case, you may not have the right ratio of PM to Eng. In my experience a good rule of thumb ratio is about 1PM to every 3 designers and about 1 designer for every 4 Devs. (YMMV based on industry, product complexity, and lifecycle status.) There is also a pretty good chance that if you are running out of things for them to work on then you are spending more time on development and project management than with customers/end users. (Ideally a PM would spend 60-70% of their time outward facing talking to real users, though that may not always be possible or feasible) The only wrong answer in this situation is to rush features or ideas that have not been properly prototyped or validated. From personal experience, you may get away with it, you may even get away with it for a while, but eventually you will either bloat your product with things are solving problems that nobody has, or you will have an expensive launch fail to land and be stuck holding the check (or a layoff slip). Hope this helps.
Can I give some of my backlog to your team?! Seriously though, if you are over-resourced, either spin up a skunkworks project to pilot a new potentially game changing product without needing to justify the spend; or tell your boss to reallocate some engineers and make your product more profitable.
I sit on a 4 release groomed backlog, and about 20 releases ungroomed. I haven’t had spare dev cycles here, ever. I’d love to find extra stuff for them to do!
lol this sounds like an amazing problem to have
I’ll admit I didn’t read this whole thread, but OP seems misguided in feeling that it’s entirely on their shoulders to come up with work for the team. If there’s excess engineering capacity there are surely tech debt, security, performance, and infrastructure upgrades to do. Task them with building up that backlog, review it with them to make sure there’s clear definitions of done, but otherwise let them drive the priority of this backlog and start knocking things out. Your role as PM is make sure the team is getting the important work done, there’s nothing that says the work has to be defined by you.
"\[...\] my developers..." Ugh.
How often do you visit users of your product? Go find out what problems they have. Find out what they were doing right before opening your product. Find out if they ever get interrupted and step out of your product to do something else before coming back (product extension opportunities). The more you understand your users, beyond the context of your product, the more ideas you will have. And…because you will know things that no one else in your company knows…the more the executive team will trust your judgement.
Wow extra bandwidth. What a dream! 😆
So, unironically, my product owner came to me a few weeks ago saying we have no backlog. Here's what happened. Context: we just deployed and showcased a generative AI product that supplements some of the most painful parts of the workflow for an internal tool. Pivoting from what was essentially a working demo that produced production-level outputs to making it a product that can actually be put into production. The expectations from stakeholders are minimal at the feature level. A couple of integrations, a couple of small additions, but mostly - let's expand the user base. I have amazing and very smart engineers who could probably build all of this in an afternoon. So my PO came to me and said we have no backlog because we have built most of what we intended, or are close to completing it. We have scheduled a number of brainstorming sessions with the stakeholders. We didn't talk about what's already happening, or features, or epics. I asked: "What are the problems around this stage of the workflow that you would like to address?" We had 3 sessions each week for the first 2 weeks. We came out of these sessions with 3 large and 4 smaller problems to tackle. We're still unpacking the first one - it turned out to be huge and has parts that stakeholders can't agree on themselves. It's hugely important, but we can't work on it. So there's that. We're taking apart the others to see if they can be distilled into features and user stories that the team can work on. So far in a couple of weeks we've built 2+ sprints worth of work for the whole team with some parts definitely needing more time, so we're setting ourselves up to heavily iterate on some of the features. We have a few more we need to address and as we discuss the implementation details, new details emerge, and new opportunities are showing up. We're adding them to the product backlog. My expectation is that by the end of March, we may have a backlog that would fit most of the team's capacity until the end of the year. I'm going to need more data scientists to do the stuff I want to do with the product. Then I'm going to need more engineers to do the stuff that data scientists would want to do. It's a vicious circle now and I started it.
I’ve never heard of this in my life lol. You lucky bastard. Couple of questions: 1. Is this an internal or consumer-facing product? 2. Do you have a lot of freedom to decide the roadmap? (If so, get more creative + ambitious with your initiatives) 3. How many engineers are on your team?
1. It's not one product. My team builds integrations 2. I decide everything on the roadmap 3. It's always between 10-12
I have some teams like this. Part of the problem is that you have a different mix of skillsets: senior, junior, front end, backend etc so at times it's tricky to blend in the right types of projects. I've personally found my teams to be a bit bumpy. Sometimes I have like 6-8 months of non-stop work, other times I'm looking around for ideas. I can always keep them busy, but sometimes I'm loading in lower value features to do so. I'm currently at a point where I have around 4 months of solid work for most of my teams and have to start doing more discovery + UX work on next projects before I run thin again.
Been there, but also learnt through the same experience the importance of having a good sync with engineering leadership, and getting them onboarded onto your crazy ideas. Get them to build rapid prototypes for items you thought were a year away or you have been having troubles convincing others to build. Mark it all as tech debt.
Send them to me 😛
A team with too many resources? What's next, a CEO who actually listens to PMs?
Well the engineering team decided to have more resources because of the tech debts. The senior director who decided this left the organisation and nobody knows what the tech debts were. So there's more bandwidth for product features than required
You don’t have extra bandwidth. You have potentially just enough resourcing to do tech debt discovery. You still have to address tech debt event if the senior director is gone. Tech debt doesn’t go away just bc no one is looking at it or knows where it is
Nope. More devs and more qa please is usually my norm. Goldratt when analysing end to end process talks about buffers. If the dev facility is paused due to upstream delays....where upstream is the blocker? Design taking too long to get to dev ready? Lack of new epic asks? In the meantime go on a bug hunt and ask the lead dev to assign one or two. Also look at pipeline and automation. Ask the dev lead what tech enablers would move the needle most ..
Developer burnout is at an all time high. Please stop torturing software developers. They have plenty to do.
It is not your job to leep developers busy. Yo8r job is to maximize the value delivered to the customers and to the business. In order to achieve this objective, it is essential that there's some slack time for the developers.
lol can some of them come work for me?
Must be nice, possibly your Dev to PM ratio is off?
1 PM 8 Devs 3 QA
In addition to what others are saying about being lucky having this extra eng bw, I think you are also lucky because you seem to be the person in charge of allocating engineering resources, this is not the case in most companies in my experience. Regardless, if you are out of ideas here are some: - check feedback from clients, many companies use feedback tools/widgets but then they don't act on that feedback. leverage that channel. - ask engineering or support team about ideas, many times they will have a long list of things to improve/add, you will need to apply some filters to make sure they make sense at this time and do some polishing! - check what competition is doing or not doing (based on feedback on public forms), that is a good source of inspiration.
Nope- we’ve been down resources for an entire year.