When product managers think of observability, they usually mean uptime, latency, or error rates. But as AI becomes central to user experiences, that definition must expand. Observability now includes monitoring model accuracy, hallucinations, prompt injection, and real-time behavior. As Datadog’s CPO Yanbing Li notes, AI systems add a new layer of complexity to enterprise monitoring.

Why AI demands a new observability lens

Traditional software is deterministic. If a server or a function fails, you can diagnose and fix it. AI systems are probabilistic: a model hallucination may look valid until it misleads a user. Prompt injections or data poisoning might not cause system errors but can quietly undermine trust.

For PMs, this means observability must extend beyond infrastructure metrics to capture:

• Accuracy drift — whether model outputs align with ground truth.
• Security resilience — spotting adversarial prompts or unusual input patterns.
• Behavioral health — tracking whether agents operate within safe, useful boundaries.

Case study: Hallucinations in hospital transcription

Consider OpenAI’s Whisper, deployed in hospitals to transcribe millions of medical conversations. Research found it occasionally hallucinated—generating entire sentences during silences, sometimes violent or nonsensical—in about 1% of transcripts. In clinical settings, even one fabricated note carries serious risks.

This shows why observability must go beyond uptime dashboards. Teams must detect—and act on—content errors that may otherwise slip by unnoticed.

What this means for product teams

1. Behavior-focused dashboards: Observability should surface hallucinations, unsupported claims, and policy violations alongside API errors. Datadog now offers hallucination detection and prompt injection monitoring in its observability suite.
2. Continuous evaluation: Like regression testing, AI models need evolving test suites that reflect real-world prompts and track drift over time.
3. Shared accountability: Observability is not just engineering’s job. Product, design, and trust & safety must all help define what “healthy AI behavior” looks like. Regular model reviews can institutionalize this check.

Most SEO problems look scarier in Google Search Console than they really are. Recently, I ran into one of those situations. Google flagged 17 indexing issues across my site:

• 16 pages marked as “Page with redirect”
• 1 page flagged as “Duplicate without user-selected canonical”

At first glance, this looked like something I’d need SEO expertise to fix. But a quick debugging session with ClaudeCode showed me it was manageable with a bit of structured troubleshooting.

The Background: A Redundant /blog Path

When I first set up my blog, URLs looked like this: blog.suryas.org/blog/[slug]

Later, I cleaned it up to a simpler and more readable format: blog.suryas.org/[slug]

I set up redirects from the old paths to the new ones. Everything seemed fine until Google Search Console started complaining.

Diagnosing the Issues with ClaudeCode

Here’s what we uncovered during the live coding session:

1. Redirect Warnings – The old /blog URLs still exist in Google’s index, so Search Console reports them as “Page with redirect.”
2. Canonical Tag Missing – None of my pages had a canonical tag, leaving Google unsure which version of the page was the “source of truth.”
3. Sitemap Mismatch – The sitemap might still include redirecting URLs.

The Fix Strategy

ClaudeCode mapped out a straightforward plan that didn’t require deep SEO knowledge:

Add Canonical URLs

• Add tags to all layouts (Layout.astro, BlogPost.astro)
• Ensure each page points to its own preferred URL

Update Sitemap

• Verify that only the cleaned-up URLs are included
• Resubmit to Google for reindexing

Improve Redirects

• Keep the wildcard redirect (/blog/* → /:splat 301)
• Add explicit redirects for the most commonly accessed old URLs

Re-indexing Request

• Submit the updated sitemap in Search Console
• Trigger re-indexing for the flagged pages

What more? I have asked it to document the changes, troubleshooting, and best practices for my future reference. Got that!

Final Reflection

The biggest surprise was how approachable this process turned out to be. I didn’t need to be an SEO expert; I just needed a clear diagnosis and a step-by-step plan.

With ClaudeCode guiding the session, what looked like a technical SEO rabbit hole became a clean set of coding tasks: add canonical tags, adjust the sitemap, confirm redirects, and ask Google to re-crawl.

Google hasn’t finished reprocessing the sitemap yet, but I expect the redirect warnings to disappear soon.

Walk into any workplace today, and you’ll see AI embedded in daily tools and workflows. It drafts emails, generates reports, and even proposes design ideas. What it can’t do is sit across from someone, understand their frustration, and respond with care. That distinctly human capacity is becoming the true differentiator.

Carnegie Mellon professor Po-Shen Loh puts it bluntly (video): “The only sustainable trait in the age of AI is the ability to care about people and act on it.”

Machines can replicate knowledge and pattern recognition, but they cannot genuinely understand what it feels like to be human. That gap is where the next era of value will be created.

Empathy as a Competitive Advantage

For product managers and technologists, this is more than philosophy. Empathy drives the ability to design experiences people love, not just tolerate.

A recommendation system can suggest content, but only a team that understands user frustration can simplify onboarding. A chatbot can answer questions, but only a product leader attuned to customer anxieties will build trust into its design.

“Creativity isn’t unique anymore. Empathy and delighting others are what truly matter.”

The Role of Critical Thinking

Loh also warns that in a world overflowing with AI-generated content, the ability to question, validate, and synthesize ideas is critical.

“We must not let AI replace our thinking. We must train ourselves to think, critique, and analyze.”

For product leaders, that means not just interpreting data but challenging its assumptions. What problem are we solving, and for whom? Why now? These are not questions an algorithm can fully answer.

An Entrepreneurial Mindset

Finally, there’s the entrepreneurial stance—an openness to try, fail, and adapt quickly. Loh encourages constant questioning and self-critique, a habit that prevents complacency in the face of AI’s rapid progress.

For product managers, that translates into running small experiments, engaging with real users, and resisting the comfort of static roadmaps.

Takeaways for Product Leaders

• Lead with empathy: Prioritize understanding over efficiency when shaping products.
• Question everything: Treat AI outputs as inputs, not truths.
• Experiment constantly: Build resilience by testing ideas in the market, not just in the lab.

---

What AI Does Well vs. What Humans Do Uniquely Well

AI Strengths	Human Strengths
Processing large data sets	Empathy and care for others
Pattern recognition	Critical thinking and questioning assumptions
Automating repetitive tasks	Creativity tied to human meaning
Generating content at scale	Building trust and delight in products
Speed and efficiency	Entrepreneurial experimentation and judgment

---

The lesson is clear. Success in the AI era isn’t about out-thinking the machine. It’s about leaning into the one trait it cannot replicate: the ability to care about people.

In my recent post on build vs buy in the age of vibe-coding, I argued that the classic binary is breaking down. Thanks to generative AI tools, teams now face a third option: AI-build. Instead of waiting for engineering capacity or relying entirely on vendors, product managers can prototype, test, and even wire together solutions themselves using natural language.

Marty Cagan just published a piece on build vs buy in the age of AI. He frames the same shift as user programming, rather than vibe-coding. The intent remains the same, though. Across the product world, practitioners are noticing the same tectonic shift. AI is turning what once required a software team into something accessible to anyone with intent and a clear prompt.

The rise of AI-build

Cagan makes the case that this new “user programming” is not just about speed of delivery. It is about changing the decision framework. For SaaS vendors, that means the competition is no longer just about feature breadth. As I argued in my earlier piece, SaaS products are under pressure to deliver leverage for vibe-coders, making their services easier to extend and customize through AI rather than waiting on roadmaps.

This is why AI-build deserves to stand alongside build and buy. It is a legitimate option for teams, not just a stopgap. When the problem is clear and the scope is well-bounded, vibe-coding can deliver faster insights and working prototypes than either traditional path.

The business rules challenge

Where Cagan is particularly insightful is in highlighting business rules as a natural limit to vibe-coding:

“The hard part is not the code, the hard part is the business rules. The real complexity in most systems is not in the algorithms but in the countless rules that govern pricing, entitlements, workflows, and compliance. This is why user programming has its limits.”

A product may have hundreds of subtle rules about pricing, entitlements, compliance, or workflows that aren’t written down in one place. Encoding and maintaining those rules is where complexity lives. A quick AI-generated script might deliver a prototype, but if it fails to respect business rules, it won’t survive in production.

This is a critical point—and one worth keeping an open mind about. My experience is that vibe-coding is powerful at the edges: testing ideas, automating simple flows, stitching together services. But it is less effective when deep institutional logic is required. At least for now, business rules remain the province of careful design, documentation, and human oversight.

Still, I wonder if this limit will shift. Already, research into AI-assisted orchestration and validation points to ways that large language models can help discover, codify, and even enforce business rules. It may be premature to assume AI will always be confined to the surface layer.

The product discovery is still the lynchpin

Cagan emphasizes that “the hard part is discovering the right solution to build, not coding it once you know what it is.”

AI will generate functioning code almost effortlessly, but unless the product team has already done the work of discovery, those outputs risk being clever detours rather than meaningful solutions. Delivery has been radically accelerated, but discovery remains the bottleneck.

Closing thought

Build vs buy is no longer binary. The third option, AI-build, is here. But the debate about business rules raises an important caution: vibe-coding may give us the freedom to build quickly, yet it also reminds us that the hardest part of software is not writing code but capturing the messy logic of the real world. Whether AI can help us bridge that gap is still an open question—and one worth exploring with both optimism and skepticism.

In a recent Every article, Dan Shipper highlights people who replaced expensive SaaS tools with AI-built alternatives. The stories aren’t just about cost-cutting. They show how quickly software creation is becoming accessible to people who never considered themselves builders.

This is still early days. Vibe-coding — natural language prompting to generate working tools — is in the first phase of its maturity curve. It often takes a few iterations to get things right, as Shipper’s examples show, but the return on investment is already strong.

I’ve seen it firsthand, vibe-coded this blog with Claude Code, among other projects. What once felt like “real development” is now as approachable as writing instructions to a teammate.

The upside: empowering non-technical builders

For product managers, operations leaders, or team leads, AI-generated tooling already unlocks new independence. Internal automations that might have sat in an engineering backlog can now be prototyped over a weekend. The process isn’t always smooth, but the ability to iterate quickly makes experimentation worthwhile.

This democratization of software creation expands what’s possible inside organizations. Small teams can act like they have an engineering wing. Ideas move from concept to usable prototype in days instead of quarters.

The downside: disruption for SaaS vendors

The same shift creates risk for SaaS companies. Many tools exist primarily to orchestrate workflows, manage data, or wrap a user interface around simple operations. If AI can reproduce that functionality on demand, customers may question why they’re paying $30 per seat per month.

This doesn’t mean SaaS is disappearing, but it does raise the bar for differentiation. Vendors can’t rely on features alone. The moats that will matter are:

Still Defensible	Vulnerable to AI-Build
Deep integrations	CRUD apps (create, read, update, delete)
Network effects (marketplaces, data sharing)	Simple workflow orchestration
Brand trust + compliance	Single-feature utilities
UX polish + scale reliability	Internal-facing dashboards/tools
Data network advantages	Niche automations

The takeaway for product managers

For builders, the question isn’t only “should we build or buy?” It’s now “should we AI-build?” That third option changes how teams weigh cost, flexibility, and speed.

For SaaS leaders, it’s worth assuming some of your customers are already experimenting with AI-built substitutes. The challenge is to deliver leverage that vibe-coding cannot. Focus on platforms rather than the point solutions.

Conclusion

AI-driven vibe-coding is still early in its maturity curve, but the contours are already visible. It empowers non-technical builders today, while quietly pressuring SaaS vendors to rethink tomorrow. The future of SaaS may not be about providing software alone, but about providing the scale, polish, and leverage that AI-built tools may not replicate.

When we think about product adoption, the focus usually falls on the end user. Product managers map user needs with frameworks like jobs-to-be-done (JTBD), ensuring the product fits a real workflow. But in B2B, adoption doesn't always equal purchase. Deals often hinge on an informal buying committee — a shifting group of individuals who influence or approve decisions, even if they never use the product directly.

This isn’t a boardroom-style committee. It’s a loose network of roles that naturally forms around a purchase: the user who advocates, the technologist who evaluates feasibility, the security lead who vets risk, the finance partner who manages cost. Ignore them, and even the best user experience may never see scale.

Jobs to Be Done Beyond the User

JTBD applies here too. Each member of this informal committee has their own “job” in the decision:

• End User: Get the job done more efficiently or effectively.
• Technologist: Ensure the product integrates cleanly with existing systems and doesn’t add unnecessary complexity. This is especially critical with APIs, developer platforms, or middleware where integration risk is high.
• IT/Security: Protect the organization’s data, ensure compliance, and manage operational risk.
• Finance: Control budget, reduce cost unpredictability, and avoid unplanned long-term lock-in.
• Legal/Procurement: Minimize exposure and standardize contracts.

Each role brings a different definition of success. Together, they form the real decision-making environment.

Why It Matters: The Case of API Adoption

Consider APIs and developer-focused products. Developers may love a tool for its speed or flexibility, but they rarely purchase based on enthusiasm alone. Technical architects and platform teams often step in as the evaluators. Their “job” is to protect long-term maintainability and ensure integrations won’t break under scale. Without satisfying that committee, a product risks remaining in pilot purgatory — tested but never rolled out.

Gartner research on B2B buying groups shows that enterprise decisions typically involve six to ten stakeholders, many with veto power. That’s the informal committee at work.

The Product Manager’s Takeaway

It’s not enough to solve the end user’s job. To win in B2B, product managers must anticipate the informal buying committee and their jobs as well:

• Map the committee early. In discovery, ask who else needs to sign off or influence the decision.
• Frame outcomes for each role. Translate product value into the language of risk, cost, and integration as much as user efficiency.
• Enable champions. Give end users the narratives and artifacts they need to persuade their own internal committee.

Products succeed when they work for users. Businesses succeed when they also work for the informal committees shaping the path to purchase.