We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Your next user may be an agent
Executives at Cisco and Vercel made the same argument from different directions: products now have to work for agents, not just people.
Vercel's COO put it bluntly. "Agents don't live in UIs. They call APIs. they hit MCP servers." A product that isn't composable and open to developers is "invisible to agentic workflows" . His advice is to build developer surfaces now: MCP servers, webhooks and APIs . He also said agents built without a structured, queryable model of the business "hallucinate or give generic answers" .
Vercel's own build process is worth borrowing:
- A GTM engineer shadowed a top SDR and turned each tool she used into a workflow step before any AI was involved .
- The agent then ran in shadow mode for six weeks. The SDR reviewed every output until she couldn't improve it .
- The lead-qualification agent costs under $5,000 a year plus about 20% of one engineer's time .
- Every quarter, the team checks whether a vendor has built something better, faster or cheaper .
Cisco's Jeetu Patel (President & CPO) said Cisco just launched a personal concierge agent that brands can give every customer, not just the top 20 or 100 accounts that get named reps . He also explained the shift that set this up. After 250 acquisitions, Cisco worked like a holding company and has now become a platform company. "We don't have any product managers at Cisco. We have feature managers," building features for the platform . Two more lessons from him:
- A second product that doesn't use the first product's route to market will fail .
- When a market looks important, Cisco now asks "what are we going to build" instead of "what are we going to buy" .
On judgment, Patel said: "what you choose not to build is far more important than what you choose to build," and that choice takes taste and an instinctive grasp of the market and customers .
There's a trust problem underneath all this. In a16z's review of about 3,600 messages from AI power-user group chats, trust was the top fear, raised in 22% of them . Their suggested design pattern: scoped permissions and monitoring, with the agent doing the groundwork and the user approving the final decision and its cost .
Connecting discovery to delivery
On Mind the Product, Jenny Martin explained Oopsie, a framework with five layers: outcomes, outputs, process, scenarios and inputs . The idea is to do enough thinking to build the right thing without falling into waterfall-style analysis paralysis .
- Outcomes. An outcome is a real-world change that creates value, usually for a customer. "A number on a spreadsheet is not the outcome" .
- Outputs. Each layer is a chance to prioritize. She estimates that about 20% of possible outputs deliver about 80% of the value .
- AI features. Non-deterministic behavior needs evals with ranges and scoring. Deterministic results need exact expected answers .
Her example: she once showed a retail customer the exact test data the team planned to use. The customer spotted a fundamental wrong assumption, which saved an estimated three or four months of work .
Funding strategy, not projects
Evan Campbell (One Knight in Product) said the most common way OKR programs fail is tying them to rewards, because people then sandbag their objectives . His portfolio approach:
- Rank cost-cutting work by NPV or IRR, but judge innovation only against strategic objectives. "There is no ROI" calculation for that work .
- Set aside a share of investment, such as 10%, for innovation so it doesn't get starved .
- Fund work in stages, and "trim the tail" once another quarter of investment would return less than a new idea would .
Cheap copying and the SaaS question
Casey Winters argues that AI makes copying so cheap that competitors "copy first and find out later." Copying is becoming a better tactic, he says, but not necessarily a better strategy .
On r/ProductManagement, a claim that one CEO used Claude to replace 9 SaaS vendors and raise margins 25% drew pushback. One reply said he built 9 good-enough internal tools, not 9 products, and now has to maintain them . Another said vendors take on risk for compliance, security and support .
Hiten Shah offered a more modest opportunity. Coding agents make the "unwritten backlog" of changes people stopped requesting worth revisiting .
Where AI costs PMs time
A widely discussed thread listed the costs:
- Slop docs. A 20-page AI-written requirements doc where a paragraph would do .
- Surprise errors. Claude helps one PM 95% of the time, but random hallucinations cut the net gain to about 50% .
- Hard-to-trace PRDs. Generated PRDs make it hard to tell where KPIs came from .
- Always-on recording. AI recording every call and Slack message makes search easy, but leaves a record of everything anyone says .
Status reports you can't trust
For a PM whose dev team keeps reporting false progress, the most practical replies:
- Require a working demo on shared staging by day 7 of the sprint.
- Log committed date, delivered date and first-try acceptance-criteria pass rate, then bring three sprints of trend data to whoever owns delivery .
Several commenters said accountability for estimates and delivery belongs with the engineering manager .
Also
Conductor, the AI coding app, is joining Meta to build "the next interface" with Meta Superintelligence Labs (MSL) .
- Jenny Martin’s Oopsie framework connects discovery and delivery by aligning product, design, and engineering around purpose and customer outcomes, rather than building without knowing why. It aims to balance enough thinking and collaboration to build the right thing against analysis paralysis, and can be used from large initiatives or portfolios down to backlog-level story splitting.
- Its five lenses are outcomes, outputs, process, scenarios, and inputs. An outcome is a meaningful real-world change that creates value, typically for an internal or external customer—not a business KPI by itself. Outputs are important results observable in the product or system; processes are the interactions that generate them. Scenarios make expected behavior concrete for testing, while inputs specify realistic test data and preconditions.
- Prioritize at each layer: Martin’s rough heuristic is that about 20% of potential outputs may deliver 80% of the value, and uncertain new work should start with a small number of important outputs. For AI products, she distinguishes qualitative or non-deterministic behavior, which needs evaluation ranges and scoring, from deterministic behavior with an exact expected result; teams can combine these approaches. In one example, reviewing concrete test data with a retail customer exposed a fundamental unavailable-data assumption before development, potentially avoiding three or four months of wasted work.
- For product planning, separate outcomes from controllable inputs: Eyal contrasts uncertain book sales with the controllable action of writing for an hour each day, and recommends focusing on what is within one’s control. Product teams can apply this by pairing market outcomes with execution goals they can directly influence.
- For behavior-change design, rehearse obstacles and intended responses rather than only picturing the desired end state: Eyal describes athletes mentally practicing what they will do when things go wrong and calls anticipating a tempting situation “mental contrasting.”
- Treat assumptions as revisable hypotheses: Eyal defines beliefs as convictions open to revision based on evidence and recommends using small steps to gather evidence that may change them. Product teams can apply this by testing assumptions instead of treating them as facts.
- Cisco described shifting from a holding company built through 250 acquisitions to a platform company: product teams prioritize features that strengthen the platform rather than standalone products. Multi-product expansion should reuse established go-to-market routes and buyer access; a large sales force cannot sell effectively to buyers it does not reach.
- Cisco says it has dialed down acquisitions and starts with “what are we going to build?”; acquisitions are selective accelerators of a defined end-state vision, not the strategy itself. Most acquired brands are integrated into the platform, while founders are given broader company-scale missions.
- In AI-era product work, product managers should use agents to amplify thinking rather than delegate judgment: deciding what not to build requires taste and understanding of markets and customers. Product management should operate in founder mode across functions—including sales, marketing, engineering, pricing, packaging and finance—and use AI without sacrificing originality.
- When consumers delegate to agents, retailers may lose some influence over upsell and cross-sell, while the agent becomes an intermediary between brand and customer. Cisco said it had launched a personal concierge agent for every brand, intended to extend support, sales and consulting to every customer rather than only customers who can be served by named account reps.
- Design for agent workflows: Provide headless, composable developer surfaces such as APIs, webhooks, and MCP servers; agents call these rather than use UIs, so products without them risk being excluded from agentic workflows.
- Treat data quality as a product dependency: A structured, queryable business representation and semantic layer ground agent answers and actions; without them, agents may produce hallucinated or generic results.
- Productize workflows before automating them: Pair engineers and data scientists with subject-matter experts to document best practice and encode the workflow; run the agent in shadow mode with human review, then reduce oversight as feedback declines.
- Reassess build-versus-buy and plan for scale: Compare whether an internal team can deliver an outcome better, faster, or cheaper than a vendor, and revisit that decision regularly. Agent workloads can expose unexpected infrastructure and cost problems at much higher usage because long-running execution and tool calls differ from conventional request-response workloads.
Lenny launched a physical, perfect-bound edition of his newsletter featuring eight hand-picked posts, with the buyer’s name on the cover; the first edition focuses on work and careers in the age of AI. He says he is not making money from the sale and wants to see how people like it, framing the release as a test of audience reception for the format.
- A PM reports that Claude saves 10× time on some cross-functional tasks and estimates a 50% average effectiveness gain, but says occasional hallucinations can make individual tasks slower than doing them unaided. Another PM describes data agents repeating prior-day results, missing event tags, and producing inconsistent cross-team data, while PRD generation can hallucinate and obscure where requirements or KPIs came from; they conclude human review is necessary.
- AI-generated requirements can shift work into review: one PM says a 20-page document required comparing generated content with face-to-face discussions and separating current requirements from end-state wishes. A commenter reports getting a strong first draft of a test plan by providing a known-good template, explicit format and conciseness expectations, and a speech-to-text description of the test.
- A PM says AI search across internal and external calls, email, and Slack helps retrieve past statements and draft replies, but also makes remarks broadly accessible to the “right” people—a productivity and privacy trade-off.
Conductor is joining Meta, where its team says it has plans for the “next interface” and will work with Meta’s MSL. Hiten Shah said he recommended Conductor to people who had never opened an IDE, calling that the highest compliment he could give; his endorsement highlights the product’s appeal beyond experienced IDE users.
- For unreliable sprint reporting, replace verbal status with inspectable work: review work in progress before sprint-end and require a running demo on shared staging around day 3–7; one commenter also recommends tracking committed versus delivered dates and first-pass acceptance-criteria completion, then using a three-sprint trend to escalate.
- Make “done” explicit: define it as acceptance criteria met, code merged, and developer-tested; surface unclear requirements early rather than at week four, and use retrospectives to review late-raised ambiguity and delivery problems.
- Keep estimates with the people doing the work and delivery accountability with engineering management; the PO can challenge estimates against comparable past work. If that accountability is absent, document commitments and misses, then escalate with evidence of business impact.
An early SaaS effort had hundreds of signups but users struggled with setup; the new PM said support tickets echoed the usability problems, while the team blamed users.
- To surface onboarding friction without making findings feel like a verdict on the team, ask the lead where they expect users to struggle, observe 1–2 real signups completing setup on a screen-share while thinking aloud, ask what surprised the lead, then bring in activation and funnel data.
- Pair funnel analysis—tracking how many users reach the intended outcome—with prioritized, testable fixes; evaluate them with a targeted user group or a randomized A/B test.
- One suggested prioritization method is to have users rank a predefined list of ten pain points, aggregate the rank scores, and treat the lowest total as the most painful problem.
- A senior PM commenter advises understanding team and leadership incentives first, aligning output with manager goals, and then earning room to improve user outcomes; another recommends building the executive relationship and maintaining regular customer discovery.
A mock bank-lending case uses portfolio segmentation to avoid an all-or-nothing product decision: $32B (80%) was in traded-asset funds, where recovery was easier, while the higher-risk direct-lender segment held $8B (20%). On that $8B segment, the case estimates annual losses of $160M at a 4% default rate and 50% recovery, versus $20M at a 0.5% default rate; it gives $24M as annual income, while noting that the profit comparison depends on whether that income already includes losses. The case recommends targeting the concentrated, higher-risk exposure rather than exiting the whole business: stop lending to the largest concentrated customer when possible, review the rest of the direct-lender book, and continue the lower-risk segment. Suggested controls include counterparty reporting on borrower and sector concentrations, drawdown-triggered reviews, exposure caps, and risk-based pricing; internal review triggers were described as quicker to implement than changes requiring counterparties to provide more transparency.
- A commenter claimed a medium-sized hardware firm used Claude to replace nine SaaS vendors and increase margins by 25%; a reply disputed the framing, saying the company built limited internal tools for features it needed—not nine enterprise-grade products—and must still operate and maintain them.
- The build-versus-buy tradeoff includes vendor-provided responsibility for compliance, security, performance, infrastructure, ongoing support, and enhancements; another commenter nevertheless sees a disruption opportunity in cheaper, good-enough products that provide only the few features customers use.
In a poll of 558 people asked which coding agent they’d keep, nearly two-thirds chose Claude Code; Hiten Shah notes that the question assumes prior experience, and is offering a beginner-focused session on getting started with coding agents and judging their output .
- Trust and control: In roughly 3,600 messages from AI power-user group chats, 22% identified trust as the main fear; one example was a personal agent exposing its user's finances in company Slack. Product design should use scoped permissions and monitoring, with the agent doing the groundwork while users retain approval over consequential actions and their costs.
- Preference-aware UX: Agent tests showed different ways of balancing same-day flower delivery against price, and of interpreting a “luxurious, cost-efficient” trip; the speakers emphasized eliciting implicit preferences and surfacing tradeoffs. A consumer-product speaker also warned against paternalism: some users may value fun or aspirational outcomes over productivity-oriented optimization.
- Make context portable: In a survey of 354 AI power users, 3% used Dots as their primary agent, while respondents valued its accumulated ChatGPT context; in a test of the top 15 agents, all but one would provide a memory file for switching.
- Reliability still differentiates: Some agents' performance degrades as they scale to hundreds of thousands of users, with founders dealing with outages, creating visible product-performance differences despite claims that software is becoming a commodity.
Casey Winters argues that AI has made copying cheap enough for competitors to copy products before validating that they work; copying may be a better tactic without being a better strategy, raising the question of what creates defensibility when products are easy to replicate.
- Prioritize problems users genuinely care about over vanity metrics, technical novelty, or what people merely say they would pay for; focus on a meaningful customer problem and iterate toward product–market fit rather than spreading effort across ideas.
- Validate continuously with the people who have the problem and test willingness to pay before investing heavily: at Focal, three months spent building retail people-tracking models produced data stores said offered no value and would not pay for; the speaker advises AI startups to start with a human in the loop before scaling compute.
- Make decisions before you have all the information—roughly 70% of what you wish you had—and favor shipping speed over waiting for certainty or technical perfection.
Coding agents are making it possible for product managers and other non-coders to try more of their ideas themselves; Hiten Shah’s “Coding Agents 101” teaches how to assign an agent a task and judge its result.
Peter Yang built a free AI skill to help families navigate medical information and prepare for decisions during cancer care; Hiten Shah highlights it as a meaningful AI use and notes it is available to anyone who needs it.
- Full-price renewals show that some customers see value, but do not by themselves establish broader demand. Map where stalled opportunities drop and check for qualification barriers: one B2B buyer reports that vendor review requires SOC 2, SSO, a signed DPA, and two similarly sized reference customers, which can block a champion and come across as “too small.”
- To sharpen the ICP, ask renewing customers what was happening immediately before they signed and what they used before—and why they stopped using it. Compare their purchase triggers with those of similar prospects rather than relying only on firmographics.
- One commenter proposes a predefined validation test: speak with 20 lookalikes of renewing customers over 30 days, and treat no one advancing beyond a small paid pilot as decision evidence. Another suggests using feature-level usage alongside company details and meeting notes to refine the next ICP and pitch.
Typeahead AI offers 15 free, no-account tools for discrete writing tasks, framing them as a simpler option than using a chatbot for every problem; examples include sentence rewording, grammar checking, and detecting made-up sources.
Companies may have an unwritten backlog of software changes that people stopped requesting after engineering priorities displaced them; coding agents make that backlog worth revisiting.
r/ProductManagement comment by u/Naive_Age_4320
In no particular order these are my thoughts (from someone who has spent 25 years in software engineering, background QA and SM).
Do you have a DoD? I’m only mentioning this because it would be a great idea to give the team a common understanding of the standard of deliverables you expect from them.
When they say ‘build failed but it looks good’- my answer is always, ‘if you can’t deploy it, you might as well not have built it at all. If it ain’t deployable, it cannot be considered to have been built or finished.
Daily Stand Ups would catch this kind of BS (the BS I’m referring to is them saying the requirements are/were unclear on week 4, whilst not bringing this up at any point before then). I would expect a Dev to bring up this ‘unclearness’ a couple of days into the development work. Not 4 weeks later. Implement Daily Stand Ups from now on.
What kind of estimation method do they use for the User Stories? In any given Sprint, on average, how many US’s do you consider to be ‘of a Production standard’ at the end of every Sprint? How many Devs do you work with?
QA - they can be as bold as to say to the devs - ‘we won’t test your work until you’ve Unit Tested it and there have no zero issues with the commits/build/deployment. Considering the (same) build will need to be deployed to higher environments, it’s crucial these kind of issues are ironed out before a PROD deployment. Even created specific AC for these tasks is a good idea.
When the build get deployed on the environment where QA test, why can’t you start testing then, at the same time as then? That’s normally what happens. You can then see for yourself how good the quality is, without relying on these cowboys.
The Retro should bring up the point about ‘unclear requirements’ as being from your side unacceptable (in the point that it’s brought up far too late).
I take it you don’t have a Scrum Master?
Yes, one of the first things I did was write a DoD. It
Included things like (shorthand);
-Complete means that an item follows acceptance criteria, is merged into the codebase, and has been tested by the developer.
-An item must pass tests before being completedIt’s been a major struggle, but the team really doesn’t like merging their code. They say there’s to many merge conflicts so they prefer to just keep work on their local. The Eng lead says that the product owner needs to do the work to update the code so that everything merges in correctly.
We quit daily standup. The devs told me that the meetings “threw off their rhythm”, and I had to accept that I was losing \~30% of the day by stressing them out with this meetings.
We have 7 devs. I slice stories aggressively, but we still only typically finish anywhere from 1 to 3 stories. For example, it took 3 devs 1.5 weeks to fix capitalization on one tooltip in the app. And yes, we are critically behind all stakeholder deadlines….
The devs estimate down to 15 minute increments. They are typically 1,000%+ underestimating Stories. I asked them to use a fibbonacci and estimate as a group, so they got and and told me to do estimates myself from now on.
QA doesn’t understand how the product works and just rubber stamps everything.
Per above…they won’t merge their code. I try to get them on calls so I can look at their local, but they say that stresses them out and they are unproductive for days afterwards. They also always say their local is down, “it was working 5 minutes ago”, etc.
Devs said that it is unsafe for them to bring up requirements aren’t clear. They said “PO writes requirements”, and that it will blur the clear line of blame to the PO if they express feedback about the requirements because that involves them in the process.
We do have a scrum master. They just agree with the devs and blame me for everything.
- For unreliable sprint reporting, replace verbal status with inspectable work: review work in progress before sprint-end and require a running demo on shared staging around day 3–7; one commenter also recommends tracking committed versus delivered dates and first-pass acceptance-criteria completion, then using a three-sprint trend to escalate.
- Make “done” explicit: define it as acceptance criteria met, code merged, and developer-tested; surface unclear requirements early rather than at week four, and use retrospectives to review late-raised ambiguity and delivery problems.
- Keep estimates with the people doing the work and delivery accountability with engineering management; the PO can challenge estimates against comparable past work. If that accountability is absent, document commitments and misses, then escalate with evidence of business impact.