Senior PM says delivery teams need to focus on friction instead of chasing automation

In terms of project delivery, I focus on defining what we build and why, aligning teams on priorities, and ensuring we ship reliably at speed. That means working closely with engineering on execution, while also keeping a strong pulse on customer impact, quality, and continuous improvement.

You should also read

• AI Tool Overload? A Guide to Managing Your Options

• AI Tools That Replaced Manual Work in 2026

• Vibecoding for Project Managers: 6 Vibecoded Project Examples by Real PMs

Why AI shifts project delivery from reactive to strategic

AI has fundamentally shifted both my role and daily project delivery. Before, delivery depended on manual coordination, reactive debugging, and human analysis. Today, with AI embedded into our workflows, the work has become more strategic.

What I spend less time on now:

• Manual triaging and debugging: Earlier, identifying root causes for bugs required multiple back-and-forths across teams. Now, AI systems can detect, classify, and even suggest fixes automatically. This significantly reduced the initial effort.
• Writing detailed specs for every edge case: Instead of exhaustively documenting everything upfront, we rely more on AI-assisted exploration, simulations, and rapid iterations to refine solutions.
• Status tracking and coordination overhead: Progress tracking, summarization, and reporting are now automated, reducing the need for constant follow-ups.

Saloni Shares

My role has evolved from managing execution closely to shaping how intelligent systems execute on our behalf.

What’s getting more of my attention:

• Defining the right problems and signals: Since AI can act quickly, input quality matters much more. I spend more time thinking about what to monitor, what signals matter, and how systems should respond.
• Designing AI-assisted workflows: Instead of just features, we’re designing end-to-end flows where AI agents detect issues, take actions, and sometimes even resolve them. This shift from tools to systems is now a significant part of my role.
• Quality and trust: When AI makes or suggests decisions, ensuring reliability, explainability, and user trust becomes critical. I spend more time validating outputs and defining guardrails.
• Speed with accountability: We’re shipping faster than before, but expectations are also higher. It’s not just about moving fast, but moving fast without regressions. This balance requires tighter product thinking.

Broadly, what’s changed in project delivery: We’ve moved from a human-driven, reactive model to a more AI-augmented, proactive model. We detect issues earlier, resolution cycles shorten, and teams spend less time firefighting and more time improving the system itself.

So my role has evolved from managing execution closely to shaping how intelligent systems execute on our behalf.

How AI transforms incident triage

We didn’t try to automate everything. Instead, we focused on high-frequency, cognitively repetitive areas that slowed down engineers. Incident triage and RCA was one such area because it happens daily, has a high time cost, and is pattern-heavy.

Our agent setup includes a Signal agent that detects anomalies from telemetry; a Context agent that pulls logs, traces, and related runs; an RCA agent that generates root cause and evidence; and an Action agent that creates a ticket with all context. This was the easiest place to start because success is measurable through MTTR.

That led us to build an RCA engine on top of our observability layer.

How AI-driven systems solve complexity in real-world cases

We built an RCA engine to reduce MTTR, but the real shift was moving from manual investigation to system-led diagnosis. The problem was that when a bug came in, logs were scattered across services, engineers had to reconstruct the flow manually, and root-cause analysis depended heavily on individual experience. Even for known issues, MTTR was inconsistent because the process wasn’t repeatable.

As a solution, we built an RCA engine that sits on top of our observability layer and does three things automatically:

Context stitching

• Pulls logs, metrics, and execution traces across services
• Reconstructs the exact path of failure (step-by-step within a batch or flow)

Pattern matching + similarity detection

• Compares the issue with historical incidents
• Uses embeddings to identify similar incidents that have taken place

AI-assisted root cause suggestion

• Classifies the issue (data issue, config issue, code regression, infra)
• Suggests the most likely root cause
• Surfaces supporting evidence, not just an answer

Why AI's impact depends on system quality

Early on, we assumed an LLM layer would directly improve outcomes. It didn’t. The first versions were underwhelming. What we learned quickly was that AI doesn’t fix messy systems. It amplifies them. And we learned that data quality matters more than model quality.

We spent a lot of time fixing inconsistent logs, missing context across services, and poorly defined signals. Once the underlying data became structured and reliable, even simple AI setups worked well.

Trust is just as important as accuracy. Even when the RCA engine or triage system proved technically correct, engineers didn’t use it. Why? Because it didn’t explain itself.

Early on, we assumed an LLM layer would directly improve outcomes. It didn’t. AI doesn’t fix messy systems. It amplifies them. Data quality matters more than model quality.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Saloni MalhotraOpens new window

Senior Product Manager, R&D team at o9 Solutions

People don’t need perfect AI. They need understandable AI. The real gain is not speed — it’s focus. We thought AI would just make us faster. But, engineers weren’t just closing tickets faster. They were starting to ask: “Why does this class of issue exist at all?” That’s a different level of thinking. Narrow and specific beats ambitious and wide. Our early instinct was to build a broad, intelligent system. That failed. AI adoption wasn’t a big bang. It was a series of small, sharp wins.

We saw a shift only when we attached evidence (logs, traces, comparisons) and showed why it reached a specific conclusion. As a result, we spent less time on repetitive investigation and more time on system-level improvements. We then found success by picking specific use cases (like RCA for batch failures), solving them deeply, and expanding gradually.

How AI tools enhance project delivery efficiency

Here's our stack.

AI and intelligence layer:

• LLMs (GPT-class models) — RCA, summarization, classification
• Embeddings + Vector DB (FAISS / Pinecone) — similarity search, incident retrieval
• RAG pipelines — grounding AI outputs with logs and historical data
• Anomaly detection (rules + ML) — failure pattern detection

Observability and data:

• Logging and monitoring (Elastic / Datadog / OpenTelemetry)
• Distributed tracing systems
• Data pipelines (Python, streaming/batch processing)
• Telemetry storage and feature engineering layers

Delivery and workflow:

• CI/CD (GitHub Actions / Jenkins)
• Issue tracking (Jira or similar)
• Release validation / simulation frameworks

Developer productivity:

• Code assistants (GitHub Copilot or similar)
• Internal AI copilots for debugging and querying systems

Overall, the evolution of the past 6-12 months has been:

• From dashboards → AI-assisted insights
• From manual triage → automated RCA
• From siloed tools → connected pipelines
• From reactive debugging → proactive detection

How Claude and Figma boost team productivity

Combining Claude with Figma has been surprisingly high-leverage for us. Before, we used a flow that looked like this: PM writes a PRD, designer interprets it, multiple back-and-forth cycles.

Now, we feed rough ideas, flows, or even messy notes into Claude and ask it to structure flows, suggest edge cases, and generate screen-level thinking.

Then, we directly translate that into Figma, where we create wireframes much faster, explore variations quickly, and think through microcopy and states.

Why lightweight systems replace traditional project management

Traditional systems worked, but they were slow to adapt, had high coordination overhead, and were often disconnected from what was happening in the system. What “traditional” looked like: detailed upfront PRDs (often outdated within weeks), fixed sprint plans with rigid scope, manual status tracking (standups, reports, dashboards), separate tools for planning, execution, and monitoring.

Now we've shifted from heavy PRDs to modular specs and live context. With this new approach we can now break things into: problem definition, key flows, and constraints. We can also store them in lightweight formats (docs + tickets) and use LLMs to expand into edge cases, generate test scenarios.

We now spend so much less time writing exhaustive documents (10–15-page PRDs in Confluence). Instead, we have a 1-page structured input with the problem, user flow and constraints.

To do this we used the following tools:

• Confluence (reduced usage)
• Jira (primary source of truth)
• LLM layer (GPT-class models via API)
• Figma
• Claude (for flow structuring)

Here is our process:

• 1-page structured input:
  • Problem
  • User flow
  • Constraints
• We feed it into Claude / LLM to:
  • Expand flows
  • Generate edge cases
  • Draft acceptance criteria
• We directly convert it into Jira tickets + Figma wireframes

The impact looks like this:

• ~40–50% reduction in time from idea → first build
• Fewer back-and-forth cycles between PM, design, and engineering
• Much clearer first version of features

How AI integration changes delivery rituals

Furthermore, defining scope has shifted from exhaustive to directional. Before, we tried to define everything upfront and cover all edge cases in PRDs. Now, we define the problem, key flows, and constraints. Then we use AI to expand edge cases, simulate scenarios, and highlight gaps. Scope is no longer about completeness on day one; it's about setting a strong direction and enabling a fast refinement loop.

In five years, plans will no longer be “written” — they’ll be continuously generated. I think plans will be live systems not documents. AI will continuously update priorities, risks, and timelines based on real-time execution, customer signals, and system health. Planning will be dynamic and always current, not a periodic exercise.

Saloni Shares

AI works best when it removes a real, daily pain, not when it’s added as a layer.

Why addressing friction is key before AI adoption

Don’t start with AI. Start with friction.

It’s tempting to ask, “Where can we use AI?” That’s usually the wrong starting point. Instead ask: Where are teams wasting time repeatedly? Where does work depend too much on a few individuals? Where do things slow down under pressure? Pick one of those and solve it deeply.

AI works best when it removes a real, daily pain, not when it’s added as a layer.

Follow along

You can follow Saloni's work on LinkedIn.

More expert interviews to come on The Digital Project Manager!