Direct answer. As of mid-2026 the field is still "the year of the demos": Neo 1X can be pre-ordered but a Figure robot still cannot be bought, and there is work-cell success but no Rosie the Robot Y Combinator. The two startup plays pitched are (1) teleop-first "robotics application companies" that own end-to-end business problems Y Combinator, and (2) infrastructure to make world-action models fast enough and cheap enough to run on robots Y Combinator. The deepest bottlenecks cited are teleop data collection, memory/adaptation, reasoning data, sim-to-real dexterity, embodiment drift, and inference cost/latency Y Combinator.

What founders are building

• Rerun (Niko, co-founder/CEO, ~4-year-old company) is a "unified data layer for physical AI": open-source SDK for logging, visualizing, querying, and loading physical data, plus Rerun Hub as a cloud data catalog/backend Y Combinator. He argues physical data (multimodal, multi-rate, episodic, 3D-nested) is very different from web data and breaks normal table-based databases, so storage-layer choice drives a lot of operational friction Y Combinator.
• General Instinct (YC company) is building "infrastructure for you to run physical AI models really fast" — analogous to vLLM/SGLang for LLMs Y Combinator. Their optimizations: distill the VAE encoder-decoder, shrink/split the diffusion transformer, use cross-attention from the video transformer to the action transformer instead of decoding future frames, cut flow-matching sampling from ~50–100 steps to ~1–3 (≈50x speedup), and use KV-cache energy for asymmetric denoising Y Combinator. Target: run a 16-action chunk in ~500 ms on a Jetson Orin Y Combinator. Motivation: a world-action model otherwise needs two "GB 200" GPUs at ~$70k each, which the speaker calls economically unscalable for robotics Y Combinator. They chose infra over an application company because "eventually every model ... needs to go on the edge and needs to go in real time" Y Combinator.
• Robotics application companies / "neo-integrators": take ownership of a full business problem end-to-end, use as little custom hardware as possible, and often start with pure teleop plus fine-tuned models rather than foundation-model generality Y Combinator. Early traction areas: data centers, warehouse robotics, small-scale manufacturing, food; reliable-robot companies are described as "100% supply constrained" — demand is easy to fill, while labor is scarce and hard to manage Y Combinator.

Startup playbook and PM lessons (Niko)

• Start with a single customer problem someone will pay for; solve it teleop-first with off-the-shelf hardware, sell/deploy fast, because "the physical world is brutal" and lab work cannot anticipate all failure modes Y Combinator.
• If it works with teleop, generally a model can later learn it Y Combinator. Teleop-first also means many businesses (even robo-taxi) don't need full autonomy at launch; autonomy becomes a scaling factor, and data-scale needs are learned by plotting your own scaling curves rather than guessed Y Combinator.
• Fictional paper-plane factory illustrates the learning pattern: ~1,000 perfect planes/day viability; customers care most about speed of onboarding new designs; a simple paper tray cuts picking failures ~50%; a teleoperator needs ~20h of practice to meet demand (changes hiring/ops); adding pick-and-pack is ~10x more valuable; cheap research arms break and force supplier changes Y Combinator.
• Set up "basics for learning": fine-tune an open model (e.g., Pi) on a few hours of teleop demonstration; keep a replica of the customer environment in your office; build a repeatable, business-specific evaluation (sharp edges, symmetry, weight distribution); do eval manually first, then automate; track metadata and failure classifications — "good data is data that makes the model better" Y Combinator.
• Iterate constantly: do not collect all data upfront then train; even big-lab debugging often ends in "send a different instruction to your data collectors" Y Combinator.
• Moats come from non-model operations: sales, assembly, shipping speed, unboxing, support — things pure model companies won't do Y Combinator. Application startups with relatively little capital are already "making a lot of money" and growing fast Y Combinator.
• Why not billions of revenue yet: robotics is "death by a thousand cuts"; cheap ways to try applications are new, and only recently have arms and base models gotten cheap/good enough; lack of those basics forced general raises Y Combinator.

Technical constraints and metrics for PMs

• Teleop and data reality: collecting teleop demonstration data is "remarkably hard" and finicky; if the approach depends on scaling this data on gripper/wrist-camera setups, "we're kind of doomed" Y Combinator.
• Four unsolved walls: world models don't respect real physics (sim-to-real gap, deformable objects, action conditioning), action-space representation is unsolved, robots lack human-like sensing (one F/T sensor per fingertip vs. human nerve endings detecting force, moisture, temperature, vibration, friction), and embodiment drift (dust/corrosion/battery aging) makes teleop data stale and forces recollect/retrain Y Combinator.
• Long-horizon memory: state-of-the-art policies like PI0.5/Groot have no memory; useful tasks (full-bed cleaning, full meal) run tens of minutes while internship demos top out around 2 minutes; adding memory fixes endless dishwashing/burnt-grilled-cheese loops and enables in-context mistake correction, but naive memory hurts performance and training/inference efficiency Y Combinator.
• Reasoning: robotics is data-scarce, so annotated chain-of-thought is a data augmenter, but selective reasoning beats exhaustive reasoning; in manipulation, move/gripper-position reasoning helps while perceptual reasoning gets pruned; in self-driving, pruning hallucinated annotations lowers L2 path error/collision rates; "action forcing" lets you drop reasoning at inference to dodge latency Y Combinator.
• Sim-to-real dexterity: a single goal-conditioned RL policy trained on primitive objects/random goals runs at 60 Hz controlling a 22-DoF hand + 7-DoF arm zero-shot, generalizes to 12 unseen tools, and turns a new task into a new goal-pose sequence ("task prompt") — a new object/task in minutes instead of hours/days Y Combinator. Roughly 60% of failures come from pose tracking (not the policy) Y Combinator; recovery behaviors emerged because random forces in simulation forced re-grasping Y Combinator.
• Evaluation is a product problem: real-world eval is expensive and rarely statistically meaningful — "you can almost get a vibe check unless you run it truly 100 trials" (can't tell 90% vs 87%); teams build automated sim evals and still need human insight Y Combinator.
• WAM inference economics: world action models learn future kinematics from future video, but inference is heavy — a 16-frame chunk needs ~32 diffusion-transformer runs due to CFG, plus 50–100 autoregressive steps; distillation and latent-state approaches with no frame decoder are the fixes Y Combinator.

Tensions and gaps to flag

• Tension: Niko's thesis is "if you can solve something with teleop, generally you can train a model to do it" Y Combinator, while Tyler's sim-to-real work exists because "highly dextrous actions remain difficult to demonstrate reliably and at scale" via teleop Y Combinator. The transcript does not resolve where the boundary lies.
• Numeric inconsistency: flow-matching distillation is described as 1–2 steps in one place Y Combinator and 2–3 steps in another Y Combinator, both claimed without performance drop.
• Gaps: no revenue/ARPU data for application companies is provided beyond qualitative "making a lot of money" Y Combinator; hardware costs and deployment economics for teleop-first models are not quantified; most metrics are demo/lab-scale rather than production deployments.

Reddit PMs report a growing threat to PM roles from Forward Deployed Engineers (FDEs) using AI coding. An OP describes their CTO, inspired by Palantir, rolling out FDEs as a test; an FDE then built and deployed features without consulting the PM or dev team, and the department now routes everything through the FDE, while leadership reassures 'FDEs will not replace the PM role' r/ProductManagement. The same PM describes the FDE as a one-person PM/dev/QA using Claude to build, test, and deploy at very high speed, causing code conflicts with the core dev team r/ProductManagement.

Critics warn FDEs will be 'great for a year until the tech debt is due' r/ProductManagement, leaving unmaintainable solutions when the engineer leaves r/ProductManagement, and skipping evals, latency/performance testing, and security checks r/ProductManagement. Advice for PMs: focus on value propositions and customer needs, not on managing developers r/ProductManagement; embrace the FDE, bring them into the core team, and align their output with business priorities r/ProductManagement; and productize FDE work into a scalable platform roadmap r/ProductManagement. Some concede that if an FDE closes the idea-to-build loop faster, PMs could be skipped for minor deviations on mature products r/ProductManagement. A blunt take: if one FDE with Claude delivered more value in four months, the PM wasn't shipping what users needed r/ProductManagement.

Veterans see the model as a rebrand of Professional Services/solutions engineering: 'the technology changed. The organizational physics didn't' r/ProductManagement, though FDEs differ by being embedded in engineering and able to change the product and deploy to prod r/ProductManagement. The thread also debates internal vs external PM roles: internal PMs are at risk because 'there is no business to run' r/ProductManagement, while DevEx PMs argue internal products need managing even more due to organizational noise r/ProductManagement. Custom one-off builds lower gross margins from software's 70-80% to consulting's 20-30% r/ProductManagement. One PM reports being laid off possibly due to an FDE hired a month earlier r/ProductManagement.

Treat EOL/deprecation as a real go-to-market effort, not an engineering task: over-communicate via multiple channels (email, docs, login screen, in-app banner), set expectations on what will and won't work, and assume customers haven't read anything until they explicitly acknowledge it r/ProductManagement +3.

• Customers won't migrate voluntarily: notify paying/licensed customers in advance and honor existing contracts; expect ~90% to take no action until forced, even when migration is trivial; if you give an out, nearly everyone takes it, and customers will drag their feet and ask for extensions — churn risk is real r/ProductManagement +1.
• Timelines will slip: planned EOL dates rarely stick (one PM's Y2K fallback software was promised gone by 2003 but ran until ~2014); build buffer into the schedule and set a public deadline several months before the technical cutoff, expecting stragglers to complain for months after r/ProductManagement +2.
• Migration mechanics: for online products, trigger direct notifications right after active users first connect and repeat at intervals; if old and new products share a data source, let customers toggle between them during migration (Marty Cagan's 'Gentle Deployment'); if data sources differ, build a data-transfer interface so customers can run both in parallel on their own schedule; also define recovery steps ahead of time since undocumented dependencies on legacy systems are common r/ProductManagement +1.
• Sequence stakeholders before announcing: Legal first (contractual promises, regulatory/data obligations that survive EOL), then Finance (revenue already baked into projections, budgets, renewals; cost of keeping the product alive), Sales (bundles, renewals, multi-year contracts, pipeline deals, undocumented field promises), Marketing (campaigns and spend already planned), Customer Success (they absorb the backlash) and Support (what stays supported, escalation) — Engineering is the last conversation r/ProductManagement. Have one-on-one talks with key/anchor customers before the mass email to surface hidden workflows and dependencies; present the full chain of dates (end of sales, end of upgrades/development, end of support, end of life) and keep communicating as each approaches r/ProductManagement +1.
• Case study (B2B enterprise EOL, 2024): process took ~3 years, driven by a hard end date from third-party data contracts; communication ran through email campaigns, documentation, login screen and in-app banner; tracked customer database, feature usage, integrations and partners; Legal helped deprecate unused features early; after end-of-sales only security/data-export features shipped. The team shrank from ~60 devs to 3 devs plus a DB team, causing institutional-knowledge loss and stability strain; ~4,000 customers were moved off. The PM's biggest regret was not sharing more context with the dev team, who read the nontraditional PM work as laziness. No replacement product was offered r/ProductManagement.

• Product thesis & first product: Typeahead, a Mac AI autocomplete, is the first product from Hiten Shah and Sam Asante's thesis that the next wave of AI software will move closer to the user; local AI is faster, more private, and makes offline work possible by default @hnshah.
• Use-case selection: They started with writing because it happens everywhere on a Mac in small moments where a blank AI workspace or long prompt is too heavy; Typeahead's product decision was to offer inline suggestions inside the apps where writing already happens @hnshah.
• Lessons from v1 → 2.0: Inline help must feel fast, native, and controllable; voice matters most — "generating more text is easy. Helping someone finish the sentence they were already writing is the harder and more useful job" @hnshah. The filter for 2.0 became "Does this help the writer stay in flow?" and the strongest product decisions were those that kept the writer in flow @hnshah.
• Local as a product decision: Local wasn't added as a privacy feature; it was the product decision first, because writing contains sensitive context and if the Mac can run the model, writing should stay there by default — enabling faster suggestions, offline work, and a real boundary for the user @hnshah. Hybrid systems will still matter; the product question is where the default should live @hnshah.
• Pricing: Typeahead is a one-time purchase to feel like software you own; subscriptions make sense for hosted services, collaboration, storage, and infrastructure, but a local utility has a different shape @hnshah.
• User feedback & roadmap: Feedback centers on speed, suggestion placement, context understanding, and native feel; users also value local-only processing, offline use, and one-time purchase. The roadmap is to get faster, understand context better, and adapt to more writing places while preserving the trust boundary @hnshah.
• Second product: Their second product is almost ready after a year+ of work; it enters a crowded space, beta feedback drove several pivots, and it will be free to download with a free version expected to remain @hnshah. The product is being iterated in tandem with local AI model development — the idea has been evolving alongside the technology @hnshah.

Freelance or consulting experience builds product management skills — collecting product requirements and building iteratively — which can make former freelancers fit more easily into organizational structures than founders of established product companies, whose opinions may conflict with org priorities r/startups. When transitioning back to employment, a reputation for delivering (clients who can vouch for you) carries more weight than a title; such credibility comes from finishing things, not from having had a role r/startups.

A 24-year-old with a Product Design & Technology degree and about a year running his own startup r/ProductManagement joined a software company as an SDR and, within two months, exceeded KPIs and was given work beyond the role: building prospecting tools, helping with marketing campaigns, contributing to GTM strategy, and helping plan launch strategy for an acquired product r/ProductManagement. The company countered a competing offer with £40k base + £15k OTE + a larger-than-normal equity grant, and promised fast progression into a strategic closing role with someone reporting to him r/ProductManagement. The alternative offer is a Product Manager role in motorsport at £40k base with standard benefits — aligned with his degree and long-standing engineering/product/motorsport interests — but he is unsure whether the day-to-day is hands-on product work or admin/coordination-heavy, and less certain about progression r/ProductManagement. He frames his decision as fast-tracked commercial/sales leadership vs. a PM title in a passion industry, and is seeking input, especially from those who moved between sales/commercial and product/engineering careers r/ProductManagement.

A founder whose prototype is in regulatory review and who listed themselves as a senior employee on their resume is interviewing at a big company in the same space, hoping to gain income and learn how a top player builds and scales products r/startups. Advice from the thread:

• If the company is a direct competitor, the employment agreement may contain a moonlighting clause and other restrictive covenants; have counsel review before signing r/startups.
• Some companies publicly advertise a culture that encourages employees' side startups — mention the founder role there; otherwise keep it vague and frame yourself as a “lead” for the relevant portion r/startups.
• Keeping it vague is the smart call; if asked directly, don't lie, but you're under no obligation to volunteer founder status unless the title genuinely matters to the role r/startups.
• If the startup is in the same or a vaguely competitive space, the IP assignment agreement (EPIA) will result in either the company owning it or disclosure leading to a rescinded offer r/startups.

• In product domains where industry knowledge matters (e.g., finance, healthcare), PMs debating product network vs. domain network leaned toward the domain: knowing people in target companies aids job referrals better than a generic PM network, and vertical connections matter more than fellow PMs r/ProductManagement +2; several said build both if possible r/ProductManagement +1.
• Industry connections double as low-effort market research: access to new information through established relationships can lead to new product features and a competitive edge r/ProductManagement.
• When competitors and vendors are based in other countries, maintaining genuine industry connections is hard: LinkedIn feels superficial, and PMs seek other platforms for real relationships r/ProductManagement.

@hnshah (Hiten Shah) posted that chat has replaced dashboards as the product control plane @hnshah, endorsing @saturnial's view that 'dashboards are dead as a control plane' — users should 'just talk to the computer about what you want,' and 'the harness is the interface' @saturnial.

Paul Graham observes that much of his office-hours work with founders involves giving them "permission to do something simpler than they were planning to," often saying "You don't need to x. Just y." @paulg This exemplifies a useful product-management practice: explicitly authorizing simpler, scaled-down approaches to reduce scope and waste.

Hiten Shah: "You can vibe code the product. The user should never feel like you did." — building with vibe coding is acceptable, but the shipped product must not let users perceive that shortcut @hnshah.

Paul Graham asked a startup how fast they were growing before a launch-induced spike; they said 40% per week. He notes that 1.4^52 = 39.7 million, so no one can sustain that rate, but it shows users like the product. @paulg +1

Job offers can be rescinded even after you've given notice; one job seeker lost a $25K raise this way, and in coaching 160+ people over 12 months this scenario came up more than admitted Aakash Gupta. Prevention tactics: ask the recruiter if headcount is fully approved before signing, wait until the offer is signed AND background checks cleared before giving notice, and keep interviewing to have other irons in the fire Aakash Gupta. If your offer is pulled and you've already resigned, try to keep your current job by having an honest conversation with your manager ("I'm committed to this team"), and if that fails, get the rescission in writing and ask for 1-2 months pay for what you're giving up — big companies often agree Aakash Gupta.