Read 50 of the best product management tweets on roadmaps, prioritization, product strategy, customer research, and working with engineers.
Roadmaps, tradeoffs, and the PM takes engineers either love or fight about.
Original Xholic analysis
Across 50 posts from 44 creators on product management, sentiment runs overwhelmingly positive (90%) and uniformly supportive (100%). The dominant theme—22% of the conversation—is AI's disruption and redefinition of the PM role. The top outliers mix that AI debate with broader PM craft: tfadell's argument that product management and product marketing should be one job (408.48 allTimeScore, 62.27x median) and lennysan's interview with a non-technical Meta PM shipping real product with Cursor and Claude Code (199.89, 30.47x). PREDICTION posts carry a high median allTimeScore (187.6 vs 4.45 for LIST and 8.5 for OPINION), though only 2 prediction posts exist in this dataset. Roadmap skepticism (
90% of posts
All-time engagement
48% of posts
Published in 90 days
Conversation map
Debates over whether PMs are dying, expanding, or converging with engineering/design into 'builder' roles; AI fluency plus taste as the differentiator; forward-deployed AI PMs; PMs learning to ship with AI tools.
22%
Talking to users daily, first-10-users-as-product, immersion in raw feedback over AI summaries, power users and MCP users as research cohorts, customers owning the post-PMF roadmap.
14%
Frameworks like MoSCoW and RICE; deciding what NOT to build; evidence- and revenue-linked prioritization; constraints as core product strategy; JTBD over feature requests.
14%
PMs building real MVPs with Cursor/Claude Code, no-handoff ship cultures, research previews, forward-deployed teams, automated demo-to-PR pipelines, closing the idea-to-validation gap.
14%
Evals replacing PRDs as the key artifact, guardrails and quality definitions, agent-native SaaS design, UX for personal agents, bottom-up strategy under unknown-unknowns.
10%
Stakeholder alignment, influence without authority, firefighting, emotional labor, re-explaining strategy, navigating dysfunction — the 80% of the job AI can't automate.
10%
Defining what should exist vs. how to build it; practical reasoning constrained by morality; intuition built from immersion; problem definition as the new bottleneck when execution is cheap.
8%
Skeptical takes on roadmaps as rigid scripts or contracts; planning loosely, adjusting in public, embracing chaos, and abandoning prediction in fast-moving AI markets.
8%
Tone and stance
Performance benchmark
Posts with media make up 32% of this collection. Their median all-time score is 24.5, compared with 4.39 for text-only posts.
Format mix
Consensus and debate
Shared view
Multiple high-scoring posts converge on the idea that the gap between idea and shipped product is closing for PMs: a non-technical Meta PM building significant product with Cursor and Claude Code, a PM arguing 'the fastest way to get better at product is no longer writing better PRDs,' and posts on no-handoff ship cultures and demo-to-PR automation pipelines.
Shared view
A recurring argument across posts: talking to users directly—daily conversations, reading raw feedback line by line, treating MCP power users as a research cohort, or letting customers own the post-PMF roadmap—outperforms roadmaps built from summaries and board meetings.
Open debate
Not everyone accepts the convergence narrative. Marc Andreessen (via a16z) predicts the three roles collapse into a 'builder' job because each can now do all three; kevinyien counters that the old role boundaries were wrong to begin with and roles are simultaneously expanding and deepening rather than merging into neat new buckets. quxiaoyin frames the related open question of whether 'builder PMs' or engineers will
What performs
32% of posts include media, and they carry a median allTimeScore of 24.5 versus 4.39 for text-only posts—roughly 5.6x. In a feed where the overall median allTimeScore is 6.56, pairing takes with visual assets appears strongly associated with performance.
The AI-role theme has a median allTimeScore of 13.257 and the AI-product-practices theme 36.557, while roadmap skepticism sits at a median of just 1.46 and prioritization/saying-no at 3.417. Argument-heavy AI-transition content is pulling the engagement in this dataset.
Statistical standouts
Creator landscape
The five most represented creators account for 20% of the selected posts.
1. Bandan (Productify)
@bandanjot
2 posts
2. JustAnotherPM | Sid
@JustAnotherPM
2 posts
3. George from 🕹prodmgmt.world
@nurijanian
2 posts
4. Sachin Rekhi
@sachinrekhi
2 posts
5. Sergio Pereira
@SergioRocks
2 posts
6. staysaasy
@staysaasy
2 posts
PREDICTION posts carry a median allTimeScore of 187.6 versus 8.5 for OPINION and 4.45 for LIST. Both predictions—a16z sharing Marc Andreessen's 'builder' role forecast (2077151270444646899, 175.31) and lennysan's interview with a non-technical Meta PM building real product with AI (2012969223392546947, 199.89)—sit in the top five outliers. Caveat: only 2 of 50 posts are PREDICTION format, so the sample is tiny; the
tfadell's post (2040136671476473912) scored 408.48—62.27x the median allTimeScore of 6.56—arguing product management and product marketing must be one job, anchored in Greg Joswiak's customer-empathy approach at Apple. It outscored every other post in the dataset, including the leading AI-role posts (199.89 and 175.31), suggesting an authoritative, practitioner-grounded take on core PM craft can cut through even an
The five outliers—2040136671476473912 (408.48), 2012969223392546947 (199.89), 2077151270444646899 (175.31), 2046273217472713086 (165.35), and 2040197363122491888 (115.63)—are all multiples of 17x or more above the 6.56 median. Four of the five concern AI reshaping the PM role: builders converging from PM/engineering/design, non-technical PMs shipping with AI tools, DHH admitting in an interview that he'd historically
Since the previous snapshot
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Product Management tweets
Ranked 01–50
@tfadell ·
Most tech companies break out product management and product marketing into two separate roles: Product management defines the product and gets it built. Product marketing wires the messaging- the facts you want to communicate to customers- and gets the product sold. But from my experience that's a grievous mistake. Those are, and should aways be, one job. There should be no separation between what the product will be and how it will be explained- the story has to be utterly cohesive from the beginning. Your messaging is your product. The story you're telling shapes the thing you're making. I learned story telling from Steve Jobs. I learned product management from Greg Joswiak. Joz, a fellow Wolverine, Michigander, and overall great person, has been at Apple since he left Ann Arbor in 1986 and has run product marketing for decades. And his superpower- the superpower of every truly great product manager- is empathy. He doesn't just understand the customer. He becomes the customer. So when Joz stepped into the world with his next-gen iPod to test it out, he fiddled with it like a beginner. He set aside all the tech specs- except one: battery life. The numbers were empty without customers, the facts meaningless without context. And, that's why product management has to own the messaging. The spec shows the features, the details of how a product will work, but the messaging predicts people's concerns and finds way to mitigate them. - #BUILD Chapter 5.5 The Point of PMs
@lennysan ·
The future of product management looks a lot like @ArnovitzZevi Zevi is an IC PM at @Meta, has no technical background—is scared to even look at code—but has taught himself how to use Cursor and Claude Code to build significant and real product. He's developed his own very powerful Cursor workflow that allows him to quickly add his ideas to Linear, develop a plan using Claude Code, build it within Cursor, and then have different LLMs review his code. Zevi's engineers at Meta ask him to teach them how he does what he does, and I haven’t stopped thinking about this conversation since we had it. Everyone needs to pay close attention to what AI us unlocking for non-technical people. We discuss: 🔸 The complete AI workflow that lets non-technical people build in Cursor 🔸 How to use multiple AI models for different tasks (Claude for planning, Gemini for UI) 🔸Specific slash commands to automate key prompts 🔸 Zevi’s “peer review” technique, which uses different LLM models to review each other’s code 🔸 Why this might be the best time to be a junior in tech, despite the challenging job market 🔸 How Zevi used AI to prepare for his Meta PM interviews Listen now 👇 - YouTube: https://t.co/rhx8JZrtUW - Spotify: https://t.co/W2u86pedQb - Apple: https://t.co/0qaRCoB31j Thank you to our wonderful sponsors for supporting the podcast: 🏆 @10Web_io — Vibe coding platform as an API https://t.co/tTGMfTU3NN 🏆 @DeveloperXM — The developer intelligence platform designed by leading researchers https://t.co/INhXcJ685b 🏆 @Framer — Build better websites faster https://t.co/n8Nou13WpL
Watch video
@a16z ·
.@pmarca on the "three-way Mexican standoff" between coders, PMs, and designers: "I'm seeing it in a bunch of the early leading edge companies in the Valley, they're circling around a job title loosely called 'builder,' or something like it. And basically the idea is that you had these separate jobs in the past of programmer, product manager, and designer." " I've been describing what's happening in the Valley companies as sort of this three-way Mexican standoff, where the programmers think that they don't need the product managers and the designers anymore 'cause they can have AI do that, and then each of the other two doesn't think they need the other two either." "I've been predicting they're all correct. The product manager can generate code and design now, and each of them can do the job of all three. The idea is the jobs change so now the job is builder." @MTSlive
Watch video
@nurijanian ·
DHH spent 20 years dismissing product management. Then 1h21 into his Pragmatic Engineer interview, he caught himself and admitted he was wrong. He was listing what matters now that AI writes the code: figuring out what to build, how to build it, which customers to talk to, where to focus. Then his exact next words: "It's product management. It's so funny for me too because historically I've not necessarily had the highest esteem for product management as a function. I thought there was a lot of BS." He explained why. Implementation was always the constraint. Engineers needed four weeks to ship anything, so PMs spent those weeks talking, planning, strategizing. Nothing looked like output until the code landed. "They were underutilized. They were not the constraint." They were rate-limited. The loudest PM-skeptic changing his mind (and DHH has strong opinions!) -- that should count for something. let's toast to that 🥂
@JustAnotherPM ·
Product Managers, give me 6 minutes to make you understand: The true meaning of AI Product Sense In product management, problems are ambiguous, information is limited, 2+2 is not always 4. Hence, it’s hard to know the “right” answer Yet some PMs know the "right" thing to do, despite the ambiguity. And that is product sense: Ability to find the right solution for the users and the business, despite limited and ambiguous information. And fundamentally, the definition hasn’t changed (even with AI in the picture). But designing AI products adds a layer extra complexity which requires PMs to answer a few extra questions. Create/clarify the overall goal User Discovery Problem discovery Solution discovery (this is different with AI) Alignment with larger goals ---------------------------------- Building and delivering the solution Measure success and collect feedback Let’s talk about the added complexity that AI brings with it. Here are the questions you should be thinking about 1. Which layers do we need: determine what powers the heart of your solution. Is it data, model, UX, Product. Do this early on so you know exactly where to focus your energy on. 2. Define each layer’s job: for all practical reasons your product would use all of the above layers. So it’s important to define what each layer is responsible for and how you define success for each of them. This is imp because when your product breaks at scale, you’ll know exactly where to look. 3. Guardrails: most PMs are very good at defining what the product should do. But with AI, it’s important to also define what it shouldn’t do. You don’t want a customer service chat bot reveal trade secrets or offer full refunds to every customer. 4 and 5 Define good and bad quality: it’s critical to define what good quality looks like, create a golden set, run tests against an EVAL framework so you know how good or bad your product is doing. At the same time also think what bad quality looks like, so your model knows exactly what not to do. 6. Design how user experiences the product: what does the user do when she receives a good response? Does she end the session? Does she start a new session? Similarly, what does the user do when she receives a bad or inaccurate answer? Can she rerun the same query? Can she course correct? All of these are very imp questions to answer before you start building. 7. How will you collect feedback: will you use explicit signals like thumbs up? Or implicit signals like engagement, clicks, time spent? Whatever you choose, you need to know upfront so you design the solution to enable the right feedback loops. in a few hours I will break this down with a lot more details in my masterclass. We’re going to tear down perplexity as a product and understand how the PMs there answered these questions. session is free to attend, but seats are limited. See you there (sign up link in comments) date: 4th april time: 12pm BST / 430pm IST
@sriramk ·
we are seeing a come back of product management when it comes to the design and UX of personal agents. instinct / dot / muse / grok bot all have significant product work on tying together ux with model capabilities underneath and its access to various services. in all of these cases I rarely care about the underlying model but very much care about the big and little touches ( the muse activity notification, the little thumbs up emoji in Instinct to acknowledge a message and more). contrast this with the “upgrade to latest model” path we are otherwise on.
@nurijanian ·
I just read a PM's post about automating their workflows with AI, so let me share some takes: 1. You can automate documentation all you want. You'll still spend 3 hours a week explaining it to people who won't read it anyway. 2. The biggest time sink in product management isn't creating artifacts. It's convincing others your idea was actually their idea all along. 3. I've seen PMs automate their entire PRD process. They still spend 80% of their time in meetings where nobody references the PRD. 4. AI can write your user stories in seconds. Getting alignment on those stories will still take 4 meetings, 12 Slack threads, and one awkward hallway conversation. 5. Most PMs spend more time writing angry Slack messages and then deleting them than they spend on actual product strategy. This is the emotional labor nobody talks about. 6. Every PM job description mentions "data-driven decision making." In reality, you spend most of your time cleaning up decisions your predecessor made based on vibes and executive opinions. 7. The irony of AI automation tools for PMs: They optimize the 20% of your job that's already efficient. The other 80% - managing up, sideways, and down - remains stubbornly human. 8. You know what takes the most time? Re-explaining the same strategy to different stakeholders who all think they're hearing it for the first time. 9. I automated my entire data analysis workflow last year. Now I spend that saved time defending the data to people who don't like what it says. 10. The best PMs I know aren't great at creating artifacts. They're great at navigating organizational dysfunction without losing their minds. 11. Here's the pattern I see: Junior PMs obsess over perfecting their templates. Senior PMs obsess over reducing the number of meetings where those templates get ignored. 12. You want to know where PMs really spend time? Writing diplomatic versions of "this is a terrible idea" in 15 different ways until one lands. 13. AI can generate a roadmap in minutes. Getting everyone to stop trying to add their pet feature to it is a quarterly battle. 14. The cruel joke: By the time you've automated your PM workflows, you'll probably be promoted to a role where none of those automations matter anymore. 15. If AI could automate stakeholder alignment, that would be the real revolution. Instead, we're automating the creation of documents that prove alignment never existed. Product management is 20% building products and 80% managing the humans who make building products complicated.
@geoffintech ·
API usage through MCP/CLI has accelerated in the last months. This trend creates a paradox for PMs. Your product is getting more usage, but you understand less about how it's being used. API logs show you what was called, not what was built. That's a dangerous blind spot. The real threat isn't going headless — it's losing the feedback loop. Your power users are now building custom apps in Claude Code that you'll never see in your analytics dashboard. They're solving problems your product should have solved. The race isn't against Anthropic, it is against your own customers. They're already building the product they wish you had. Every day you don't talk to them, that gap widens. What does this mean: 1. Your MCP users are your most important research cohort right now — go talk to them 2. What they're building tells you what your product is missing. Build those capabilities natively, with the UX and reliability that a Claude Code hack can't match. This is your roadmap. 3. Ship it to the 90% of your users who will never touch an MCP and use your distribution to your advantage
@bhalligan ·
The product roadmap is getting replaced by direct customer input in the AI era. @jack on what changes when the product IS the conversation: "When your interface is a conversation with your customer, instead of this visual navigation, you suddenly get this amazing fidelity of, like, what do our customers actually care about?"
Watch video@JustAnotherPM ·
Product managers, if you want to keep your job in the next 12 months, read this. Bookmark it. Re-read every Monday. Here is what is happening on the ground: 8 out of 10 PMs I work with still treat the PRD as the most important artifact. It is not. The most important artifact for an AI PM is the eval set. A PRD is a set of intentions. An eval is the only proof that the model behaves the way the customer needs it to. Try this for one week: 𝟭. 𝗦𝘁𝗼𝗽 starting your AI feature with a PRD. Start with 10 example user inputs and the response you would accept from a human expert. 𝟮. 𝗧𝘂𝗿𝗻 those 10 examples into a graded test file before any prompt is written. 𝟯. 𝗥𝘂𝗻 the eval after every prompt change. Track pass rate. Track regressions. 𝟰. 𝗢𝗻𝗹𝘆 𝘁𝗵𝗲𝗻 write the PRD, with the eval pass-rate as the launch criterion. The PMs who do this ship faster, get fewer rollbacks, and become the person eng actually asks for input. The PMs who do not are slowly being moved off the AI roadmap.
@sachinrekhi ·
Question: Given that all PMs will eventually have access to the same AI tools, how do I differentiate myself as a product manager? I get this question a lot. And I don't love the shallow answer going around that "all that matters is taste." Taste is definitely important, but here's my far more concrete playbook for differentiating as a PM in the age of AI: 1. Stay at the frontier of AI fluency - I think too many people are dismissing this one saying that "everyone is going to have access to the same tools." But I'm a year and a half into this and I can tell you the gap is only widening on folks who can wield AI well in their job vs those that can't. And I don't see that changing anytime soon. So the people best positioned are the ones that know how to use AI effectively to produce great output, which is no easy task. 2. Taste / high standards / judgment - This is the one everyone talks about and I agree it's important. For example, I recently showed off 13 AI PM skills I built in Claude Code. What I didn't show was the 16 others that I tried to build but ultimately threw away because the output didn't meet my bar. I'm seeing lots of other people ship these skills and just accept the low quality output coming out of them. This is a mistake. The first battle is knowing what great product work looks like. The second battle is continuing to hold yourself to that standard. Don't ship slop. 3. Domain expertise - As the functional aspects of the role become more commoditized, I do think domain expertise in a given field becomes even more important. I don't think it's a fluke that a cardiologist beat experienced software developers in Anthropic's recent vibe coding contest. It's because his deep knowledge in the domain allowed him to come up with such a compelling solution to the post-visit patient problem that he deeply understood. Only a domain expert could do that. 4. Product strategy - AI is terrible at product strategy. I've tried every which way and it never comes up with a compelling, differentiated product strategy that has any chance of winning the market. I think that's going to be the case for awhile. So it's a great area to continue to build your muscle. 5. Design - The advancements coming out of Gemini, etc is impressive, but I still can't get AI to match the world-class designers I've worked with in my career. Especially on interaction design, not just visual design. Learning these skills is still valuable.
@kevinyien ·
The belief that EPD is collapsing into a single role called a “builder” is based on the incorrect assumption that product manager, engineer, and designer had the right boundaries to begin with. For example, many of the people with the title “designer” that I respected the most were already a combination of “product manager + product designer + frontend engineer”. Now they can do each aspect even better / more. But they are still a “designer” (at least imo). The same applies to product managers who can (and should) do more of the product marketing, selling, and growth work. Anyone looking for the new neat buckets to slot into will have a hard time over the next decade. The reality is that roles are simultaneously expanding and deepening (which many are ready for, or straight up don’t want to happen).
@danshipper ·
SaaS isn’t dead, it just needs to become agent-native. Linear (@linear) is a great example of how: They pivoted the product to be used by both humans and agents, and that has made them one of the premier software tools in the agent-native era. I had Linear’s cofounder and CEO @karrisaarinen on @every's AI & I to talk about how a product management tool for human software developers became an agent-native tool—and how Linear’s trajectory reveals a bright future for SaaS businesses: - Speed means decisions matter more, not less. AI makes it easy to have an idea and build it without considering whether its existence is justified. When ChatGPT was released, SaaS companies were launching their own chatbots left, right, and center. Instead of jumping on the bandwagon, Linear stopped to consider whether the application was useful. (It wasn’t.) - Just because the technology has changed doesn’t mean your mission should. Karri attributes Linear’s success to never losing sight of what matters: helping teams develop great software. Instead of chasing trends, Linear focused on understanding how AI was impacting its customers’ workflows—and updating its product accordingly. - Agents are now first-class users. Linear never tried to change what it was or did well; it just expanded the user base. Companies can now kick off agents inside Linear, manage them, and track what they're working on alongside the humans on the team, which explains why Codex, Coinbase, and Brex all run their agents on Linear. This is a must watch for anyone interested in how an agent-native SaaS company operates. Watch below! Timestamps: Introduction and how Every first discovered Linear: 00:00:39 Why Linear waited to ship AI features instead of rushing to chatbots: 00:02:00 Linear's agent platform and becoming the system that guides AI agents: 00:05:06 Why "SaaS is dead" is a simplistic narrative: 00:07:42 How Linear adopted AI coding tools internally: 00:12:18 AI's impact on product building workflows—speed versus thoughtfulness: 00:17:45 The value of conceptual work and thinking before shipping: 00:22:18 How AI is reshaping Linear's product strategy: 00:29:30 Demo: Linear's agent skills, shared context, and code review workflow: 00:37:18 The future of product development and the enduring role of human judgment: 00:47:48
Watch video
@jeff_weinstein ·
@kevinyien and I have been chatting re: the product manager's role — one thought: (1) make sure the team ships (2) decide to ship something "surprisingly great" or "not obviously bad" if "surprisingly great" = yay else, ensure "not obviously bad" to earn trust, then ship again
@santoshstack ·
Your product roadmap shouldn't only answer: What should we build next? It should also answer: What are we deliberately NOT building? Without the second question, every customer request becomes a potential commitment. Constraints are part of product strategy.
@PrajwalTomar_ ·
Before we build ANY MVP, we use the MoSCoW method to define scope. MoSCoW = Must have, Should have, Could have, Won't have. We categorize every feature: → Must have = Core features for phase 1 → Should have = Nice to have but not critical → Could have = Future roadmap → Won't have = Out of scope This simple framework gives us a clear feature list, a lean scope, and zero ambiguity. It's the difference between shipping in 3 weeks vs getting stuck for 6 months.
@iamKierraD ·
I wasn't planning to write an article about Forward-Deployed AI Product Managers. The more I watched companies like OpenAI, Anthropic, and other frontier AI organizations evolve, though, the more obvious it became that this wasn't simply another product management role. It represents a shift in what companies value. We're entering an era where building AI is becoming easier, but deciding what deserves to be built is becoming exponentially more valuable. That's why I wrote The Rise of the Forward-Deployed AI Product Manager. Yes, it's a practical guide for anyone interested in breaking into one of the most exciting roles in AI. I also wrote it because I think every technical professional can benefit from developing product sense. Whether you're an engineer, architect, consultant, founder, or product manager, your ability to understand customers, evaluate tradeoffs, communicate across disciplines, and build trustworthy AI systems is becoming a competitive advantage. The article explores why this role exists, the competencies companies are actually hiring for, and how AI is reshaping product management itself. For paid subscribers, I also included a roadmap for building those competencies intentionally—from customer discovery and governance to portfolio projects, rapid prototyping, and the artifacts that hiring managers increasingly expect to see. I hope it changes the way you think about building AI products as much as researching it changed the way I do. Link:https://t.co/qmSBZHk6wR
@staysaasy ·
So much of good product strategy is simply having the courage to invest more in what's obviously working, rather than working on whatever was promised to your boss' boss' boss' dog walker's roommate.
@staysaasy ·
Product management is better understood not as a role but as a bunch of related activities that are necessary for improving a mature product. 1% of these activities are awesome (telling people what to build) and 99% suck (everything else).
@rrhoover ·
When I was a junior product manager, I made the mistake of narrowly prescribing solutions to engineering. Similar dynamics exist working with AI. The smarter it gets, the more AI can fill in gaps and surface solutions you didn't think of. Specific prompts = limit solutions to your own ideas. Open-ended prompts = unlock novel solutions when properly contextualized.
@realBigBrainAI ·
Microsoft merged Product management, design, and engineering into a single "full-stack builder" role.
Watch video@sachinrekhi ·
THE KILLER PM COMBO: AI FLUENCY + HIGH STANDARDS I'm convinced that the best product managers today exhibit two qualities: AI FLUENCY They know all the AI tools and how to incorporate them into their product workflows, from strategy to customer research to data analysis to prototyping to validation to daily execution. They know the strengths of each AI tool, their limitations, and when to reach for each. HIGH STANDARDS However, simply knowing how to wield the tools doesn't actually prevent you from generating slop. It needs to be paired with high standards. That first requires strong product taste to know what great output actually looks like, whether it's a product strategy a product design or quality customer insights. It then requires actually holding yourself to that standard. And when AI output doesn't cut it, refining your process or scrapping it in favor of doing it the old fashioned way. Right now I'm seeing too many PMs that have one skill but not the other. Some folks are leveraging AI for absolutely every task, but generating slop along the way. Others are sticking to their deep understanding of the craft, but are getting burnt out failing to meet the new expectations of pace. Learning both becomes critical in this next era of product management.
@dharmeshba ·
We've built this notion that if a task is long and boring, only AI should do it. I keep hearing the same story from PMs: an intern automated their customer feedback pipeline. Tickets are summarized. Reviews are tagged. Insights get surfaced automatically. User research, they say, is now "simplified." Most product people already know their insights. We've seen the patterns. We know what customers complain about, what they request, what makes them churn. The data confirms what we suspect. The hard part was never knowing. The hard part is believing it enough to make uncomfortable decisions. That gut-level certainty doesn't come from merely dashboards or summaries. It comes from the slow, tedious process of reading customer words one line at a time. Hour after hour to internalize a worldview. Think about film. You can watch at 2x. You'll know the plot. But no filmmaker who respects the craft watches it that speed - because experiencing the story is the point. Customer feedback works the same way. The hours spent reading sales transcripts or customer conversations aren't overhead. They're training. You're teaching yourself to think in your customer's language, to feel their frustrations as your own, to hear their voice when you're debating a feature in a roadmap meeting. AI gives you the summary. Immersion gives you the intuition. And intuition is what lets you make the calls that summaries can't justify.
@elgermerlo ·
Your users write your roadmap. Spend 1-2 hours daily talking to customers; every single feature you'll ship comes from direct conversations, not board meetings.
@SinghDevHub ·
building product is becoming easy. how to distribute, what features to build, incremental changes to move matrics fast product management, design, generalist roles are winning in this market.
@TheMattBerman ·
I automated shipping features from demos with @openclaw 😱 here's the system that runs autonomously: step 1: capture feature requests from calls → someone DMs me for @StealAds access. we hop on a call → call transcript auto-sends to my @OpenClaw agent → agent checks the convo for feature requests, complaints, wishes → filters out the noise (questions, compliments, small talk) → outputs a clean ranked list of what people actually want built step 2: score + prioritize against my roadmap → does it fit my mission? → does it materially improve the path to the magic moment? → how many users would it affect? → how hard is it to build? → top request gets a full PRD auto-generated → PRD includes problem statement, proposed solution, edge cases, user stories, acceptance criteria → the scoring rubric is the whole game. without it you get a PRD for every random comment. step 3: auto-create the GitHub issue → PRD passes threshold → agent creates a GitHub issue with the full spec linked → tagged, labeled, assigned. ready for dev. → I didn't open GitHub. I didn't write a ticket. I was still on calls. step 4: build the feature with AI code review → @Openclaw spins up a @ClaudeCode harness with @every compound engineering plugin → reads the PRD, checks the codebase, writes the implementation → compound engineering runs a full review (style, architecture, edge cases) → @OpenAI Codex does a second review → two AI reviewers before I see it step 5: PR lands in my inbox ready to merge → both reviews pass → PR auto-created and assigned to me → I open it, scan the diff, test, approve, merge → the feature that was a sentence in a demo call is now in production input: 1 demo call output: production-ready PR. same day. dozens of hours of product management → 1 PR review here's how to build it 👇
@FintechKristen ·
Once you’ve got product market fit, your roadmap isn’t yours anymore. It belongs to your customers. They’ve chose you for a job and you have to make sure they keep choosing you. New jobs are ok too, but don’t forget what you were hired for.
@BigBrainBizness ·
Pavel Durov explains how Telegram scaled to a billion users with one product manager and zero HR staff: Pavel kept full ownership of Telegram and refuses to give up voting control. His reasoning comes down to one word: efficiency. "Having myself as the sole owner, director and product manager for this extensive period of time in the company's development allowed us to move faster." When asked how he could possibly still be the only product manager at a company of Telegram's scale, Pavel doesn't flinch: "I still come up with most of the features. I still work directly with every engineer, every designer who is implementing these features. I'm running this company because I enjoy it. I'm the only product manager because I think this is the way I can contribute." Then comes the more surprising admission. Asked how big his HR department is, @durov answers: "Zero. Well, you could say it's me." Instead of building a traditional HR function, Telegram decentralised hiring entirely. They built a separate platform, where they run engineering contests every month or two. "We select the best of the best engineers as a result of the competitions that we organise." The throughline of Pavel's approach is concentration over delegation. One owner. One product manager. No HR department. A hiring funnel that replaces recruiters with open competition. Most founders are told that scaling means letting go: hire managers, hire recruiters, dilute ownership, distribute product decisions. Pavel's bet is the opposite. Stay close to the product. Stay close to the engineers. Let the work itself filter who gets in.
Watch video
@rish_neynar ·
founders usually want to talk about the clever parts of the product. users notice the missing basics first. if search is buggy, onboarding is confusing, notifications don’t work the way they expect, or the app feels slow, they feel it immediately. they might not describe it well. they’ll just feel like the product is off. a surprising amount of roadmap work is closing those gaps. not very exciting externally, but without it the differentiated stuff doesn’t really matter.
@SergioRocks ·
AI is turning everyone into a Product Manager For years, we split teams into “thinkers” and “doers.” - PMs defines the problem - Engineers implemented the solution That model is outdated. Anthropic’s latest study shows the top aspiration people have with AI is not “do work for me.” It’s “help me do better work.” (18.8% - the largest category) That sounds subtle. It’s not. Because when execution becomes cheap, the bottleneck shifts: - Not to coding - Not to tools - Not to headcount To problem definition. We’re already seeing it: - Non-technical founders shipping MVPs - Engineers writing less code, making more decisions - Solo operators building what used to require teams AI compresses execution so aggressively that the only thing left that matters is: What to build, Why it matters, and What tradeoffs to make. That’s product thinking. So now everyone is being pushed into that role. And most people are not ready for it. Because defining the right problem is harder than solving it. AI didn’t eliminate the need for engineers. It eliminated the excuse of hiding behind implementation. Now the question is simple: - Are you good at deciding what should exist? - Or just good at building what you’re told? That distinction is becoming everything.
@rvivek ·
Anthropic's Head of Product on Claude Code explained why they ship faster than anyone else. And it's not the mythical Claude Mythos model. Here are 4 things they do differently: 1. No handoffs: An engineer sees user feedback on Twitter Monday morning. By end of week, the feature is live. No PM brief, design review, or a roadmap meeting. Cat Wu calls them "engineers with great product taste." 2. Everyone was an engineer first: Most designers were front-end engineers. Almost all PMs wrote code. Everyone makes product decisions and ships. 3. Evergreen launch room: When something is ready, the engineer drops it in Slack. Docs, PMM, and devrel turn around the announcement the next day. 4. Ship as research preview: Almost everything launches early with the "research preview" label. Users know it's not final. Feature cycles went from six months to one month to sometimes one day. Most companies still hire engineers, designers, and PMs as separate roles. At HackerRank, our designers already ship code. GTM is next. It's not just developers who need to level up. Everyone is becoming a builder who ships.
Watch video
@rseroter ·
Managing 8 engineers now feels like managing 4 teams https://t.co/NhNjB0YfJy < now product management is the bottleneck. You need rapid product thinking and thicker backlogs for engineering teams that iterate much faster than before. Some suggestions here.
@FunOfInvesting ·
After a decade in product management, here are a few principles I've picked up along the way: 1. Product management is firefighting. There's little praise during the quiet times and much criticism during the fires. Embrace this early and you'll save yourself years of headaches. 2. There are the numbers and there is the story that frames them. The higher you climb, the more you're paid for the second. 3. Product is the connective tissue between teams that would otherwise clash. Stakeholder management is the art of driving a direction without drowning in the details. 4. Leading through influence is infinitely more difficult than leading through authority. Every PM starts with only influence, but the great ones rarely need more. 5. The quality of your product is directly proportional to the number of nos behind it. Saying yes is easy. Saying no means you've done the work. 6. A product built solely on opinions is a sandcastle. Data is knowing how close to the water you can build 7. Everyone around you starts at the solution. Dig out the problem buried underneath and check whether the two even match. 8. An organization's process is its scaffolding. Small teams build fine without it. Past a certain height, everything topples. 9. Out at sea, there's no such thing as a hole on their side of the boat. Effective teams work the same way.
@vivilinsv ·
If you’re a builder, you’ve got to listen to this. The “godfather of mobile gaming,” @markpinc, joined @reidhoffman on @mastersofscale podcast and shared his Proven, Better, New framework for building products people actually want. One of his most valuable distinctions is between instincts and ideas: Your instinct may be right—you sense that a real problem exists or that something could be fundamentally better. But your first idea for solving it is probably wrong. That’s where the framework comes in: - Proven: Study what already works and copy the essential mechanics without ego. - Better: Improve something users already care deeply about. - New: Isolate your original bet so you can test it quickly without reinventing everything else. Great product builders don’t copy because they lack imagination. They copy what has already been proven so they can focus their creativity where it truly matters. As the saying goes, great artists “steal”—but the real art is making the gameplay unmistakably your own. That’s deeply inspiring to me as I build @Souli_AI and work to create a distinctive gameplay of our own. A must-watch for every founder, product manager and builder. P.S. So happy Mark followed me back - honestly made my day! 😊 Full interview link in thread.
Watch video
@peer_rich ·
a roadmap is fiction the market changes, users surprise you, something breaks the companies that treat roadmaps as contracts spend all their time defending old decisions instead of making new ones they way i see it, we should all plan loosely, ship honestly, and adjust in public
@ant_murphy ·
Q: "how do you build a product strategy for AI products since when we don’t know what AI models will be capable of, we don’t know what competitors are doing or where the market is going in the next 3 months, let alone the next 8 months?" Answer: Throw a lot of stuff out there. Of course it's more nuanced than that but I'm not kidding. I shared this in a recently newsletter post on How the Leading AI Companies Do Product. I talked about how they're all incredibly 'bottom-up' and it's intentional. They genuinely don't know what will be technically possible next, or what will resonate. So throwing a lot of ideas out there to see what sticks is deliberate. Going broad _IS_ part of the strategy. And Cynefin explains why that works. Most product work lives in the complicated domain. Known-unknowns or Unknown-Knowns. In these spaces you can sense, analyse, then respond. aka Research first, decide second. But AI products are truly in the unknown-unknowns. There's nothing to analyse yet, so you have to act and probe first. Run lots of experiments and see what works and resonates. Which is the opposite of what most of us are used to. Which is why I am seeing a lot of AI Product Roadmaps and Strategies fall apart and executives get frustrated. Here's the nuance (and how I'm approach it as I'm living this first-hand) It's the same way I approach 0 to 1 startups, which is a very similar context. 1. Have a shared long-term view of where the world is heading This is for alignment, to make sure you're rowing in the right direction. But it can't be too concrete, because so much is unknown. So write it as narratives. The key things you believe will be true in a few years. For example: - Do you believe there'll be no more UI in an agentic world? - Do you believe everything will happen through chat or not? - Do you believe we'll swing back to doing everything in person and non-AI work will be highly valued like hand-made stuff is today? - etc. 2. Focus on a near-term goal Eg. our first MVP or the next version of your product. Basically the next 3 months. Create a high amount of clarity and detail in that. Basically "we need to build X". You strategy ends up the combination of these two. It's multi-year narratives plus a 3 month target. And accept math things are going to change a lot more than you're used to. We should also intentionally bake-in flexibility. Leave room to adapt, to pounce on opportunities when they show up, and to keep going broad and trying new things. For anyone building AI products (or in 0-1 startup land) and struggling with this I hop it helps.
@quxiaoyin ·
Everyone's saying product managers are screwed. I keep seeing articles like this one by Lenny where VCs think PMs are heading for massive disruption. Another piece straight-up called product management a "sunset industry." As someone who wrote a PM bestseller eight years ago, I'm conflicted. The articles aren't wrong about some things. Most PM work is just translating between teams and doing alignment - stuff AI can absolutely do better. AI has all the Slack messages, meeting transcripts, everything. Why do we need humans for alignment? Plus teams are smaller now anyway. Companies that used to need 1-2 PMs for 20 people now run with 2-person teams. Who needs a PM when there's barely anyone to manage? I agree - traditional PM work is toast. But here's where it gets interesting. Everyone agrees that "builder PMs" who can take ideas from concept to live product will be incredibly valuable. So who becomes these super builders? PMs learning to code? Or engineers finally getting to build what they want without PM interference? My take (and yes, I'm biased): PMs have the edge. Product sense matters more than coding skills when AI handles implementation. My engineer friends disagree. They think I'm just another liberal arts major who couldn't handle real technical work. They believe engineers will naturally become better builders than PMs scrambling to learn tech. Maybe they're right. But I still think understanding user problems beats understanding compilers. The winners will be people who think like founders - regardless of whether they came from PM or engineering. Because AI makes technical execution easier. It doesn't make knowing what to build any easier. #ProductManagement #AI #Engineering #Startups #TechCareers #FutureOfWork #Builders
@SergioRocks ·
You already know what needs to be built. That’s your advantage as a Product Manager. For years, the gap was execution: - You defined the problem - Wrote the PRD - Prioritized the roadmap Then handed it over for implementation. That gap is gone. With tools like Lovable, Cursor or Claude Code, now you can: - Turn a spec into a working prototype - Build simple frontends and flows - Wire APIs and basic logic - Ship something users can actually try Perhaps not production-ready systems. But real minimum viable products. The fastest way to get better at product is no longer writing better PRDs. It’s shipping the actual product. Instead of debating scope for weeks, build the smallest version and test it. Instead of polishing a roadmap, put something in front of clients. This is where product sense sharpens. Not in docs. In the client feedback loop. You don’t need to replace engineers. But you can remove the gap between idea and validation. And that changes everything. The best PMs are no longer just defining products. They are shipping and testing them in the real world.
@rcmisk ·
your first 10 users are the product. not beta testers. not early adopters. the actual product. the questions they ask, the workflows they break, the features they ignore: that's your roadmap. most founders extract feedback. the ones who figure out PMF let users design the next version. how are you turning user conversations into build decisions right now?
@mbertulli ·
Your product roadmap should be driven by customer jobs-to-be-done, not feature requests. Solve the problem behind the problem.
@YanqingCheng ·
back in Feb everyone was building orchestration systems and I was like "hey we need an orchestrator to build a product but let's not build an orchestrator as part of our actual product because in 5-6 months time the models will be good at orchestrating". but even so, I now have a very different opinion about what the products that actually are needed, that complement the models that can orchestrate, actually look like. so on the one hand I feel well-calibrated and prescient, and on the other hand I still don't back myself to know what the "right ux" looks like for devtools in another 6 months time. makes it pretty hard to come up with a product strategy but everyone is in this boat...
@joncphillips ·
Roadmap (n.): a document describing what you would build if nothing unexpected happened, written by someone who has been doing this long enough to know things will.
@shouvik ·
Last evening Siddharth and I were debating Product Management over a couple of drinks. I argued that good product management is largely common sense. He disagreed. His view was that it is less about common sense and more about common morality. That idea stayed with me, so I spent the morning reading about common morality. What struck me wasn’t that morality is “common”, but that each of us assumes our own moral framework is the obvious one. We struggle to imagine how someone with a different worldview might reason. That distinction matters for product managers. It’s easy to exploit predictable user behaviour to improve conversion, engagement or retention. The real dilemma is whether our decisions genuinely serve the user’s interests or merely optimize the metrics we’re accountable for. An overly rigid moral framework can prevent experimentation and unconventional solutions. A weak one can justify manipulation in the name of growth. It left me wondering whether good product judgment isn’t just common sense. It’s practical reasoning constrained by an ethical framework that keeps the user at the centre of decisions. Thanks @_svs_, for an idea that kept me thinking long after the conversation ended!
@DenisJeliazkov ·
Project Manager vs Product Manager Project manager: keeps the train running. Updates, deadlines, coordination. Product manager: thinks in trade-offs. Features, market, decisions. Most teams hire the first and expect the second. Then wonder why nothing feels “product-led.”
@marvinvista ·
A product manager is responsible for delivering these outcomes: - Define the right product and where it should go over time. - Own the spec and messaging: what it does and why customers should care. - Align engineering, design, marketing, sales, support, finance, and PR to get it built and launched well. - Protect the product’s original intent so it doesn’t get watered down. - Be the voice of the customer: surface pain points, guide tradeoffs, and drive toward happy customers and a viable business. h/t @tfadell
@andywalner ·
Why are forward-deployed product teams winning? They give large companies back what they lose as they grow: startup speed. Traditional product management asks teams to prove an idea belongs on the roadmap before they can test it. At Google, my org was encouraged to pursue ideas only if they could become $100M opportunities. That filter kills promising ideas before customers can prove their value. Forward-deployed teams reverse the process. They start with a real customer problem, build a solution, and learn from how it performs. The best ideas earn the right to scale. At Sierra, we share what works across the company, then turn the strongest solutions into product capabilities for every customer. This is how we run fast experiments, delight customers, and keep a high bar for everything we bring into the core platform. Take transfer nudges, which decide whether an AI agent should hand a customer to a person immediately or make another attempt to help. After solving this problem across many deployments, our agent engineers learned when these nudges work best and when they frustrate customers. They turned those general lessons into reusable SDK tooling and a no-code package. AI makes this model even more powerful. Internal tools like Pinecone help builders across Sierra ship high-quality work faster. The result is a tighter loop: solve, learn, share, productize.
@kylegawley ·
How I prioritise software roadmaps and features: ❌ Guess what users want ❌ Build whatever sounds fun ✅ Look for evidence tied to customer behaviour and revenue I usually think about feature requests in two buckets: 1. What would make existing customers more successful or stop them leaving? 2. What's currently blocking new customers from buying? For existing customers, I look at two main sources: 1. Feedback boards tell me what engaged customers would like improved. 2. Churn feedback tells me what was important enough to contribute to someone leaving. The second is usually more urgent especially when the same issue appears repeatedly because it’s directly connected to lost revenue. Then I look at growth. What are prospects repeatedly asking for during trials, demos and support conversations? If multiple qualified prospects are saying: "We need X or Y" That deserves attention. Revenue-linked requests still require strategic judgement. A request from one lighthouse customer can derail your entire product strategy BUT sometimes that trade-off is worth making. We did this with Jason Calacanis. The commercial value of having him as a customer was greater than the value of sticking rigidly to our existing roadmap.
@jradoff ·
The PM role isn't dying. It's expanding. LinkedIn just replaced its Associate Product Manager program with "Associate Product Builder." Microsoft and Citi are building agent ops teams. 41% of production code is now AI-generated. What's happening — and what it means for product leaders:
@bandanjot ·
Why do so many product teams struggle with prioritization? I've observed countless meetings where discussions spiral out of control, leaving clarity in the dust. A clear prioritization framework can help you avoid this confounding chaos. I often wonder what it would look like if teams adopted a zero-based approach to prioritization. Imagine starting from scratch, evaluating every project solely on its merit rather than historical precedence. What if, instead of being held hostage by momentum, we focused exclusively on delivering customer value and aligning with strategic goals? Effective product management hinges on resource allocation, and the right framework can turn chaos into clarity. The impact of prioritization is profound; it guides team efforts, aligns stakeholders, and shapes product vision. Consider models like the RICE scoring method or the MoSCoW technique—each provides a systematic way to assess initiatives based on Reach, Impact, Confidence, and Effort, or importance levels respectively. In a rapidly changing landscape, being able to pivot based on data rather than gut feel is invaluable. Reflecting on fundamental decision-making processes can aid your product’s trajectory and foster a culture of strategic thinking. Rethinking the way we prioritize could transform not just outcomes but team dynamics, leading to a more agile and engaged product team.
@bandanjot ·
Roadmaps might be the biggest illusion in product management. Sure, they help you visualize the journey ahead. But how often do they turn into rigid scripts that stifle real-time learning? Instead of being a guiding light, they can become a cage, restricting your team from adapting to emerging insights or shifting market dynamics. The reality of product development is chaos, and it's essential to embrace that chaos rather than map every moment meticulously. Agile methodologies advocate for continuous discovery, where the understanding of customer needs evolves as the product iterates. It's about steering your ship through unknown waters rather than following a predetermined route. When we accept that our paths will zigzag and that detours will lead to innovation, we open ourselves to a world where user feedback drives product evolution, and every mistake becomes a lesson learned. Let’s rethink our relationship with roadmaps and prioritize flexibility in the journey. What’s your take on balancing planning with adaptability?
Best Product Management tweets
Xholic studies what works in your niche, drafts posts in your voice and schedules them for the hours your audience is online.
No card needed · Nothing to cancel
Browse all tweet collectionsLive demo: no sign-up or login needed · takes about 2 minutes
Keep exploring