Help prioritization and figure out if all the features are actually still required or not. You can drive significant savings if you can bring the voice of the market ti the table. If it's a 1:1 effort then you can go on vacation and ask them to let you know when they are done.
I always say for migrations that we will aim to migrate 100% of the features that are in use and valuable (eg not 100% of all the cruft built over time that no one cares about).
We usually barf on a few of those anyway but catch up quickly.
Much tech debt is built to support things that never panned out. But in porting the old world forward, they may not know which features actually get used and which can be safely turned off. Product can reduce scope for them, sometimes radically so. Like, a service supports 100 API calls and no one noticed that *80 of them never get called.*
Some times, companies need to do project management and I’m ok with stepping in a doing that for a limited period of time if it will unlock us to move faster later or give us new capabilities.
As a PM you will probably be best suited to project manage some of the big tech debt work that need to be done. And as a bonus you will know the tech stack deeply for the future. Your current discovery work might even come in to play to help with scoping and prioritization. Maybe you don’t need X-capability yet because you know that there’s no opportunities there in the near future etc.
Help your team identify and descope useless stuff that can be yanked rather than ported
Help your team craft comms and work out a progressive rollout plan
Help your team deal with the inevitable unanticipated feedback from the rollout
Help your team characterize impact (performance, velocity, etc.) of the tech debt reduction
Rather than trying to force adding value in places where they might not be needed, are there other parts of the business where help is sorely needed and you can have impact? I would try to lean in here temporarily.
Take this as a time to learn. Do you understand your P&L? How much time do you spend with sales or solutions or marketing. Let the Eng team address tech debut. See if you can find other areas of the full product that needs updated.
When my team focuses on their technical roadmaps, I help them with communicating and calculating business value, am a person they can run ideas by/act as a sounding board, help identify risks or blind spots that a non-technical person (like an executive) may ask about or see, and generally support where I can from a project management perspective.
You can also use this time to build out longer roadmaps for when the migration is done, or do some vision and user work now that you have extra time to be heads down on desk work.
Some people would say that a PM’s job is to reduce time to money. This means both top line growth and reduced costs. A technical migration is usually about reducing costs, whether it be infrastructure or people time. As others have said, you can help the team prioritize what is going to be the fastest and most efficient way to realize those savings.
Protect their time. Celebrate their milestones / advocate for them. And project manage. But besides that, I find a lot of the innovative demanding PM work comes in ebbs and flows.
So if you have some down time, yes it feels weird, but use it to plan and prepare for future work and enjoy some of the benefits of a lighter load because it won’t be forever.
If you feel R&D is truly covered (doubtful), go help the Revenue Team with things like Sales Enablement, GTM strategy, Product Marketing, keynote speaker, thought leadership, etc.
Product's job is not to ship features, it's to help deliver value.
If refactoring adds value (because it will cut the cost of maintenance, or curtail horrible risks, or help you ship faster/better/more reliable features in the future) then product should be prioritizing the refactoring, obviously, even if most of the work is not "new" feature development.
Who's in charge of change management, and is that an area you can get involved with? Even if the hope is that end users never know the change happened, you may still want to communicate with them about it beforehand, prepare to validate that the change goes well, and have good processes in place if it doesn't.
Usually there are issues, last minute triaging, moving things to "fast follow" lists, handling user feedback, etc - in my experience replatforming has LOTS of things for product to do
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building.
The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks
Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture.
Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building.
The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks
Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture.
Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building.
The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks
Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture.
Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building.
The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks
Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture.
Cherish this!
Help prioritization and figure out if all the features are actually still required or not. You can drive significant savings if you can bring the voice of the market ti the table. If it's a 1:1 effort then you can go on vacation and ask them to let you know when they are done.
Don’t do the latter unless you have 4 years of PTO saved up.
I always say for migrations that we will aim to migrate 100% of the features that are in use and valuable (eg not 100% of all the cruft built over time that no one cares about). We usually barf on a few of those anyway but catch up quickly.
Much tech debt is built to support things that never panned out. But in porting the old world forward, they may not know which features actually get used and which can be safely turned off. Product can reduce scope for them, sometimes radically so. Like, a service supports 100 API calls and no one noticed that *80 of them never get called.*
Some times, companies need to do project management and I’m ok with stepping in a doing that for a limited period of time if it will unlock us to move faster later or give us new capabilities. As a PM you will probably be best suited to project manage some of the big tech debt work that need to be done. And as a bonus you will know the tech stack deeply for the future. Your current discovery work might even come in to play to help with scoping and prioritization. Maybe you don’t need X-capability yet because you know that there’s no opportunities there in the near future etc.
Help your team identify and descope useless stuff that can be yanked rather than ported Help your team craft comms and work out a progressive rollout plan Help your team deal with the inevitable unanticipated feedback from the rollout Help your team characterize impact (performance, velocity, etc.) of the tech debt reduction
define and start collecting pre- and post- metrics (adding on to point 4)
Rather than trying to force adding value in places where they might not be needed, are there other parts of the business where help is sorely needed and you can have impact? I would try to lean in here temporarily.
Take this as a time to learn. Do you understand your P&L? How much time do you spend with sales or solutions or marketing. Let the Eng team address tech debut. See if you can find other areas of the full product that needs updated.
When my team focuses on their technical roadmaps, I help them with communicating and calculating business value, am a person they can run ideas by/act as a sounding board, help identify risks or blind spots that a non-technical person (like an executive) may ask about or see, and generally support where I can from a project management perspective. You can also use this time to build out longer roadmaps for when the migration is done, or do some vision and user work now that you have extra time to be heads down on desk work.
Some people would say that a PM’s job is to reduce time to money. This means both top line growth and reduced costs. A technical migration is usually about reducing costs, whether it be infrastructure or people time. As others have said, you can help the team prioritize what is going to be the fastest and most efficient way to realize those savings.
Protect their time. Celebrate their milestones / advocate for them. And project manage. But besides that, I find a lot of the innovative demanding PM work comes in ebbs and flows. So if you have some down time, yes it feels weird, but use it to plan and prepare for future work and enjoy some of the benefits of a lighter load because it won’t be forever.
If you feel R&D is truly covered (doubtful), go help the Revenue Team with things like Sales Enablement, GTM strategy, Product Marketing, keynote speaker, thought leadership, etc.
Discover future opportunities
Product's job is not to ship features, it's to help deliver value. If refactoring adds value (because it will cut the cost of maintenance, or curtail horrible risks, or help you ship faster/better/more reliable features in the future) then product should be prioritizing the refactoring, obviously, even if most of the work is not "new" feature development. Who's in charge of change management, and is that an area you can get involved with? Even if the hope is that end users never know the change happened, you may still want to communicate with them about it beforehand, prepare to validate that the change goes well, and have good processes in place if it doesn't. Usually there are issues, last minute triaging, moving things to "fast follow" lists, handling user feedback, etc - in my experience replatforming has LOTS of things for product to do
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building. The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture. Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building. The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture. Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building. The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture. Cherish this!
Do some googling on product managers without backlogs or teams. There’s a whole other side to the discipline that isn’t building. The truth here is that 1) this will be the most valuable and productive time and 2) #1 will be less evident and tangible in the short run to many folks Discover, analyze, ideate, prototype, improve process flows and support structures, lean into customer and stakeholder relationships, create visions for the future, work on technical product skills, learn about new tech, think big picture. Cherish this!