Trying to be the PM, but keep getting caught up in the day-to-day execution at new job

Background: I started a new job about 3 months ago so I am still learning a lot about the product, team, customers and processes. I feel like I’ve made good progress so far, but feeling overwhelmed by the teams requests and like I can’t keep up.

My current product team has 1 scrum master, 1 tech lead, 1 tech lead/dev combo, 6 devs and 2 QAs. I didn’t have a lot of work in the product backlog to inherit when I got this role so I’ve been having to build all of this myself and had a hard time keeping up between discovery/learning vs creating tasks for the team for each sprint in the meantime. I’m finally getting to a point of having a solid roadmap to work off of and can start breaking initiatives down into epics and stories. I have been open with the team sharing the product vision and roadmap for the year, outlining our priorities and welcoming new ideas or feedback. Here is my problem.

Our sprints are every 2 weeks and I often don’t have time for discovery/planning ahead because I’m caught up in solving the “how to build” anytime I found the “what to build.”

Here’s what I mean: I’ll create an epic for the overall feature goal (i.e “customer can manage appointments”)and create user stories for each feature in that epic (each story is a different type of option like “book appt” or “look up appt”). During grooming, I’ll review the feature and provide context and what problem we are trying to solve with it. Often the team isn’t sure how to execute so they will create a spike and we’ll have to focus on that first (i.e. “spike: how to look up appointments”). I’m fine with spikes, but they tend to require me to gather the information or reach out to whomever might know depending on what questions the dev team has (I.e. where does the data live for booked appts or what info should we use to look their appt up). This has resulted in me trying to gather some possible ways to build something and collect the necessary information to do so before I even make the story. Or it leads to having a list of new features but only have a few things we can actually develop in the next sprint. note: this is all hypothetical examples to explain a bit better

My other issue is when I have these new features with all the details, which may range between 3-5 each sprint, it’s not really enough work for the team. The stories may focus on one or two areas that only a couple of devs are familiar with and can complete skill wise so it leaves the others unsure of what tasks to pick up. I’ve tried to make an effort to include tech debt and bugs in the sprint so it’s not just feature focused, but the team rarely has any of these tasks identified and created or have any in mind. It seems like if the task doesn’t come from me, it won’t get created.

Am I doing something wrong? Should I be the one to gather all the detailed requirements and am I struggling just because I’m still new and learning on what those details can be? I just feel a tad confused because in my last PM role I was a lot more hands off with the devs. We’d have a backlog meeting and I’d share what feature needs to be implemented, answer any clarifying questions about it, get an estimation, and then could prioritize off that and plan the sprint. I wasn’t privy to the actual development tasks needed to carry out the feature, but would provide guidance when the team presented different development options or there was an issue found with the original feature request.

TL:DR Started a new job 3 months ago with a large product team. Dev team is having a hard time executing on feature requests without all the details upfront which requires me to spend time collecting and gathering those before the sprint. This leaves me with little time to plan for the future or do discovery unless I decided to overwork myself more than what I’m currently already having to do. I constantly feel like I’m planning sprint to sprint and barely making it by. How can I get out of this cycle?

8 Likes

Ohhhh I’ve been in your shoes.

I kinda feel like you’re being taken for a ride by your tech leads.

“How to build” is not your job. Try and get some help from the tech lead(s) on this. Especially when it comes to ‘where does the data live for X”. If they don’t know, and you don’t know, make it part of the spike. That’s what a spike/research effort is for.

It’s also not your job to load balance tech work among the team or skill up other members of the engineering org. That’s your tech leads responsibility in conjunction with an engineering manager. If there is a consistent staffing gap that is causing problems, bring it up with tha dev manager / tech lead. You can assist by sharing context of where the product needs to go and why so the eng manager can work backwards from there to some kind of staffing plan.

You have a good point about tech debt. Challenge the tech leads to come up with some tech debt that matters and have them scope it out. Give them what they need, which is upcoming major business challenges /customer pain points that will hit your team in the face in 6 months. Can your stack accommodate that? What major areas should be investigated? Or what just bugs the shit out of them that they’ve always wanted to tackle?

This is also part of their responsibility — not yours. While they identify and work on this, you get runway to research new value adds.

You may need to set a hard boundary here because it sounds like your tech leads are used to you doing a lot of this work for them. but hey that’s where the “influence” part of your role comes in :grinning: Correctly offloading this work should save you a decent bit of time.

You may also need help from your manager or some assistance from like a jr PM or PO. It’s difficult if not impossible to be strategic and tactical at the same time. But take that route only after your tech leads start to pull their weight more.

8 Likes

@Samantha, Thanks for the comment and confirming some of my thoughts! This is only my second company I’ve been a PM at so I thought maybe I just had a different idea of what the work entails.

The tech lead has mainly been responsible for managing the on boarding of new devs and handling release related tasks. Not so much the delegation of tasks within the dev team :’(. It’s a very different structure than I’m used to, but maybe it’s something I should find a way to address and bring up because they could be unaware as well.

I’ve definitely given them goals about some potential business challenges and what we’ll need to support in the next 6 months- we’re going from 5 million users to 25 by the end of this year so we need to be able to scale. I have no idea how well do that from a technical perspective and lean on them to provide insight but feeling like it’s just not there.

7 Likes

Isn’t this the job of the scrum master? You mention one of them in your team but where are they in all this?

As everyone has already pointed out, you are being given work to do that isn’t yours. I would take the opportunity of being new to set up a “roles and responsibilities” session so that you can ~clarify~ who is meant to be doing what (aka tell people to start doing their job). It sounds like you’ve got a very, very passive team who have either been coasting, aren’t fond of thinking or taking any initiative, and unless you want to micromanage babysit them forever, you’re going to have to get them to start doing more.

Also, your last sentence where you say you don’t know if the team have the right technical perspective/insight for the business goals? Big alarm bells. It sounds like you may have a big team, but they are either not being used effectively or are not as good as they think they are.

In addition to all the above, I’d start networking internally, look to speak to whoever the overall software architect is and check about how realistic those scaling plans actually are, talk to other tech leads etc. and figure out if the entire company is like this (in which case…good luck?) or if you’ve been saddled with the dud team (has been known to happen).

Finally, what does your manager think about all this? Again, if they think all this is normal, its going to tell you a lot about the company culture…

6 Likes

I did an Agile refresher recently and can confirm ryry & enrico’s perspectives/advice.

If people resist working collaboratively and getting more involved, then they are resisting the Agile methodology. Agile helps teams achieve worthy goals faster, even if each individual feels that their bit of work is slow-paced or seems redundant. For a team to move fast as a whole, and understand their purpose, they need to work together, not delivering whole chunks of work individually on to the next person.

You should be there to define product-market fit and priorities (also collaboratively with tech, business and customer representatives), resulting into epics or general user stories. Not to create requirements or how-to’s; this is supposed to be done collaboratively and owned by engineering.

I wonder where your scrum master stands on all of this.

7 Likes

@ChristieDook, Our Scrum Master is new so could be that they’re still learning.

In regards to the scaling thing, I was referring to i have no idea how to do that because that’s not my expertise so I cannot create the necessary stories/tasks needed. I’ve been relying on them, they just haven’t created anything yet. The engineering manager has brought up its importance too and created some tasks in the past for them.

I don’t think all product teams are like this, but I do work in a large organization and manage one other product. The tech lead is much different on that side and the devs tend to find their own stories/tasks that come up after I bring in new features.

6 Likes

Re: scaling, my point is that they should know and be planning for it. Scaling at that level is not usually something that happens quickly and without a lot of background prep if you want it to go smoothly, so if they aren’t doing it or no one is taking charge of it, that’s not ideal. My suggestion is to raise it as an issue, and keep flagging the fact that someone needs to be looking into it. If the Engineering Manager has raised it in the past, go back to them and tell them this is still a problem. (I would class this as one of those strategic things that is getting dropped because you are getting pulled into things that aren’t your job FYI)

6 Likes

Focus on higher level epics that have value and let your engineering team figure out how to build it. You shouldnt be involved in research for spikes for example. You would come in if the result of that spike means you need to do a trade-off or make a decision, but not in the research itself.

5 Likes

@VladPodpoly, For us, we set aside about 2-4 weeks of UX research, 2 weeks of solutioning (where the initiative tech lead volunteer will lead the HOW to build with technical stakeholders), 1 week of work breakdown where the team gets together to break epics and pieces of work into story maps

It sounds like it would also help OP to get dev notes into the stories before bringing them to grooming. I get volunteers to take dev notes and give the dev about a week to get them in

4 Likes

The company is getting great value if they’re paying you to run product AND a manage a team of devs! I first started in hardware and moved into connected products. Lucky for me, I had a fantastic software director as a mentor. If I were you:

  1. Reset expectations immediately. You tell them (devs) what to build and when, never how. Haha… you certainly do not do tech research for their spikes. Why would a dev want a Product person tell them how to implement? That’s super weird, perhaps the dev team is afraid of being accountable?
  2. I would have a chat with the person running the software team to get devs to work on stories out of their “core” areas (this assumes the work being done isn’t super domain specific and does not require specialist knowledge). Is it as efficient? Probably not but it means you have a lot of more flexibility and fewer devs twiddling their thumbs if they don’t have stories to work on. IMO, working across the whole product helps provide context to devs so they can see the system and not just one cog.
  3. In addition to a scheduled grooming session, have a separate session with your QAs to understand and prioritize bugs.
  4. Be ruthless with time. Cut out non-essential meetings to give you more time for writing stories, grooming, etc. It’s OK to say no.
  5. If you can get more time, get ahead of the 8 ball and build up a pipeline of groomed stories that are ready to go. There’s always some fluffy UI stories or copy changes needed somewhere you can pull out.
3 Likes

First, and most importantly: HOW TO BUILD IS NOT YOUR JOB

Now that we’ve gotten that out of the way, let’s talk about what goes in to building a feature. It typically takes ~4 weeks to bring a feature from ideation to a point where it’s dev ready.

Week 1:

  • Bring business case to UX dev. aske them to build something

Week 2:

  • Bring the business case to the devs. Ask them to come up with a design.
  • Write stories that focus on the business usecase.

Week 3:

  • Review design together (whole team).
  • Expect lots of back and forth. Stories, UX, and Tech design will likely all have to be tweaked

Week 4:

  • Estimate stories

Week 5:

  • Start Dev
2 Likes

Couple ways to keep the devs busy/stall while you build your roadmap.

  • Meet with key cross-functional internal teams and gather high and medium priority requests, then write epics for the requests that require simple requirements aka minimal output from you, but will take a sprint or so of dev time to implement. Not a PM best practice, but it’ll keep the devs busy, giving you time to prep bigger feature sets. I always say: customers have been waiting for a couple features so I’m squeezing them in before we begin focusing on our bigger feature sets.
  • Ask QA to coordinate a bug blitz. Have dev and QA participate (1/2 day). Then pull a bunch of the high/medium bugs into the sprint.
  • How’s performance? Usually you can spot a couple areas within an app that doesn’t load quickly enough. Have the team investigate and propose solutions.

This part sucks, but once you build your roadmap, grab a PSL :coffee:and spend a Sunday cranking out epics.

Lastly, I only write epics- 1 for the UX team so they can create a prototype and 1 for the dev team. Within the dev epic I detail what the acceptance criteria is for MVP, iteration 1, 2, 3 etc. but I’m not responsible for creating the spikes, front end or back end tasks, this is done by the dev manager or feature lead. My epics are fairly detailed and specific, but they only cover the ‘what’ not the ‘how’.

Good luck!!!

1 Like

Whew! That was a fantastic discussion. So much learnt, so much understood, Thank you all for taking the time to post your insights and views. Each and every comment is valuable.
Once again a very BIG Thank you to one and all.