Roadmaps, Prioritization & Tradeoffs
Roadmaps as flexible, evidence-driven plans rather than fixed contracts; prioritization, scope control, feature killing, and investing in what works.
30%
Best tweets about Product Management
50 Best Tweets About Product Management (2026)
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.
- Creators
- 44
- Updated
Original Xholic analysis
What 50 top Product Management posts reveal
Product-management posts frequently frame roadmaps as revisable plans shaped by customer evidence rather than delivery contracts. AI is presented as compressing execution while increasing the importance of product judgment, evaluation, customer contact, and stakeholder alignment. Posts disagree over whether this change produces a unified builder role or expands existing crafts.
- Dominant tone
- Positive
- Median score
- 8.24
- Leading format
- Opinion
- Recent posts
- 36%
50% of posts
All-time engagement
80% of posts
Published in 90 days
Conversation map
The themes creators return to
AI Product Management
How AI changes PM work: model evaluation, data and failure-mode planning, agent-native products, AI-assisted workflows, and knowing when not to use AI.
28%
Product Strategy & Value Creation
Product strategy grounded in problem definition, customer value, market differentiation, business viability, and disciplined resource allocation.
26%
Customer Discovery & Feedback Loops
Direct customer conversations, feedback immersion, jobs-to-be-done, and real-world usage as the primary inputs to discovery and roadmap decisions.
24%
Product Judgment & Quality
Product quality through empathy, taste, high standards, coherent messaging, foundational UX, and resisting low-value or manipulative choices.
24%
Builder Roles & Faster Shipping
The shift from specialist PM, design, and engineering roles toward cross-functional builders who can prototype, ship, and validate directly.
22%
Product Organization & Operating Models
Team and company design for product velocity, including centralized versus GM structures, founder-led product, forward-deployed teams, and team-product fit.
14%
Stakeholder Alignment & Influence
PM as organizational connective tissue: stakeholder alignment, influence without authority, clear priorities, and managing dysfunctional decision processes.
12%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 26
- Median reposts
- 2
- Median replies
- 4
- Median views
- 2.6K
Posts with media make up 32% of this collection. Their median all-time score is 18.5, compared with 5.08 for text-only posts.
Format mix
- Opinion 80% · score 8.20
- Announcement 14% · score 7.27
- List 4% · score 10.1
- Question 2% · score 211.5
Consensus and debate
Where creators agree, and where they do not
Shared view
Roadmaps earn their place through evidence
A recurring principle is that roadmaps should follow real problems and customer input: remove unjustified scope, talk with users, and let feedback reshape what gets built.
Shared view
AI raises the bar for product judgment
AI product work is framed as disciplined judgment rather than feature enthusiasm: validate the problem, decide whether AI is needed, plan for data and failure modes, and use evaluations as a launch criterion.
Open debate
Is the PM becoming a builder—or broadening?
Posts offer competing views of role convergence. One predicts a unified builder role; another argues the old role boundaries were already inaccurate; a third argues that founder-like product sense matters more than a PM or engineering title.
Open debate
Automate feedback processing, not customer understanding
Posts differ on how customer feedback should be mediated. Conversational products and automated pipelines can expose signals, while another post argues that direct immersion builds intuition that summaries cannot replace.
What performs
Patterns behind standout posts
Top outliers focus on PM mandate and decision-making
The five supplied outliers cover product messaging, feature restraint, AI-era PM relevance, role convergence, and stakeholder alignment. Their scores range from 127.28 to 478.19, versus an overall median all-time score of 8.24.
Opinion dominates; prompts and media stand out
Opinion made up 80% of posts. The single question-format post had the highest supplied format median score (211.453), and posts with media had a higher median all-time score than text posts (18.48 versus 5.08).
Statistical standouts
- View standout post 1 Score 478.2 · 58.03× median
- View standout post 2 Score 259.3 · 31.47× median
- View standout post 3 Score 251.0 · 30.46× median
- View standout post 4 Score 211.4 · 25.66× median
- View standout post 5 Score 127.3 · 15.45× median
Creator landscape
Who shapes this conversation
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. Tony Fadell
@tfadell
2 posts
Fadell makes empathy a shipping filter
Tony Fadell’s two posts are the dataset’s first- and second-highest scoring outliers. Together, they argue that empathy should shape product messaging and that weak features should be cut when their value cannot be explained.
AI does not remove the human PM problem
George from prodmgmt.world presents AI as changing the constraints around PM work while emphasizing enduring human work: choosing where to focus, talking to customers, and securing stakeholder alignment.
Since the previous snapshot
What changed since Aug 7, 2026
- 82% of the selected posts remained.
- The creator count changed by +2.
- The leading sentiment remained stable.
How this analysis was made
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
Top Product Management tweets from 44 creators
Ranked 01–50
- 01
@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
- 02
@tfadell ·
PMs don’t just ship features. They kill them. Shipping isn’t the job. Shipping the right product is. A great PM doesn’t fall in love with the roadmap. They fall in love with the problem and have the guts to say: This isn’t solving it. This adds complexity. This doesn’t matter. Every feature, setting, UI, element should fight to exist. At Nest, we had one rule: If you can’t explain why it matters, it doesn’t ship. You had to tell us the why. The reason a real person would care. That one rule killed dozens of features.
- 03
@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 🥂
- 04
@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
- 05
@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.
- 06
@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
- 07
@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
- 08
@JustAnotherPM ·
Most people think the "AI PM" title is just a product manager who happens to know AI. That is what I told myself the first six months of working on AI products. Turns out, I had the role inside out. After years of coaching AI PMs, hiring a few, getting hired by a few, here is the sharper take: The job is not "product manager who knows AI." The job is "person who can hold a model accountable to a customer." AI PMs need to answer 7 critical questions 𝗪𝗵𝗮𝘁 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘀𝗵𝗼𝘂𝗹𝗱 𝘄𝗲 𝘀𝗼𝗹𝘃𝗲 The problem must be specific, validated with real users, and solution-agnostic. If you get this wrong, the model does not matter. 𝗗𝗼𝗲𝘀 𝘁𝗵𝗶𝘀 𝗿𝗲𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱 𝗔𝗜 This is the most important question an AI PM asks. And the answer is usually no. Saying no to AI when the situation does not call for it is not a failure. It is the job. 𝗗𝗼 𝘄𝗲 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗱𝗮𝘁𝗮 "We have data" is not a strategy. An explicit data plan that includes what data we need, what we have, and what is missing is the right strategy. AI is only as good as the data behind it. 𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝘁𝘂𝗿𝗻 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗶𝗻𝘁𝗼 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘂𝘀𝗲𝗳𝘂𝗹 Simple prompt, ML model, RAG, or agents. Each has a different use case, cost profile, and failure modes. The PM who skips this hands those decisions to engineering. 𝗛𝗼𝘄 𝘄𝗶𝗹𝗹 𝘂𝘀𝗲𝗿𝘀 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝗶𝘁 Users need trust, control, and recovery. Design for when the AI fails, not only for when it works. 𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗸𝗻𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝗹𝗮𝘂𝗻𝗰𝗵 There is no binary pass/fail. Build an eval framework. Define good, bad, and edge cases. Ship only when the product clears your threshold. 𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗺𝗮𝗸𝗲 𝗶𝘁 𝗯𝗲𝘁𝘁𝗲𝗿 𝗮𝗳𝘁𝗲𝗿 𝗹𝗮𝘂𝗻𝗰𝗵 AI products degrade in production if you stop watching them. Sample live conversations. Add new failure modes to your test set. Never stop monitoring. Until you're answering all seven, the title is decoration. Once you can, it is the most leveraged role in the company. The companies that figure this out in 2026 will out-ship the ones that do not by 10x. Watch the job openings. The shift has already started.
- 09
@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.
- 10
@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.
- 11
@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
- 12
@clairevo ·
Here is the problem with loops wrt product management: there are not infinitely commercializable product problems in a domain, even though there are infinite things to change in a codebase. Even as I surround myself w lots of (fairly autonomous!) agents, I still run a ROI positive compute budget—meaning we don’t really build for build’s sake, because we haven’t seen the upside from brrring tokens 24/7. I do run lots of loops where I think we’re under leveraging raw intelligence or diligence (sales, marketing, bugs) but unless your product loop is highly coupled with a distribution + monetization loop (in a market where there is budget) you’re just shipping green diffs into the void.
- 13
@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).
- 14
@heyitsalexP ·
Manager: "I want more visibility into our team's priorities" Team: *builds out PM system, sends daily updates* Manager: "Not like that! I can't spend all day reviewing tickets and roadmaps" Team: *condenses everything into weekly update* Manager: "Why are we doing project X?! I though I TOLD you our priorities are Y!" Team: "It was in the weekly recap, I thought we agreed–if you had no feedback on the recap, it was ok to proceed with those projects" Manager: "An email is going to get lost in my inbox and I don't have time to read a list of 50 projects anyway! Let's transition to a weekly 15 minute standup" Team: ok, what time works for you? Manager: "Mondays at 11a...except every second Monday of the month because that's my skip level. And every other week I have an executive team meeting that's usually at 10a but sometimes I get rescheduled to 10:30a and sometimes it runs over..." If this sounds familiar, you need to confront two harsh truths: 1. You don't actually want "visibility", you want a team of mind readers, who will translate your fleeting thoughts into the perfect roadmap "make no mistakes". This doesn't work for romantic relationships, and it doesn't work for managing teams. Grow TF up. 2. You're probably doing a piss poor job of setting priorities and communicating them. If everything is an emergency, nothing is an emergency. If the goal posts are always moving, building an action plan is impossible. Stop managing your business reactively, from a place of fear, and take time to communicate your POV and priorities...and watch "management" magically get 10x easier. Bonus: feeding your inbox and PM system into OpenClaw doesn't solve this problem because YOU are the problem.
- 15
- 16
- 17
@FredaDuan ·
Org Design & Reorgs I’ve always been fascinated by two things: 1/ how different companies design their org structures, and 2/ what it signals when a company goes through a major reorg or restructuring. --- 1/ Org structure: no one-size-fits-all Broadly, companies sit on a spectrum from centralized to single-GM. Centralized: decision-making, product strategy, and core engineering are tightly controlled at the center. This works best when coherence matters more than speed - a single system, brand, or architecture where fragmentation creates tech debt or UX inconsistency. Single GM: businesses are run as semi-autonomous units with clear P&L ownership. This works when speed, local optimization, and accountability matter more than perfect cohesion. A. Common patterns > Centralized High premium on end-to-end quality, architectural integrity, and brand consistency. Typical in “one-system” products Examples: $Apple, $Airbnb > Single GM Optimized for portfolios of distinct businesses, categories, or geographies. Speed and ownership beat strict coordination Examples: Common in CPG ( $P&G, $Unilever) and multi-country, regulated businesses (often country GMs, e.g., $Revolut) > Hybrid GM / vertical / geo owners paired with shared platform teams (core eng, data, infra, risk, compliance, brand). This only works if leadership is psychologically comfortable giving up control and pushing decisions down to BU leaders Examples: Marketplaces and multi-line fintechs ( $Uber, $DoorDash, $Robinhood, $Coinbase, $Revolut) B. 180-degree org reversals can happen $Robinhood Centralized → GM-led (2022) Arguably a major contributor to the sharp acceleration in product velocity that followed $Square / $XYZ GM-led → centralized after Dorsey returned A classic response when coordination costs explode, architecture degrades, or brand/system coherence becomes the bottleneck after rapid expansion --- 2/ Restructuring as an investment opportunity Major restructurings often create windows to own good companies while sentiment is messy and execution risk is over-discounted. A few that just/ are going through major restructurings: Meta Googl Shopify Apple SpaceX / xAI / Tesla (potentially)
- 18
@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.
- 19
@denk_tweets ·
letting go of my ego and learning how to take critical feedback has been a massive unlock for me a few weeks ago I asked people on LinkedIn and X to roast our product. over 250 users responded and tore us apart I also spent hours on Reddit last month getting roasted some people on my team got pretty stressed about the insults and everything else that comes with building in public… for me, it couldn't have been more helpful (and humbling). it helped craft our roadmap for the next six months — our users told us exactly what we can do better so when I ask again six months from now, it's our job to make sure it's not the same feedback
- 20
@Hartdrawss ·
10 things in your MVP brief that are SILENTLY burning your budget (before a single line of code gets written) 1/ No ICP defined → you build for everyone, ship for nobody 2/ Timeline locked before scope agreed → you negotiated against yourself before the call ended 3/ 3 founders, 3 opinions → pick one decision-maker or prepare for 3 rewrites 4/ Payment flow mentioned last → it's the most important UX. Your users see it first. 5/ 200 screens for an MVP → that's a roadmap, not a product 6/ No admin panel in the brief → day 3, someone asks "who manages the data?" Silence. 7/ User roles left undefined → one wrong assumption here rebuilds the architecture 8/ IP ownership skipped → fine until the product hits. Then it's $10K in lawyers. 9/ No success metric → "make it good" is not a brief 10/ Revision rounds not discussed → this is where scope creep always starts A bad brief doesn't just slow the build It ships the wrong product entirely
- 21
@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.
- 22
@aakashgupta ·
Every major platform in history has run the exact same six-word playbook. Open. Invite. Reward. Study. Absorb. Eliminate. 1988. Lotus 1-2-3 controlled ~70% of the spreadsheet market. An entire economy sat on top of it: add-ins, training firms, consultants, thousands of books. Microsoft bundled Excel inside Office for less than the cost of Lotus alone. Excel overtook 1-2-3 by 1993. IBM bought the remains of Lotus in 1995, then slowly discontinued it. Excel now generates ~$2B/year. The Lotus add-in developers got nothing. 1998. Karelia Software built Watson, a Mac internet-search tool. Won an Apple Design Award. Two years later Apple shipped Sherlock 3 with near-identical functionality, native, free, preinstalled. Karelia folded. The industry got a new verb: "Sherlocked." 2007. Facebook opened its platform, invited Zynga in, let them build FarmVille to 83.76M monthly actives by March 2010. Facebook changed its messaging policy that same month. Traffic dropped 26% in four months. Zynga never recovered its platform dependence. 2013. Twitter had three dominant third-party clients: Tweetbot, Twitterrific, Echofon. Developers who built the original Twitter experience. Twitter capped their user tokens, then revoked API access on a Thursday night in January 2023. No warning. Tapbots shut down Tweetbot after 12 years the same week. Four platforms. Four decades. One pattern. 2026. OpenAI has the contractual right to study every query, every retry, every edge case, every successful flow built through their API. The ToS spells it out. Every production prompt you ship is a labeled training example. Every failure you debug is feature gap research. Every user flow you monetize is a roadmap bullet. The pattern is the same. The timeline keeps collapsing. Lotus had 7 years. Watson had 2. Tweetbot had 12 hours. You're their product manager. You're paying them to do the research.
- 23
@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.
- 24
@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 👇
- 25
- 26
@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
- 27
- 28
@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.
- 29
@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.
- 30
@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
- 31
@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
- 32
@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.
- 33
@vitaliidodonov ·
Stanley One launch T-74. preparing for a big launch on june 1. 74 days out. figured i'd try this one differently. first thing i did was spin up an @OpenClaw agent as my product manager. his job: hold me accountable, track everything, push back when i'm being naive, send daily standups. building the PM before building the product. called him jared. let's see how this goes.
- 34
@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
- 35
- 36
- 37
@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.
- 38
@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?
- 39
- 40
@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...
- 41
@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!
- 42
- 43
@BenjaminBadejo ·
I think most tech companies (and even non-tech companies), as well as individuals, could learn a lot from the way @OpenAI staff engage with users on X. They’re very responsive, almost dogmatically positive and respectful, never complain publicly, and really try to understand what users want or need. If they can provide what users are asking for, they do — pretty quickly, too. Many companies have lots of users with pain points to share, questions to ask, and suggestions for features. Users provide so much potentially useful feedback that is ripe for implementation (or at least ripe for genuine consideration and roadmap placement). But most companies ignore that feedback entirely, or, at best, delegate user feedback to an impersonal support ticketing queue or inbox that is not closely connected to the product management, design and engineering teams. What makes @OpenAI different is that their people actually listen to users and even talk to users directly, on a daily basis. They don’t just direct users to some impersonal support queue and consider the job done. Instead, they personally do the job of engaging with users and turning feedback into product improvement. As a result, things keep getting better and better. All you have to do to succeed is actually care.
- 44
@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
- 45
@TheCharlesIsidi ·
Before product market fit, I believe you must hit team-product fit. There’s a way a product gets on the roadmap and you just notice the team is invigorated to build it, they are dreaming up new things outside of the scope, it’s almost like this product has sparked their genius and will to create beauty. It’s usually the first sign for products that will do well, the team enjoys creating it, are tinkering around the edge cases, they are simply just happy to stay up till 2am. Every call always has that “I was thinking about this and how it can help the user” from almost everyone, and in their heads, the possibility is becoming endless. Yes, eliminating team disillusionment, this is almost a tell tale sign that a product might succeed. I said might. But as a founder, you want to prioritize products like this, products that keep your team dreaming and in awe. It’s good for their nervous system, and your job is to keep casting that vision and extending the boundaries of what’s possible in their minds. This is how sweet and delightful products are built. Once you sense hesitation from the team, then it’s probably a bad product. Also your job as CEO is to manage energy, you are the teams hype man, you make them feel intelligent, you show them it’s possible, and you get them to the product market fit promised land.
- 46
@_vmlops ·
MiniMax M3 didn't get a prompt. It got an entire startup Product requirements, Pricing docs, Customer feedback, Roadmap, Competitor analysis, All loaded in at once The task was simple: read everything, build the first version and explain what to prioritize and why What came back wasn't just code. It was a product decision. Pricing shaped the features, Customer feedback rewrote the roadmap. Competitor data influenced every trade-off M3 didn't summarize the documents. It reasoned across them
Watch video
- 47
@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.
- 48
@Michael_Fenech_ ·
Claude Code tip: Always start with a spec. Not a vague idea. A spec. What does it do? Who is it for? What does success look like? This forces clarity before code. I have seen developers skip this step and spend 3 hours building the wrong thing. 10 minutes of spec writing saves hours of refactoring. Claude is a great implementer. But you are the product manager. Act like one.
- 49
@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.
- 50
@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 Tweets by Topic