We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Is the PM edge gone?
A Head of Product at a UAE fintech asked whether product is "doomed as a role." His case: AI drafts detailed requirements in minutes, and engineers increasingly don't need to be told how to build. He says that has worn away what used to set the role apart .
The most concrete reply came from a former two-time VP Product in financial infrastructure. About 1.5 years ago he moved into a hybrid product-engineer IC role, building PoCs and testing them with clients before engineering finishes the product. He reports earning about 2x his previous pay. He also says nearby PM-management roles are being cut "in exchange for hiring product IC's who can ship fast." His view is that head-of-product skills still pay off when the "team" is made of agents .
Other replies split two ways:
- Speed wins. One PM expects speed to beat quality "for the next few years," since copycats show up within weeks. Their warning: PMs who don't think like engineers will struggle .
- Judgment wins. Others say AI output is only as good as the person prompting and reviewing it, and that the thinking is "still the most important thing" . A consultant says product skills are in higher demand across enterprises. In their view, PMs supply the context AI needs, and "everyone will be some sort of a product manager" .
One PM described a working setup. They write draft Playwright tests tied to user journeys before the build. Prototypes run against a real backend sandbox and are heavily tested before engineers touch them .
What job descriptions ask for
Aakash Gupta summarizes Ankit Shukla's AI review of 10,000+ PM job descriptions. Over 30% now ask for AI skills, and the top skill is picking the right AI use case, ranked above RAG, agents and prompt engineering . The advice is to run the first experiment yourself before asking for an engineering sprint, and to "engineer last" . One example of owning "the last 20%": Shukla questioned an AWS stack Claude proposed and cut it from $420 to $110 a month . The post also cites Axial Search data: a $195K median across 12,397 US AI product postings, and $320K–$520K total compensation for senior roles .
Context and agents as the platform
Scott Belsky argues that devices, operating systems and app-like experiences will increasingly "spawn from the context we provide them," and will be limited by that context. He describes an early "context war": agents want user data, data stewards weigh whether to allow connectors, and consumers have no portable source of truth for their context and aren't sure whom to trust. He calls this a "big opportunity" . Ryan Hoover's related bet: as consumers let agents make purchase decisions, the "quantifiably best" products will grow . Hoover also called Block's Dessa full-duplex speech model the best voice demo he had heard, and expects human-level voice to unlock many more consumer use cases .
The serving stack affects AI feature quality
A YC Paper Club speaker said providers serving the same open model differ in precision, weights version and tool calling. The gap between the worst and best provider can be larger than the gap between open and closed models . Errors compound in agent workloads: with a 10% per-step deviation, a 15-step task could be up to 79% wrong . Full evals are expensive to run continuously. A cheaper option is to watch tool-call error rates and changes in request shape, which can catch problems like infinite loops .
Practitioner notes
- Scoping search: For a 150M-record dataset, a search PM advised against indexing everything, since it adds latency, noise and cost. They let actual filter clicks and usage decide what to keep . Another PM found through discovery that users wanted reports, not search. Cutting 27 of 30 options turned an eight-week build into a couple of days, at the cost of not serving about 30% of users .
- Exiting an internal product: Push it into maintenance mode, framed as freeing resources for higher-impact work. One PM needed about six months of documented low impact before leadership took it seriously .
- Stakeholder anxiety: In a large thread on anxiety, one senior PM said they and two senior-PM peers were all signed off work for burnout or anxiety this year . Tactics shared: go into a meeting you dread with three points to land and one question to ask , and in heated moments, bring the discussion back to data, the product and the customer .
- Distribution before features: A founder building a LinkedIn alternative admitted to building for months before working out distribution . One commenter's suggested reframe: sell it as a single job-search workflow, measure completed searches rather than signups, and recruit users in cohorts such as bootcamps .
- Fast response to demand: Hiten Shah's Beam hit #1 on Product Hunt and shipped its most-requested feature, Intel Mac support, three days later .
- Before technical meetings, define what a “good” search result means for users and bring 3–5 representative queries, such as an exact part-number match versus a misspelled brand name; keep the technical plan anchored to that user-defined outcome.
- Prepare to ask how search quality is measured and examine indexing delays, relevance versus latency, filtering, ranking, and freshness; facilitate technical trade-offs and surface how pipeline changes affect upstream and downstream systems.
- For the original 150-million-record dataset, challenge the assumption that every field or filter should be indexed: indexing everything can increase latency, noise, infrastructure costs, and relevance-tuning difficulty. Use actual filter clicks, usage patterns, and uplift to decide what to simplify.
- Validate the underlying user need before building a broad search interface. In one prior case, customer discovery showed users wanted a custom report or condition verification instead; the team removed 27 of 30 options, did not serve about 30% of users, and delivered in a couple of days rather than eight weeks, using a vector database and heavy import-time processing.
- Tune AI serving to the product’s workload and service-level goals rather than a single speed target: profile coding versus chat workloads, cache-hit rates, time between user turns, responsiveness, and end-to-end completion time. Scheduling also involves a throughput-versus-snappy-response tradeoff, while prompt prefill and token generation are distinct workloads.
- Treat the provider and serving stack as part of product quality: providers serving the same open model can differ in cost, intelligence, speed, and region/privacy, as well as in precision, model version, and tool calling. The speaker said the provider-to-provider performance gap can exceed the gap between open and closed models, and warned that inconsistencies compound in long-horizon agent tasks.
- Combine quality checks: broad evaluations can catch issues but are costly and slow to run continuously; lightweight monitoring of tool-call errors and request patterns can surface problems such as looping. Customer-specific evaluations based on private data or traffic can help detect failures in real use cases and are harder for providers to game.
- A former two-time VP Product in financial infrastructure says they moved 1.5 years ago into an IC hybrid product-and-engineering role, building PoCs and testing products with clients before engineering completes them; they report earning about 2× their previous pay and seeing PM-management roles replaced by product IC hires. They see head-of-product skills as useful when applied to a team of agents rather than a people team.
- The discussion is divided on what AI changes: one participant predicts speed will increasingly outweigh quality because successful products can be copied within days, and says PMs will need to think like engineers. Others argue that faster execution does not remove the need for product judgment and experienced review, and that AI does not replace customer interviews, UX judgment, or A/B testing.
- One PM describes a practical AI-assisted workflow: prepare Playwright tests before the build, tie them to user journeys and expected outcomes, run prototypes against a real backend sandbox, and hand tested iterations to QA.
- The founder’s platform combines ML job matching, job-specific voice-based AI interview prep, skill-community reputation, and recruiter discovery; after months of outreach, the founder still struggled to turn attention into users who returned and acknowledged building before figuring out distribution.
- Product feedback emphasized validating a specific user need and focusing on retention rather than signups; the founder agreed that structured user research and learning what brings people back should take priority. One commenter proposed treating job search as a focused workflow and measuring completed searches and referrals, with cohort-based acquisition, rather than judging progress by signups.
- Commenters warned that a professional-network entrant faces cold-start friction because the incumbent’s network is part of its value, so a merely better product may not be enough. The founder’s counter-hypothesis was that job matching and interview prep offer value without an established network; the stated priority was proving users return for that value.
- PMs in the thread describe stakeholder conflict, organizational politics, and coordinating people as significant sources of stress; one says the role can feel lonely when representing a team among stakeholders backed by their managers, while another links burnout to caring about many things and keeping people working together.
- Meeting and conflict tactics shared by practitioners: prepare three points and one question before a difficult meeting; in charged discussions, return to data and frame the issue around the product and customer; document heated exchanges and delay responding until calmer.
- Stakeholder preparation can include mapping stakeholders with the DISC model; another PM recommends learning stakeholders’ goals and looking for a common solution, which they say helped turn difficult stakeholders into people who supported their work.
- One PM uses an AI-powered “second brain” that draws on meeting notes, transcripts, and Slack, checks for the PM’s identified weaknesses, and handles meeting prep and open-loop tracking after accumulating enough context.
- For a solar-monitoring product spanning multiple manufacturers, validate with small installers or maintenance contractors: ask how they monitor sites, how much time they spend across portals, what tool they would stop using, and whether they would pay to solve the problem. Commenters suggest positioning around fewer unnecessary site visits or extra repair jobs, with per-site pricing as one option.
- Prioritize trustworthy, actionable underperformance alerts over another dashboard: compare output with an expected baseline, such as irradiance data or nearby systems, to account for weather, shading, or dirty panels; otherwise false alarms may overwhelm technicians and erode trust. Alerts should help determine whether a problem needs a site visit or can be resolved remotely.
- Test the alert workflow before broad development: one suggestion is a 30-day shadow test with one installer and 20–50 sites, manually flagging drops and checking which would trigger a visit; another is to start with Fronius and SolarEdge across 10 sites before adding Huawei. Manufacturer API integrations may require ongoing effort.
- Validate the home-rehabilitation workflow with home-visiting physiotherapists before further development: a commenter recommends them over surgeons as better judges of whether the tool solves a real problem or adds documentation, matching the builder’s concern about spending months without confirming demand.
- Pressure-test buyer, differentiation, and clinical-trust assumptions. A commenter says Physitrack and Wibbi already sell monitoring to clinics, claims Indian clinics still rely on WhatsApp because documentation software is cut first, and notes HealthPlix offers a free EMR funded by pharma—raising the question of who would pay. The prototypes are early demonstrations, not clinically validated or deployed; another commenter cautions that warning-sign alerts entered by a student need qualified-clinician backing before clinics will act on them.
Beam launched on Product Hunt and reached #1; after Intel Mac support emerged as its most-requested feature, the team shipped it three days later. Support covers Intel Macs running macOS 14 or later and works in both directions: users can share windows or an entire desktop, or open windows from other Macs on the Intel machine.
Hiten Shah argues that there is no single right way to build an AI agent, harness, or context layer, just as there is no single right way to build software.
Hiten Shah observes that experience can make it easier to explain why an idea will fail, raising the possibility that founders and product teams dismiss some good ideas prematurely.
A founder reporting prior government and Google grants advised treating applications, reporting, and follow-ups as a time-cost tradeoff: early-stage founders may be better off spending those hours with customers and on growth. They recommended targeting programs that closely fit the company’s stage and industry, checking whether awards are cash or credits, and budgeting for reporting work. A separate commenter who had applied to three grants said all required a working demo rather than a deck, and paperwork was the main filter—an anecdotal reason to check evidence requirements and application effort before committing.
For a PM trying to step away from a difficult internal product, one suggested route is to move it to maintenance mode . To get leadership buy-in, frame the change as freeing resources for higher-impact work; one commenter said documenting the product’s limited impact for about six months helped make the conversation serious .
In a campus-placement discussion asking whether prior PM internship experience listed under eligibility was compulsory, one commenter advised treating it as mandatory unless marked “preferred” and suggested applicants without PM experience highlight relevant skills, tools, and keywords . Another commenter encouraged applying anyway .
Ankit Shukla’s analysis of 10,000+ PM job descriptions found that over 30% ask for AI skills; choosing the right AI use case ranked above RAG, agents, and prompt engineering, pointing to product judgment as a key skill. The proposed workflow is for PMs to run an initial experiment themselves before requesting an engineering sprint, map multiple opportunities rather than fixating on one, and ground product decisions in user workflows. The post also reports a $195K median across 12,397 US AI product postings and $320K–$520K total compensation for senior roles, citing Axial Search (2026).
Anecdotal product-discovery signal: one commenter says they look for tools that work offline first and make cloud use optional, but find products that require an account and sync before offering useful functionality. The original poster is building a product intended to run both locally and in the cloud.
Scott Belsky predicts that next-generation devices, operating systems, and app-like experiences will be generated from user-provided context and tailored to preferences, with their potential limited by the context available to them. He identifies a product opportunity—and adoption challenge—in the “context war”: agents need user data, data stewards decide whether to allow connectors, and customers weigh sharing risks, while consumers lack a portable source of truth and remain unsure whom to trust or how to balance privacy with convenience.
Ryan Hoover’s investment thesis is that as consumers adopt agents to make purchase decisions, products and services that are “quantifiably best” will see significant growth; this is a forward-looking thesis, not a reported outcome.
Block introduced Dessa, which it describes as a full-duplex speech model with human-like emotion, nuance, pauses, and cadence . Ryan Hoover called its demo the best voice demo he had heard and argued that human-level voice conversations could unlock many more consumer use cases .
Scott Belsky suggested that society would benefit from a cross-platform, open-source, broadly adopted Community Notes protocol, and asked whether X could offer Community Notes as a service beyond its own platform—a product and distribution opportunity, not an announced plan.
r/startups comment by u/Street_Program_7436
A year building a LinkedIn alternative because we thought everyone hated LinkedIn as much as we did. Turns out, hating it and leaving it are two different things. [i will not promote]
Last year we got really fed up with LinkedIn. Every other post is AI slop, everyone sounds like a motivational speaker. People sharing events which they dreamed last night after fapping twice. Intolerable corporate BS.
So we decided to build our own platform. Basically, the opposite of what LinkedIn has become.
We built a karma engine like Reddit where people build reputation by actually contributing something useful, instead of farming engagement with generic posts. Users can only post in skill-based communities or comment on job listings.
We built ML based home feed job matching that helps candidates figure out which jobs are actually worth applying to,
We also added a free voice-based AI interview tailored for each job to practice for specific roles.
The recruiter side is just as important to us. When every applicant has a perfectly tailored AI resume, how do you figure out who’s actually good?
Recruiters end up screening endless applications and spending days on calls. I want to give them better ways to find the right people without relying entirely on what’s written in a resume. They can simply visit the relevant skill communities and see the top contributors and directly message them.
There’s proper fb messenger level messaging too excluding calls, and I’ve made everything free for job seekers and recruiters both. No premium subscription to unlock the useful stuff.
But here’s the reality. I’ve spent months building all this and I’m still struggling to get users.
People already have LinkedIn. Even if they hate parts of it, getting them to join another platform and start from zero is a completely different challenge.
I probably spent too much time building before figuring out distribution.
I’ve been trying a few things to get the word out.
I’ve been posting about the platform in relevant subreddits, reaching out to recruiters on LinkedIn, making short videos showing how the features work, and building a community around the product.
I’m also trying to get people to try the interview tool because I think that’s something useful even if they aren’t ready to switch professional networks.
So far, it’s been a lot harder than I expected to turn that attention into people who actually stick around.
For those who’ve built something that needed a community to become useful, how did you get your first real users? Not signups that disappear the next day, but people who actually come back and participate.
I’m curious what worked for you, especially if you were starting with basically no audience.
Others have said this in other words but IMO you have too many features that speak to different audiences. It’s unclear who your target customer is, which is probably why you’re having a hard time finding them and getting them on your platform. Because for every one feature that maybe speaks to them, there are 5 that don’t.
The big platforms didn’t start out with the 100 features that they have now. They originally had one specific use case, which allowed them to be laser-focused. You’re not laser-focused. So, go figure out which of the things people truly want to use and then focus your site on that. Don’t build anything else before figuring that out.
- The founder’s platform combines ML job matching, job-specific voice-based AI interview prep, skill-community reputation, and recruiter discovery; after months of outreach, the founder still struggled to turn attention into users who returned and acknowledged building before figuring out distribution.
- Product feedback emphasized validating a specific user need and focusing on retention rather than signups; the founder agreed that structured user research and learning what brings people back should take priority. One commenter proposed treating job search as a focused workflow and measuring completed searches and referrals, with cohort-based acquisition, rather than judging progress by signups.
- Commenters warned that a professional-network entrant faces cold-start friction because the incumbent’s network is part of its value, so a merely better product may not be enough. The founder’s counter-hypothesis was that job matching and interview prep offer value without an established network; the stated priority was proving users return for that value.