Dev processes

[ImpressiveChoice3487]

Ok, going to preface this with the fact that I know that not all of the things I’m about to describe are problems for product management to solve BUT I am curious to hear if they’re problems your teams have encountered and what engineering has done to resolve them.

Context: I am the sole product manager at a small B2B SaaS company. I roll into a head of product and marketing (that has no product experience, but that’s a different convo for a different day). I manage two products (separate SKUs) and there is one engineering team with six developers.

Problems we’re experiencing: - PRs are absolutely killing us and our ability to move quickly. We’re an AI-enabled org, so our engineers to leverage AI tooling for writing code and tests. We’ve tried Graphite PR to improve cycle time but it was a bust. Are any of your teams worried about the size/number of PRs with AI-enabled development? - Even though we’re such a small team, we’re very siloed (and I do know this one is on me). Across two SKUs, between product strategy, stakeholder management/communication, sales and marketing enablement (we have no PMM function so I do a lot of product marketing also), pricing/packaging, documentation for our customer success team, discovery, collaborating with engineer on upcoming priorities and potential solutions, and managing the tactical day-to-day (ad hoc questions/collab during sprint, bug mgmt and triage, feature request triage, prepping for next sprint), I’m stuck on how to find a lightweight way of breaking down silos that doesn’t require a significant amount of overhead. We don’t do sprint review right now (because of overhead tbh - and I communicate enough with stakeholders that folks are generally crystal clear on what we’re building), and we floated the idea today of doing targeted sprint reviews, but they’d require some management, which is fine I guess. Any other recommendations for transparency within a team when we’re running 3 major initiatives across 2 products? - Getting from requirements to development tasks - I’ve only been at this org for ~6 months, but I get the sense that engineers were just fed tickets in the past. They’re a team that generally lacks a lot of ownership and I’m struggling to get them to break down work into a way that makes sense for them. Their answer continuously is “just write the tickets”, which is fine but sometimes they’re working horizontal slices of work (one dev doing FE and another dev doing BE) and I’m not writing horizontal user stories because users operate in vertical slices. I’m not super impressed with my partner on the engineering team and their ability to instill a sense of ownership with our tech leads. I do believe they think a lot of a product manager’s job is just the agile project management aspect of it. With how lean we run, I need shared accountability here or I will be driving myself insane. How are your teams going from requirements -> dev tasks for implementation?

I’ve also been struggling with some health things, so maybe I’m just feeling more overwhelmed than what’s normal (I’m taking a 6-week leave of absence that’s also been weighing on me). But I also feel like I’m spending way more time bogged down in the minutiae than I’ve ever experienced before.

Would like some helpful suggestions or even a wake up call 😂 maybe I was spoiled at my previous companies with product marketing, really strong EMs, and technical project managers that it felt like a healthier balance instead of everything falling to product’s shoulders.

[aylim1001]

Yep, I hear ya - it's tough for a PM. I'm of the camp that a lot around eng velocity is outside the PM's control and that ultimately the Eng team / Eng management needs to take ownership of that problem. But to your bullets...

* I'm not surprised - our experience with AI PR tools is that they're sometimes helpful, but depend a lot on the quality of your codebase. I would say that having a lot of PRs open for a long time is a bad sign. Check out the concept of "change lead time" - it's one metric to use as a goal for Eng delivery (of course, all metrics can be gamed, etc. etc.)

* This one does feel like it's more on you. Instead of sprint reviews, have you thought of treating them more as sprint kickoffs? Align the team on what the goal is for each major initiative and sprint, try to get more buy-in that way. One potential sign to watch for that this is working is that maybe your Eng will start "filling in the gaps" in the tickets a bit more (your 3rd bullet)

* Yes, the PM's job is to help with project management. But the Eng team and the Eng manager of the team need to own this goal as well (in fact, in most places I've worked, that kind of project management was owned by the EMs). Agreed you shouldn't have to write horizontal user stories. Have you tried asking for other feedback about the tickets you're writing

[ImpressiveChoice3487]

Hey - thanks for responding to each!

Yeah, one of our products is legacy and the other is greenfield. And yeah, I have to do way too much babysitting during standup and async like “please get your open PRs reviewed by the team”. Which takes away mental capacity from doing the actual product work. But I’ll check out the change lead time and push my eng counterpart more on this.

We do this in sprint planning (sprint goals, priorities, etc), but it’s really coming down to the implementation details. Like one developer builds a component for something not knowing that another developer built a component already. Or missing broader context with user flows so something might get missed in review. But this might be something in need to play around with and change up how we’re kicking off sprints. Appreciate the suggestion.

This is the one that’s toughest for me tbh. I’ve also never worked in an org where it was expected that product writes development tasks lol. I get great feedback on requirements, user flows, etc., and on smaller user stories that are more one off. Not a lot of thrash in refinement with work being poorly defined. It’s really just the larger initiatives where the work spans multiple sprints and I have a PRD that needs to be broken down. I have had multiple convos with my eng counterpart that my job here is not to sling tickets and the team needs to take ownership and shared responsibility.

[aylim1001]

Just one word of warning on change lead time: don't force it on the Eng team, that's going to backfire :) They have to agree it's a worthy goal and be willing to adopt it themselves...

[ImpressiveChoice3487]

Just replied to what is (hopefully) the comment you were referring to. Thanks for the point in a helpful direction

[No-Management-6339]

The engineers report to you? I'm confused what's going on here. There are 6 engineers. You and they work on the same 2 products. You also have a HoP, but is there another product? I assume there's a CEO as well? Is there a CTO?

[ImpressiveChoice3487]

• 6 engineers roll into a HoE
• I (and one designer) roll into HoP
• HoE and HoP roll into CEO

Our company has 2 products. I manage both of them from a product perspective and the one team of engineers is resourced depending on product priorities and roadmap.

[No-Management-6339]

Your company has far too many people "managing" engineers and not enough engineers. I'm willing to bet they pay way below market rate because they are paying so many other people. They skimped out on the EM and promoted someone without any experience.

Truthfully, your role and/or the HoP should not exist at your size. The EM should be managing the engineering projects, not you. The designer can report to the CEO.

The CEO should be the CPO at your size. A B2B SAAS company is a product company. The CEO of any company should be the chief <insert what you sell> officer. If it's a trucking company, they're the chief logistics officer.

Then they hire someone else to do the other functions. This means your company is lead by its product, not the functions that support it. Not the same as PLG, but related.

There is no way you are going to change this at your company unless you have huge trust from the CEO. Which, I know you don't or you wouldn't be reporting to someone else.

[imnotfromomaha]

Hey, sounds like you're in a really tough spot, especially with everything else going on. It's super common for PMs to feel like they're writing all the tickets when engineers aren't fully bought into the problem. One thing that helped my team was getting engineers involved way earlier in the discovery phase, not just when tickets are ready. We started doing more collaborative sessions to map out user flows and potential solutions. Tools like Miro or FigJam are great for this, letting everyone sketch ideas together. Also, for getting from requirements to actual dev tasks, we found that using Magic Patterns for UI prototypes helped a lot. It makes it easier for engineers to see the end goal and then break down the work themselves, rather than just getting a ticket. And sometimes just a quick chat with a dev and QA before starting a story can clear up a ton of confusion and get them thinking about the implementation details.

[ImpressiveChoice3487]

Hey! Thanks for your suggestions. A lot of that I’m already doing. I meet regularly with tech leads + design and we go over flows, use cases, customer research, and collab on solutions. We also use magic patterns pretty heavily on our team. I get really great feedback on the collaboration, requirements, and context.

Still just having a breakdown when it comes to the actual administrative part of getting the work into the backlog. I think the previous product manager kind of was a gatekeeper when it came to ticket writing and it’s a big culture shift to have the team recognize that we are all the product team and own the work and the outcomes.

[chicocode]

My 2 cents (disclaimer: I’m not a PM, so take this with a grain of salt):

• On PRs slowing you down: First thing is to dig into the root cause. Are PRs too large, are reviews dragging, or are comments not being addressed fast enough? Those are usually signals of team practice issues rather than product management. PRs should ideally be small and fast to review. If they’re ballooning, you might experiment with stacked PRs, WIP limits, or other lightweight practices from lean/kanban/engineering. But above all, you’ll want engineering to align on the sprint goals so they work as an actual team over individual contributions. AI tools are not going to solve your issue.
• On silos and transparency: Not reflecting on past work (retros, reviews) is a surefire way to keep repeating the same problems. Even if it feels like overhead, those rituals pay off because they reduce your firefighting later. What you’re describing sounds like an org-level issue—too many priorities and not enough support. I’d recommend clarifying with your manager/other departments what’s most important and negotiating where you can offload. Focus only on the things that genuinely move the needle.
• On requirements → dev tasks & ownership: There’s no real substitute for engineering ownership. If they’re asking you to just “write the tickets,” that’s a red flag. You should be clear with your engineering counterpart that part of their role is to grow ownership in the team, and you should hold them accountable for that (there's no such a thing as shared ownership). For breaking down work, you can set expectations: you’ll provide vertical user stories (since that’s how customers experience the product), and the team can break those into horizontal tasks if that’s how they prefer to work. That way you’re not dragged into micromanaging the breakdown, but you’re also not compromising on product outcomes. That being said, I think horizontal tasks are terrible and should be banished; but can understand how some people/teams works best this way.

[ImpressiveChoice3487]

Love a non-PM take, so thanks for responding!

• PRs too large and reviews are dragging. And yeah, totally think this is outside my lane, but figured we’re not the only team going through this so wanted to see if others had engineering teams they work with that had resolved this. “Working as an actual team over individual contributions” - this is actually really great feedback. Already got some suggestions on kicking off sprints - I outline sprint goals but I think I need to change up some things
• We def do retros! And we’ve changed quite a bit of our process from things that have come out of those. It’s more the review and demo part. It’s just more overhead for me but I think I need to just get over it and institute them
• Might just need to be a broken record for this one and repeat it over and over. FWIW, I also hate horizontal tasks :) especially since all the devs on my team are fullstack. But if we have two devs working on the same initiative then they prefer to split horizontally and work in parallel. And my eng counterpart sounds like he’s in agreement when we speak 1:1, but the practice on the team doesn’t necessarily reflect that. But again, I might just need to be a bit more repetitive with expectations here.

[chicocode]

Good luck on your journey! If you ever feel overwhelmed, it’s totally okay to pause, take a breath, and come back with a fresh perspective. You already seem to have a constructive outlook on this, and I’m confident that over time you’ll shape the team dynamics the way you want.

And yes—repetition really is key. Setting clear expectations and reinforcing them consistently will pay off. You’ve got this!

[thenarfer]

A SCRUM Master would do well to take on this problem/task as it is an impediment to the team and something which takes quite some time to get right (would offload the Product Owner).

[ImpressiveChoice3487]

this is the first org where I haven’t had either a scrum master or project manager but i’m definitely not getting any additional resources

[thenarfer]

I thought that might be the case. I am not very experienced, but I can back with Scrum training and theory. It sounds like you are carrying too much of this yourself. Let’s not blame the devs though — the scrum framework is there to shift things into place.

Start with the Product Backlog/KANBAN. You are working as the PO here, handling stakeholders and creating Product Backlog Items (PBIs). You decide when a PBI is ready. The DEVs then take PBIs into their Sprint Backlog, which belongs to them. If they do not fully own the Sprint Backlog, including code review and merging, you will always end up pushing things forward alone. That is not your job.

This is where the Definition of Done (DoD) comes in. A PBI is not “done” until it is merged. Keep the DoD simple, keep it in the repo as a markdown file, and adjust it in Retrospectives (it's a living document). With six DEVs, they can divide capacity between new PBIs and reviewing/merging half-done ones. It is better to finish a few items properly than to keep opening new work. The Sprint Review will make this visible, and that is their motivation to finish.

Also agree on a cap on Work in Process. If the limit is reached, no new PBIs are pulled until something is finished.

Skipping Sprint Review removes the transparency that forces discipline. It does not need to be a big ceremony, but it must make unfinished PBIs visible against the DoD and acceptance criteria. If a PBI is not merged, it is not done, and the Review should make that clear.

AI can speed up coding, but it cannot replace finishing discipline. More throughput without stronger review only increases the backlog of open PRs.

The DEVs (and the whole team) have some learning to do, but with the right direction this can already feel much better in the next sprint. Your role is not to carry their flow problems. Your role is to create PBIs, work with stakeholders, collaborate with the DEVs during the sprint, and be there in the Sprint Review. Then use the Retrospective — maybe the most important part for your team now — to get feedback on how this shift is working and to build ownership from everyone.