We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI-native product teams are redesigning the artifact around shared context, not document volume. Together AI’s CPO says long AI-written documents now consume coworkers’ context rather than signal work. His team replaced 20-page PRFAQs with two pages plus a prototype, built a hierarchical shared-context repository, and keeps the PM accountable for the quality of anything AI produces. Their supporting tools synthesize support tickets and Gong calls daily so leaders can skim broadly and go deep selectively. Apply: make the prototype the primary alignment object, keep the decision brief short, and make context discoverable in layers; use AI to question and synthesize, not to own the decision.
More people can build, so product selection and coherence become the scarcer work. USV made Scott Belsky its first Product Advisory Partner to help portfolio companies with product, positioning, and experiences; the announcement argues that AI accelerates building while uncertainty about moats and consumer preferences makes resilient products harder. Hiten Shah’s parallel framing is blunt: every idea can now become a demo, so the PM must decide which ideas deserve to enter the product and make the whole experience coherent. A polished demo is therefore a weaker filter; the bar moves toward evidence, a clear product story, and disciplined inclusion.
Tactical Playbook
Map the operating system before accepting the feature request. When a business asks for a new website, first map Customer → Lead → Sales → Operations → Delivery → Reporting; classify each step as automate, integrate, custom-build, or leave alone. Prioritize the points where the business loses time, money, or information—not the visible software request.
Triangulate competitive intelligence, and separate discovery from validation. Competitor pages describe the narrative a company wants prospects to believe; reviews and communities can reveal customer language and failure modes, but may be biased and should not establish prevalence on their own. For a lean team, maintain a source registry spanning release notes, pricing, reviews, job posts, and sales-call mentions; normalize changes into a weekly digest tagged by segment and strategic impact, with confidence labels and source citations. Also watch quiet changes—removed features, softened claims, or new pricing footnotes—as possible signals.
Give AI a risk budget rather than a binary trust decision. One GTM practitioner is comfortable letting AI inspect performance data, flag falling activation, propose onboarding campaigns, and draft emails, but warns that reviewing every customer-facing change can become an approval queue. Define tiers: AI-only analysis and drafts; bounded actions under pre-approved rules; and human approval for new claims, audiences, or high-consequence sends.
Case Studies & Lessons
A deliberately strange B2B experiment converted attention into pipeline. A cloud-security startup built a fake toy store for CISOs, selling joke products such as a “CISO panic button.” The article reports that it cost almost nothing, drew 46,000 visitors in 24 hours, and produced hundreds of qualified leads. The lesson is not “be quirky”; it is to design a low-cost artifact around a recognizable customer identity, then measure qualified downstream behavior rather than reach alone.
Career Corner
B2B-to-B2C interview prep needs an evidence chain. One PM’s B2B habits—workflows, business rules, feasibility, and operational efficiency—were judged weaker on intuitive interface interactions. The practical adjustment is to start with the consumer problem and persona, then show key-flow events and KPIs, the hypothesis behind a change, and the experiment suited to the question—A/B, fake-door, Wizard-of-Oz, or another method.
Replace indiscriminate job-application volume with targeted outreach. A single current anecdote—not a market statistic—describes 6,000 applications over 12 months without a PM role. A career coach’s counterstrategy is to choose 20–30 companies where the candidate’s background is unusually relevant, contact employees with a tailored reason, and prioritize warm introductions over generic posts.
Tools & Resources
A structured growth-ideation bank. Lenny’s current collection contains 64 creative ideas organized by outcome—buzz, launches, word-of-mouth, leads, competitive moves, willingness to pay, and retention—and is explicitly designed to be fed into an agent for product-specific brainstorming. Use one target outcome to constrain the brainstorm, then test the cheapest credible idea.
- Use customer-facing teams to recruit, but keep discovery PM-led. In B2B, ask sales, account management, or support to nominate customers who match a precise persona and open the introduction; the PM should conduct the interview rather than delegate insight gathering to sales or marketing. Keep the referring salesperson informed, but avoid making them the exclusive go-between or filter for all customer communication.
- Use a tiered recruitment playbook. For existing customers, start with customer-facing teams; for a specific hypothesis, ask sales/support to identify candidates, send a 15-minute invitation, and provide a scheduling link, ideally clustering sessions on Mondays or Tuesdays. For non-customers, one practitioner suggests defining an ideal buyer persona and contacting 100 LinkedIn prospects, estimating 2–3 interviews per week in 4–5 hours and useful insights from fewer than 10 interviews; another reports LinkedIn outreach as time-consuming with about a 2% response rate, while a recruiting agency is an option when budget permits.
- Create repeatable feedback channels. A customer council can use a shared form or a CRM flag for customers willing to speak with Product; in-product or website prompts can recruit participants, with an incentive and short qualifying survey for public-facing requests.
- Improve interview signal before and during the session. Define the relevant jobs-to-be-done, user journeys, and problem before recruiting; review the customer’s account history and usage, bring only the PM plus one colleague when possible, keep the group to no more than three, and meet at the customer’s site or at a convenient time to minimize distractions and influence.
Choose discovery methods by cost of learning: Compare conversations, observation, sketches/prototypes, manual delivery, and working software based on what remains unknown and the cost of answering it. Five conversations can expose a bad assumption, observation can reveal details users omit, and manual delivery can test demand before software is built. When useful software is cheap enough, a real product may teach more through use than another week of discussion. AI has lowered the cost of researching markets, analyzing customer evidence, building, studying responses, and iterating, so the product can join customer research earlier without replacing it.
Beam case study: Beam started from an internal problem: using a window on another Mac required opening full Screen Sharing. The team built a small useful version quickly because they understood the workflow, had Mac expertise and testing machines, and could get the product into real use. Instead of asking whether people wanted “a better way” to access another Mac, Shah asked people on X to show their actual setups; more than 100 replied and 42 completed a baseline form. Twenty-nine interacted with another Mac several times a day, 28 kept the other Mac nearby, and only four usually wanted the whole computer while 18 wanted one application or a few specific ones. The evidence shifted the product understanding from generic remote access toward app-level access across nearby, specialized “personal Mac fleets.”
Validate replacement, not enthusiasm: After launch, ask, “If Beam weren't installed, what would you have done instead?” and observe whether Screen Sharing, another remote-access tool, or physically walking to the other machine disappears—and what users return to when Beam fails. Shah distinguishes compliments, signups, repeated use, replacement of an existing behavior, payment, and retention as answering different validation questions; replacement shows that the product displaced something, while retention shows whether it keeps earning a place in the user’s life. A founder can be customer zero, but must find people with the same problem, understand their current workflow, put the product into it, and watch what changes; Beam is testing this with free access for early users in a small X group.
- A fresh-grad Product Analyst in adtech reported that heavy company-specific terminology, sparse documentation, and limited manager/mentor bandwidth made the initial ramp feel overwhelming and left them unsure about performance. The suggested response is to allow time for context-building, focus first on one important end-to-end flow, and learn the product, industry, users, and problems before trying to master everything.
- Make onboarding explicit: set clear goals with the manager and document what you learn and do; choose one or two role-relevant areas, map how the product works and whom it serves, identify user problems, share findings with the manager, and agree on an effective way to exchange notes.
- Build context deliberately by whiteboarding the stack, tools, and workflows; mapping stakeholders and knowledgeable peers; and maintaining a glossary of abbreviations. AI can help explain jargon and local systems, but its answers should be verified because it can make mistakes. Taking on selected manager activities and repeatedly asking why the work and approach were chosen can accelerate learning and surface pain points.
- Use the cost of learning to choose the next discovery method. Start with the least expensive method that can answer the current uncertainty—conversation, observation, manual delivery, prototype, or software—and move the product into real use earlier when building is cheap enough to generate better evidence; AI has lowered the cost of building, researching, and iterating on customer response.
- Beam shows how an early product can become part of research. The team started from its own multi-Mac workflow problem, built a small usable version, then asked people to show their existing setups rather than asking whether they wanted a hypothetical solution. More than 100 people replied and 42 completed a baseline form; 28 kept the other Mac nearby, while only four usually wanted the entire other computer and 18 wanted one app or a few specific apps. This shifted the problem framing from generic remote access toward friction at the boundary between machines.
- Validate behavior change, not enthusiasm. Track what the product replaces—such as a Screen Sharing session, another remote-access tool, or walking to another machine—and ask, “If Beam weren't installed, what would you have done instead?” The evidence bar rises from compliments to signups, repeated use, disappearance of an existing behavior, payment, and retention. A founder can be customer zero, but must then find people with the problem, understand their current workaround, put the product into that workflow, and observe what changes.
- Use unconventional, low-cost experiments to break through crowded acquisition channels: A cloud-security startup built a fake toy store for CISOs, selling joke products such as a “CISO panic button.” The stunt generated 46,000 visitors in 24 hours and hundreds of qualified enterprise leads, despite being designed primarily to earn attention.
- Turn outbound prospecting into customer discovery: Select 8–10 ideal customers, apply the product or service to their situation, and send them a useful report, audit, or analysis instead of asking for a demo. Vanta sent Segment a custom SOC 2 gap assessment before Vanta had a product; Segment became a design partner that helped shape the company.
- Reduce activation friction with self-serve product experiences: Replace or supplement “Book a demo” with a no-signup playground that lets prospects reach an aha moment without providing an email or credit card; the examples given are Plausible’s live analytics dashboard and Linear’s demo workspace.
- Use narrow free tools as acquisition wedges: Strip one product capability down to a single free interaction with no signup requirement. Wordware’s free X-profile roasting tool reportedly attracted 8.1 million users and more than 400,000 signups for the core product.
- Treat conversion improvements as experiments: Adding a blurred product screenshot behind a signup form increased conversion by 25% in one reported A/B test, suggesting that curiosity and a sense of progress can be tested as signup motivators.
- Design referral and ambassador mechanics explicitly: An open ambassador program can recruit many small creators, pay based on impressions, and avoid follower or content-approval requirements; tl;dv’s example paid $100 per 20,000 views, capped at $700 per post, and reported more than 10 million monthly impressions.
- The PM artifact is a shared product story, not merely a specification. The story should explain who will use the product, why it matters in their lives, and how the experience should feel; it must be immediately understandable and repeatable without the PM present. AI changes the workflow from idea → spec → scope → build to quickly build a prototype, play with it, design the real product, then ship and learn. Because prototypes are cheap but production-quality products are not, PM judgment should focus on product coherence and impact rather than simply whether an idea fits the schedule or available resources.
- Use Purpose–Core actions–Cycle to define product vision and measurement. Specify why users choose the product, what they actually do with it, and how often each action should occur. Evaluate usage through direct, intentional traffic and completion of meaningful core actions—not just signups, DAU/MAU, waitlists, revenue, or brief app opens.
- Design onboarding for the curious middle of the user distribution. Introduce the product step by step with simple, discrete actions; repeat the core message, explain why nonessential information is requested, and teach each key concept through a clear user action. For AI products, replace the blank prompt with concrete capability examples and get users to a valuable use case quickly, ideally using their own data. Judge onboarding variants by next-day or next-week retention and core-action adoption, not by how many users reach the end of the flow.
- Twitter’s onboarding rebuild illustrates the approach. Millions of people signed up after hearing about Twitter but did not return because they could not explain what the product was or what to do after signup. The Learn Flow taught the product one concept at a time—following accounts produced tweets in a timeline—and improved retention more than anything else Twitter shipped that year.
- For AI products, treat user transcripts as product research. Read the user’s exact prompts, rephrasing, and abandonment moments to identify unmet expectations; use AI to surface patterns, but retain human judgment about what the product story actually is.
- For launches and growth campaigns, consider an “anti-professional” tactic: deliberately break a professional norm in public—for example, discuss what roles actually pay or admit that a big launch failed to meet internal expectations—to stand out from polished professional content.
- The rationale is that unexpected executions can be shared organically, remain memorable longer, and usually cost less than a week of ad spend than conventional channels such as high-production launch videos, paid influencers, social, and events.
TokenCompass is building a measurement layer for AI at work to help leadership teams understand AI spend and usage and budget tokens across human employees and agents; the product is currently in private beta. Its stated product rationale is that companies need tools to plan and make informed financial decisions about token spend, pointing to token-cost visibility and allocation as emerging requirements for enterprise AI products.
- Separate attention from adoption: The discussion cites 90% U.S. awareness versus 11% use for GLP-1s, and 95% crypto awareness versus 14% ownership. In a sample of about 960 TikTok videos about peptides, posts fell into promotional, personal-exploration, educational, and skeptical-warning categories; skeptical warnings represented about 19%, while promotional content increasingly converged with personal-experience content as adoption grew. PMs can use awareness-versus-use data and social-content composition to avoid treating virality as product demand.
- Watch for productized demand as a maturity signal: Protein quantities had not changed, but brands began prominently featuring protein on yogurt packaging because consumers were actively looking for it. A trend may be reaching the mainstream when it changes product positioning or merchandising, not merely when it generates online discussion.
- Map origin communities and adoption lag: The speakers argue that peptide culture began in American Heartland and bodybuilding communities before being professionalized or accelerated in Silicon Valley. Wearables similarly took a long adoption path—Fitbit launched in 2007, Apple Watch in 2015, and broader uptake followed through product development and slow adoption. PMs evaluating emerging categories should distinguish the originating user community from the later high-visibility scaling channel.
- Lenny’s growth thesis: when competitors rely on the same high-production launch videos, paid influencers, AEO, social, and events, unexpected tactics are more likely to be shared organically, remembered for months, and usually cost less than a week of ad spend.
- Tom Orbach’s collection of 64 growth ideas is organized around seven outcomes: generating buzz without paid ads or influencers, making launches stand out, encouraging word of mouth, increasing leads and conversions, outsmarting competitors, increasing what customers will pay while keeping them happy, and improving retention.
- A practical ideation workflow is to feed the collection’s Markdown version into an AI agent to brainstorm growth ideas tailored to a specific product and its goals.
- AI makes building an individual feature cheaper, but production-quality delivery remains costly: treating coding agents as “free” can produce spaghetti code, Frankenstein data models, duplicated code, feature bloat, performance problems, and downstream maintenance work. Skilled engineers must still observe and steer AI-generated output, and architecture decisions cannot be outsourced to coding agents.
- Separate build to learn from build to earn: use cheap, throwaway prototypes for discovery, but actually discard them instead of treating them as production-ready foundations.
- AI products require substantial product and engineering work beyond the demo, including error analysis, evaluations, LLM-as-judge processes, and repeated prompt/orchestration iteration. Reaching a good-looking prototype may be fast, while closing the final 30% to a trustworthy product can take months or years; delivery became cheaper, not free, so discovery and delivery both remain essential.
- Lenny Rachitsky argues that teams relying on high-production launch videos, paid influencers, AEO, social, and poorly attended events are competing for the same channels and attention. His counterstrategy is to pursue unexpected growth tactics that earn organic sharing, remain memorable, and can cost less than a week of ad spend.
- Tom Orbach’s collection contains 64 creative growth ideas organized around seven objectives: generating buzz without paid ads or influencers, making launches stand out, prompting word-of-mouth, increasing leads and conversions, outsmarting competitors, increasing customers’ willingness to pay, and improving retention.
- A company without a formal PM/PO function is falling behind on release notes, user and stakeholder updates, roadmap editing and prioritization, user-feedback management, UAT, launch communications, and knowledge-base updates; budget constraints are driving consideration of fractional or part-time help.
- The discussion distinguishes strategic fractional PM work from execution-heavy part-time support: one recommendation is to retain roadmap prioritization and potentially user-feedback ownership internally while automating or redistributing routine updates, knowledge-base maintenance, UAT coordination, and release communications.
- A proposed staffing split assigns a motivated junior/full-time hire to release notes, stakeholder and user communications, launch messaging, and knowledge-base updates, while a fractional senior PM handles roadmap prioritization, user feedback, UAT, competitive analysis, and coaching the junior hire.
- Suggested implementation practices include defining explicit goals and deliverables like an outsourced QA engagement, separating research/analysis/recommendation work, standardizing communication templates and processes, tapering an initial full-time engagement to three then two days per week, and embedding workflows so the team can continue after the specialist leaves.
- For a first-time PM managing multiple products in a niche industry with outsourced development, establish a lightweight operating system: maintain a living glossary and stakeholder map; keep a one-page snapshot for each product covering its goal, commitments, risks, and next decision; and create a delivery rhythm with written acceptance criteria, regular demos, and a decision log. These practices help the PM learn, prioritize, and make uncertainty visible.
- Core habits recommended for reducing ambiguity are to start from first principles, define measurable success criteria before beginning an initiative, focus on customer/user/business problems rather than presumed solutions, ask questions, and understand end-user pain points.
- Community responses offer a career reality check: PM overwhelm may change form rather than disappear, with respondents reporting continued overwhelm after 10 or 20+ years and, in one account, greater stress at senior levels than as a junior.
- “Customer zero” is a starting point, not validation. If a founder has lived with a problem deeply and can build a useful version without a large bet, they can start with their own workflow—but must then find people who already have the problem, understand their current behavior and workarounds, put the product into that workflow, and observe what changes to earn “customer one.”
- Choose discovery methods by learning cost, not habit. Conversations, observation, manual delivery, prototypes, and working software answer different questions; five conversations may expose a bad premise, while a cheap product can reveal more through real use. AI has lowered the cost of building and iterating, making the product itself viable as an earlier research instrument, while customer research remains necessary.
- Beam illustrates behavior-led discovery. Shah’s team began with its own need to access apps running on another Mac, then collected 100+ X replies and 42 baseline responses. Of those respondents, 29 interacted with another Mac several times daily, 28 kept the other Mac nearby, and 18 usually wanted one application or a few specific apps rather than the whole computer—evidence that reframed the opportunity from generic remote access toward lightweight, app-level access.
- Prioritize evidence of replacement over expressed interest. The strongest validation is seeing an existing workaround disappear—such as fewer Screen Sharing sessions, less use of another tool, or no longer walking to another computer—followed later by payment and retention. After adoption, ask, “If the product weren’t installed, what would you have done instead?” to identify what it actually replaced.
- B2B PMs moving into B2C should start with the consumer problem and persona, then demonstrate empathy for users who are less tolerant of interface friction; B2C interviews place greater weight on intuitive experiences, outcomes, and experimentation than on workflows, business rules, backend feasibility, and operational efficiency.
- Build interview examples around a clear evidence chain: instrument key user flows with events and KPIs, identify the data or customer feedback that prompted a change, state the hypothesis, choose an appropriate experiment, and explain how the result validated or disproved it. Useful practice areas include root-cause analysis and growth cases.
- Treat experiments as learning rather than proof: select the lightest method suited to the question—such as fake-door, Wizard-of-Oz, multivariate, or qualitative comparisons—and minimize engineering effort while testing. A/B testing can also mean comparing versions qualitatively across users or iterating from version A to version B when automated telemetry is unavailable.
- A QA Team Lead at Accenture with approximately six years of testing experience is considering a transition into Product Management. They report transferable experience in product requirements, user impact, Product/Engineering collaboration, sprint planning and estimation, feature decomposition, release support, cross-team coordination, and mentoring; they are more motivated by understanding problems, user needs, trade-offs, and what to build than by testing the finished product.
- The stated preparation gap is a lack of formal product ownership experience, including roadmap and product-metrics responsibility. The poster is weighing paid structured training against self-study, case studies, and projects.
- A PM four months into a new Indian fintech role reported that personal issues had reduced availability and performance; although they had identified high-impact problems and aligned leadership, execution was slower than expected, raising concerns about internal perception and job security.
- Recovery expectations vary by company: four months may still be onboarding in some organizations but may be considered a long time in others. If the setback was isolated, the recommended response is to focus on execution and deliver value over the next 6–8 months.
- Once performance shows an upward trend, have a candid conversation with the manager and potentially a skip-level leader about what happened. The advice also warns that termination remains possible in highly cutthroat companies, making rapid improvement in the performance trajectory the immediate priority before repairing the internal narrative.
- An internal platform team at a multi-billion-dollar company reports that nearly every stakeholder initiative is now an AI agent or LLM-based solution. The team has no clear customer demand for next year, expects to spend the next six months in keep-the-lights-on mode, and worries that agent-heavy product work could reduce teams to human-in-the-loop support, minor tuning, and configuration. This is an anecdotal signal that generative AI may compress the scope and staffing of some product organizations.
- Community counter-signals highlight risks to validate before treating this as a settled operating model: AI adoption may create technology debt and depend on venture-subsidized token costs, while agents may be “solutions looking for problems.” Another commenter argues that simply reacting to inbound requests was never a full product function, implying PM value should shift toward problem selection and product direction rather than disappear.
- Use discovery questions before accepting stakeholder requests: clarify the intended outcome, KPIs, operator, formal plans, leadership sponsorship, deadline flexibility, and what existing work should be deprioritized before moving into solution mode. This can reveal that a request is less important or insufficiently thought through, while framing pushback as partnership rather than gatekeeping.
- Make scope transfers explicit: when work falls outside the team’s responsibility, ask which existing commitment should move, who owns the trade-off, and where the scope decision is documented. A short weekly alignment with the managing engineer can establish boundaries in advance; visible prioritization decisions are preferable to quiet scope transfer.
The Product Can Become the Research
I almost never build software because I personally want it. For most of the last twenty years, I’ve treated my own frustration as evidence of one customer. I still had to find out whether anyone else cared.
That bias made sense when software was expensive to build. You could spend months turning an assumption into a product before customers had anything real enough to react to. By then you had already spent the time and money, and the thing you made had started to feel true simply because it existed.
So I learned to understand the problem first. I wanted to see what people were already doing, especially the workarounds they had created without us. Those were useful because somebody had cared enough to solve the problem before we showed up. I wanted to know how often it happened, what made the current way frustrating, and why people kept doing it anyway.
I still believe in all of that.
I am changing my mind about how early the product itself can become part of the learning.
There has never been one right place to start
Products come from all kinds of places.
Sometimes you notice a broken process. Sometimes a new capability makes an old idea possible. Spend enough time around a problem and you may see something people who encounter it occasionally never notice.
Sometimes the problem is your own.
Eric von Hippel started studying people like this decades ago. He called them lead users. They experienced needs earlier than much of the market and sometimes built their own solutions because the problem already mattered enough.
Software has a simpler phrase for it.
Scratch your own itch.
37signals has built around this instinct for years. When you are the user, you know much more than the fact that the problem exists. You have lived through all the tiny moments around it. You know which annoyance gets worse with repetition, which workaround is strangely good, and which part everyone assumes matters but barely affects the experience.
That knowledge can be incredibly useful. It is still knowledge about you.
Someone has to find out whether the problem extends beyond your own life.
That is why I have always leaned so hard into customer development. My own experience can tell me where to look. Other people help me decide whether to keep going.
The thing I had not reconsidered enough was the cost of getting something real into their hands.
The cost of learning shapes what you do first
You can learn about a product in a lot of ways. Talk to somebody. Watch them work. Sketch the idea. Make a prototype. Provide the outcome manually. Put actual software into their workflow.
For most of the time I have been building companies, those things had very different costs. A conversation could happen this afternoon. Useful software might take months.
So you answered the cheap questions before committing to the expensive ones.
That was one reason customer research became such an important muscle for me. If five conversations could expose a bad assumption, finding out before we built around it could save months of wasted work.
That logic still makes sense.
What changed is how much the build costs.
AI did not invent prototypes, early products, or learning from customers. All of that has been happening for a long time.
It made getting to useful software much cheaper.
The change reaches beyond code. We can research a market faster, work through piles of customer evidence, build the site, change the product, study the response, and turn what we learn into another experiment with much less effort than before.
Sometimes building is now the fastest way to learn.
Beam is where that became real for me.
Beam started as our problem
We build Mac apps, so we have a bunch of Macs around for development and QA.
We kept running into a small problem. Something we needed would be running on another machine, and we would open Screen Sharing just to use it for a few minutes.
@SamAsante started building around a simpler idea. If a window is running on that Mac, it should be able to live on this one.
That became Beam.
We knew the problem because we were living with it. We also knew how to build Mac software, had useful scaffolding from other products, and owned plenty of machines to test with.
The first useful version was a small enough bet that Sam could make it and we could start using it.
A few years ago, I probably would have wanted more external validation before letting the product get this far.
This time we had something real soon enough that it could help us figure out whether the idea traveled.
Once Beam existed, we could ask better questions
We could have asked people whether they wanted a better way to use another Mac.
I am not sure what a yes would have told us.
Instead, I asked people on X to show me their weird multi-Mac setups.
More than 100 people replied. Forty-two filled out a baseline form about how they already worked. We asked what the other Mac did, how often they needed it, what they opened there, and how they reached it today.
Now we had behavior to study.
Twenty-nine of the 42 interact with another Mac several times a day. Another four do it about once a day. Tailscale showed up in 33 setups, SSH in 26, and Apple Screen Sharing in 25. Seventeen people said they sometimes just walk over to the other computer.
The number that changed how I thought about the problem was 28.
That is how many keep the other Mac on the same desk or somewhere else in the same house or office.
I had been thinking about remote access. A lot of these people barely had any distance to overcome.
The computer could be a few feet away and they had still built systems around getting in and out of it.
We saw something similar when we asked what they wanted once they got there. Only four people said they usually wanted the whole other computer. Eighteen said they generally wanted one application or a few specific ones.
That sounded a lot like the problem that produced Beam.
The descriptions were even better than the numbers. One person talked about dealing with an entire remote desktop canvas just to touch one app. Someone else used a more powerful Mac mini less than they wanted because getting into it was annoying enough to change their behavior.
We started with our own problem. Now we could see where it overlapped with other people’s lives.
Then the replies showed us something we had not been looking for.
The other Macs had jobs
A lot of these computers are doing something even when nobody is sitting in front of them.
People are running agents, Xcode, local models, automation, browsers, research, builds, media work, and services that stay on.
The interesting moments happen when one of those machines suddenly needs a person. An agent reaches a login screen. macOS asks for permission. A browser needs authentication. Someone needs to inspect an application before the work can continue.
One person described a spare Mac driving a browser all day. Compute was easy. Eventually the browser needed something only the person could provide.
I had started calling these setups personal Mac fleets somewhat jokingly. The phrase made more sense the longer I looked.
Some of these computers have become specialized machines with jobs of their own. They can keep working without somebody sitting in front of them until one small part of the job needs a human.
That gives Beam a much larger context than the QA problem that caused us to build it.
It still does not tell us whether Beam is any good.
For that, I want to see what changes.
The strongest evidence is what disappears
I care less about somebody telling me they like Beam than I do about what they were doing before Beam existed.
If someone has opened Screen Sharing five times a day for the last year, the problem already has a history. If they put together some strange combination of SSH, Tailscale, VNC, and physically walking over to another machine, they found a solution long before they knew we existed.
Now Beam can enter that workflow.
Maybe a Screen Sharing session disappears. Someone stops reaching for Jump Desktop for one particular task. A person stays in their chair instead of walking over to the Mac mini.
Sometimes Beam will lose too. I want to know what people go back to when that happens.
The question I care about after somebody actually uses Beam is simple.
If Beam weren’t installed, what would you have done instead?
That tells us what Beam replaced, if anything.
The answer may be another product. It may be some ugly series of steps nobody would ever put on a competitor slide.
Before Beam existed, we could study the problem and the workaround. Once it is inside the workflow, we can see whether the behavior changes.
That is the kind of evidence the product can create.
It is also why cheap building can be dangerous.
Cheap building raises the bar for evidence
It has become incredibly easy to make a weak idea look real.
You can have a polished product before anyone has established that the workflow matters. The website can look finished. The demo can work. AI can research the market, help with positioning, write the launch, and produce an analysis explaining why the first response looks promising.
A lot can happen around an idea while almost nothing changes for the customer.
I think this is going to fool a lot of us.
When building was expensive, plenty of bad ideas died because pursuing them cost too much. Cheap building lets more of them survive long enough to look convincing.
So the quality of the evidence matters more.
A compliment tells me one thing. A signup tells me another. Repeated use is different again. When an existing behavior disappears, we have learned that the product replaced something. Payment answers a later question. Retention tells us whether the product keeps earning a place in someone’s life.
The easier it becomes to build everything around an idea, the more careful we have to become about what we choose to believe.
When the cost of an experiment changes, its place can change too
Five conversations may be the fastest way to discover that your premise is wrong.
Watching somebody work can reveal the small things they would never remember to mention.
Providing the outcome manually may tell you whether anybody cares before you write the software.
A useful version may now be cheap enough to teach you more in real use than another week of talking about it.
What matters is what you still need to learn and what it costs to learn it.
For much of the last twenty years, useful software was expensive enough that I wanted substantial evidence before building it.
Now there are cases where the software itself can help produce that evidence.
Customer research still matters.
The product can join it earlier.
That brings me back to my own problem.
You can be customer zero. Then you have to earn customer one.
I still do not think my frustration proves there is a market. It tells me I experienced something worth investigating.
If I have lived with the problem long enough to understand it unusually well, and I can make something useful without placing a huge bet, I am more willing than I used to be to start there.
Then the idea has to leave my world.
Find people who already had the problem. Understand what they do today. Put the product into that workflow and watch what changes.
Then we see whether the evidence keeps getting stronger.
Customers still get the final vote.
What I have changed my mind about is how early the product gets to join the conversation.
You can be customer zero. Then you have to earn customer one.
Scratch your own itch. Ship it. Then find out how many other people are scratching the same place.
I’m testing this with Beam right now
The first 42 people have already helped us see where our problem overlaps with theirs. Now we want to learn what changes when Beam enters those setups.
I’m bringing the early users together in a small X group and giving them Beam free while we learn from how they use it.
If you regularly use more than one Mac and need something running on another one, you can join us.
Join Beam Early Users → https://forms.gle/632FRNSred4EtCu8A (opens in new tab)
Choose discovery methods by cost of learning: Compare conversations, observation, sketches/prototypes, manual delivery, and working software based on what remains unknown and the cost of answering it. Five conversations can expose a bad assumption, observation can reveal details users omit, and manual delivery can test demand before software is built. When useful software is cheap enough, a real product may teach more through use than another week of discussion. AI has lowered the cost of researching markets, analyzing customer evidence, building, studying responses, and iterating, so the product can join customer research earlier without replacing it.
Beam case study: Beam started from an internal problem: using a window on another Mac required opening full Screen Sharing. The team built a small useful version quickly because they understood the workflow, had Mac expertise and testing machines, and could get the product into real use. Instead of asking whether people wanted “a better way” to access another Mac, Shah asked people on X to show their actual setups; more than 100 replied and 42 completed a baseline form. Twenty-nine interacted with another Mac several times a day, 28 kept the other Mac nearby, and only four usually wanted the whole computer while 18 wanted one application or a few specific ones. The evidence shifted the product understanding from generic remote access toward app-level access across nearby, specialized “personal Mac fleets.”
Validate replacement, not enthusiasm: After launch, ask, “If Beam weren't installed, what would you have done instead?” and observe whether Screen Sharing, another remote-access tool, or physically walking to the other machine disappears—and what users return to when Beam fails. Shah distinguishes compliments, signups, repeated use, replacement of an existing behavior, payment, and retention as answering different validation questions; replacement shows that the product displaced something, while retention shows whether it keeps earning a place in the user’s life. A founder can be customer zero, but must find people with the same problem, understand their current workflow, put the product into it, and watch what changes; Beam is testing this with free access for early users in a small X group.
- Use the cost of learning to choose the next discovery method. Start with the least expensive method that can answer the current uncertainty—conversation, observation, manual delivery, prototype, or software—and move the product into real use earlier when building is cheap enough to generate better evidence; AI has lowered the cost of building, researching, and iterating on customer response.
- Beam shows how an early product can become part of research. The team started from its own multi-Mac workflow problem, built a small usable version, then asked people to show their existing setups rather than asking whether they wanted a hypothetical solution. More than 100 people replied and 42 completed a baseline form; 28 kept the other Mac nearby, while only four usually wanted the entire other computer and 18 wanted one app or a few specific apps. This shifted the problem framing from generic remote access toward friction at the boundary between machines.
- Validate behavior change, not enthusiasm. Track what the product replaces—such as a Screen Sharing session, another remote-access tool, or walking to another machine—and ask, “If Beam weren't installed, what would you have done instead?” The evidence bar rises from compliments to signups, repeated use, disappearance of an existing behavior, payment, and retention. A founder can be customer zero, but must then find people with the problem, understand their current workaround, put the product into that workflow, and observe what changes.
- “Customer zero” is a starting point, not validation. If a founder has lived with a problem deeply and can build a useful version without a large bet, they can start with their own workflow—but must then find people who already have the problem, understand their current behavior and workarounds, put the product into that workflow, and observe what changes to earn “customer one.”
- Choose discovery methods by learning cost, not habit. Conversations, observation, manual delivery, prototypes, and working software answer different questions; five conversations may expose a bad premise, while a cheap product can reveal more through real use. AI has lowered the cost of building and iterating, making the product itself viable as an earlier research instrument, while customer research remains necessary.
- Beam illustrates behavior-led discovery. Shah’s team began with its own need to access apps running on another Mac, then collected 100+ X replies and 42 baseline responses. Of those respondents, 29 interacted with another Mac several times daily, 28 kept the other Mac nearby, and 18 usually wanted one application or a few specific apps rather than the whole computer—evidence that reframed the opportunity from generic remote access toward lightweight, app-level access.
- Prioritize evidence of replacement over expressed interest. The strongest validation is seeing an existing workaround disappear—such as fewer Screen Sharing sessions, less use of another tool, or no longer walking to another computer—followed later by payment and retention. After adoption, ask, “If the product weren’t installed, what would you have done instead?” to identify what it actually replaced.