Eight figures saved, every year

The Automation Experience Team turns manual business processes into automated workflows on Comcast's internal Flow Engine platform. My team owns Paths, the part of Flow Engine where these automations are designed and delivered. Requests come in from business teams across the company, and each one competes for the same engineering, design, and platform capacity.

Automation requests arrived with very different levels of clarity, and the delivery process had friction built in:

• Prioritization focused mostly on impact, without a consistent view of effort or blockers.
• Design had to be fully finished before development could start, so work happened in sequence.
• Paths had no design system, so every new automation reinvented its UI patterns.
• Comcast has a federated API landscape, so developers often had to track down documentation themselves mid-build.

Senior Product Manager. I own each automation from assignment through launch: discovery, process analysis, solution design, cross-functional alignment, and delivery. I also improved the delivery process itself.

1. 1.

   Intake and prioritization

   I review incoming business requests and their requirements, then score each one on impact, effort, and blockers. Weighing all three helps the team commit to work that will deliver value and actually ship. Approved automations are then assigned for delivery.

2. 2.

   Discovery and stakeholder mapping

   Once I'm assigned an automation, I identify everyone involved, meet with the business team, and review the requirements together to agree on the problem we're solving.

3. 3.

   Early technical feasibility

   Before going deep on process work, I pull out the technical requirements and review them with engineering first. Ruling out the infeasible early saves everyone from designing something we can't build.

4. 4.

   Current-state process mapping

   I interview subject matter experts, process owners, and stakeholders, collect all existing process documentation, and map how the work really happens today. Along the way I find gaps and conflicting accounts and resolve them, then confirm the map with process owners and invite more feedback from the business.

5. 5.

   Simplify, then automate

   Before automating anything, I look for steps to streamline or remove. Then I identify where automation adds the most value, choosing the right tool for each step with engineering: Paths workflows, APIs where they exist, and RPA where they don't.

6. 6.

   Future-state blueprint and alignment

   I mock up the proposed future state and lead a kickoff with every team involved to reach consensus on exactly what we're building.

7. 7.

   Staggered design and development

   When an automation needs UI work, I bring in design and break the work into staggered sprints: content first, then journey mapping, then UI. Each stage starts as soon as the one before it gives it enough to work with. Signed-off designs then go to development sprint by sprint, so design and development run in parallel instead of one after the other. Many automations need little or no UI, and those go straight to development.

8. 8.

   API readiness

   Before handoff, I gather the API documentation the developers will need, so they start with everything in hand instead of searching for it mid-build.

9. 9.

   Launch and lifecycle

   Development carries the automation through to launch, and the business team leads training and documentation for its users. After launch, I manage the product going forward: bug fixes, enhancements, and new feature requests.

• Impact alone isn't a priority. The best bets weigh impact against effort and blockers.
• Ask engineering first. Checking feasibility before process work keeps discovery grounded.
• Simplify before you automate. Automating a broken process just makes it break faster.
• The biggest delays sit between teams, not within them. The largest gains came from fixing handoffs: design to development, and documentation to developers.