I think applied AI looks similar. We’ve seen plenty of successful enterprise and B2B AI products, but far fewer consumer-facing ones. At the same time, I think AI is different enough that the consumer side may have different potential this time.

I recently listened to a podcast from a16z where partner Anish Acharya shared several insights about consumer AI. This post is a mix of what stuck with me from the episode and my own reactions to it.

Why Consumer AI Was Held Back

According to Anish, these were the three reasons why consumer AI growth may have been slower.

1. No app store or marketplace distribution channel

I think what ignited the consumer mobile app market was the marketplace: having the right channel for distribution. It became extremely easy for individuals and companies to list a game, a social app, or anything else and get engagement. A similar thing happens in certain software scenes. CRM products, for example, can launch on the Salesforce AppExchange to solve a small subset of problems in the sales pipeline within the Salesforce environment. The existence of these channel platforms is what drives the exponential growth of new products, and there really hasn’t been an equivalent for consumer AI.

2. Consumers don’t like paying for software

This is probably what stalled growth in consumer software too. I used to build a document and knowledge management tool for consumers called Typed. It was aimed at students and individuals who wanted to boost their writing productivity by seeing how their documents connect, adding references to the documents they were writing, and so on. It solved some real problems, but willingness to pay was so low that it didn’t make sense as a product. We had to pivot to B2B and sell to startups as a collaboration tool.

Anish points out that consumers don’t care much about productivity. I think that’s largely true. Some consumers do care, but even then their willingness to pay is low, and paying for software at all is rare. According to coverage of a16z’s latest Top 100 consumer AI apps report, only about 4.5% of consumers actually pay for a subscription to ChatGPT, Gemini, or Claude.

3. AI products have a real marginal cost per user

Classic consumer software like Facebook and Instagram costs almost nothing to serve one more user, so you can do plenty to grow virally and monetize later. For the previous generation of consumer apps, the model was free viral growth with ads as the monetization.

AI products are different. Every query burns inference compute, so adding free users adds real cost almost immediately, and the free growth hacks that worked for the post-dotcom apps don’t necessarily work anymore. Coupled with the second point, if consumers don’t pay for software, you can’t easily cover per-user costs with subscriptions either.

Why Consumer AI Can Be Different from Traditional Consumer Software

I’ve been using personal AI agents like Muse and Dots a lot lately, and I’m realizing how much more potential this consumer space has.

Some of my thoughts here: What set traditional software apart was that it solved productivity problems, like cutting the time it takes to write something by a few hours with a split-screen view. That matters for companies, which can measure it. For consumers it’s hard to measure and often doesn’t matter much. A product that makes file organization easier might be nice, but consumers usually won’t pay for it.

LLMs do more than boost productivity. They can take actions on your behalf and create outcomes. This ties back to why many agentic products are moving toward outcome-based pricing, rather than usage-based pricing or a typical flat subscription.

If there are problems consumers just want to get done, rather than get a little help with, that may be what opens people’s wallets. Consider Expedia, which shows you different flight options. A consumer AI product could research, track, and book the flight on its own, plan out the itinerary, and book other things along the way, with the user’s confirmation. It’s solving the problem by taking action, not just assisting.

Or take an app that reminds you to take your medicine or lists doctors and providers in your neighborhood. A personal health assistant that books the doctor’s appointment, follows up, and sets a recovery routine for you brings a different kind of value.

These all work because they let the product:

1. Connect to and call different tools across services
2. Understand your need, instead of following a deterministic path set in advance
3. Not only generate language, but take action

Understanding What Consumers Get Excited About

One point Anish made that stuck with me is that consumer AI products should feel like opening Christmas gifts like the iPhone in 2009. New products are flowing in, and some will stick while others won’t. But at a time like this, we want to see something exciting and new.

I still remember unboxing the first iPhone I had, playing around with it, and being completely mesmerized. Consumer products have to bring that charm, not just a cost reduction or some metric-driven value. That’s something consumer AI can do, which means how you package and deliver it matters a lot for consumers too.

Maybe the real test for consumer AI isn’t whether it makes us more productive, but whether it makes us want to open the box.

I remember as a student, whenever I got an assignment, the first thing I did wasn’t start writing, solving problems, or doing research. It was reading the grading rubric. Two reasons: I’d know what “success” (getting an A that term!) actually looked like, and I’d know exactly what to do to perform better, since there were usually several criteria, not just one. There were times when a teacher or professor graded my paper with just a score, like 85%. That left me confused, because it didn’t help me actually improve for next time. Was my research not deep enough? Was it not clearly structured?

I’m learning this concept holds true in LLM evals. When writing evals, it’s usually not enough to have a single pass/fail on the end result a pipeline outputs. Most LLM workflows are pipelines with multiple prompt chains, multiple agents, or model calls doing different things: classification, judgment, execution, generation. You need a grading rubric that covers all of it.

What an Eval Case Consists Of

An eval case consists of an input, an expected output, an actual output, a threshold, and an actual score.

An input is like the question or problem a student must answer. An actual output is like the student’s submitted answer. That gets graded against the expected output.

An expected output is like the answer key. For grading papers, some rubrics have set expected answers, especially in science or math. Is the answer “10”? Does it include the deterministic scientific fact it needs to? Similarly, for some LLM evals, correctness is deterministic or binary. For a healthcare prior authorization agent, did it identify the right CPT code? Is it 70551? For cases like these, scores are pass or fail, 0 or 1.

For a research paper rubric, grading tends to be less deterministic, focused on whether the content covers the right ground or lands in the desired tone. The same is true for some eval cases. Did the customer support response strike a polite but non-apologetic tone? For cases like these, scoring can fall on a scale between 0 and 1 (say, 0.8 for tone).

What to Measure

So what are you actually measuring? What criteria and rubrics should go into an LLM eval set for an AI solution or agent workflow?

This depends heavily on context, so the first step is figuring out what overall success looks like for the job you’re trying to do with AI.

Say there’s a retail return support agent that decides whether an item can be returned and processed automatically, or needs to be flagged for human review. The business goal might be cutting the cost of manual review, so you’d be tempted to track only whether a ticket was completed by AI. But there’s more risk than that. A ticket that should’ve gone to human review but gets auto-processed for return can be costly. Imagine someone tries to return a $5,000 couch, claiming it’s “not comfortable enough” after using it for months, and attempts to abuse the AI agent to force the return. The agent shouldn’t give in. It should flag it. In that case, the false negative rate (a return getting processed when it shouldn’t) needs to be in the rubric, likely with a stricter threshold.

Here are some grading rubric categories I’d include, along with a note of caution on thresholds:

Task completion

• Completeness: Was the job done? Was it able to complete the task? This isn’t always aiming for 100%, since you may deliberately want the model to reject a task or escalate it.
• Refusal rate: Was the job refused by the model’s guardrails? Important to track. If it’s too low, guardrails may not be working.
• Consistency: An LLM call is non-deterministic, meaning the same input can produce different outputs. Is the output consistent?
• Tool call accuracy: Did it call the right tools for the given task?

Task accuracy

• Correctness: Was the job done correctly? Did it approve the case it should have approved? This is the most basic, yet hardest, blocker to launch. If correctness is poor, there’s little point measuring anything else.
• Precision: Of all the positives the model flagged, how many were actual positives? This optimizes for avoiding false positives. This matters most when including a non-positive case is costly, like a fraud detection agent flagging a legitimate transaction as fraudulent and blocking a customer’s card.
• Recall: Of all actual positives, how many did the AI catch? This matters most when false negatives are more costly, like the return-flagging agent example above.
• Factuality/groundedness: Is the response actually supported by references, sources, or retrieved context (RAG)?

Tone/information

• Coherence/fluency: Especially for generated, user-facing responses, this bar matters.
• Tone: Did it hold the tone set in the system prompt?
• Safety/leakage: Does the answer avoid leaking PII or violating safety guidelines? This threshold should probably sit close to 100%.

This isn’t an exhaustive list, and not every AI solution needs all of these. But these are the angles worth thinking through.

Then Who Grades It?

In college, depending on the assignment, grading fell to a TA (my school called them a GSI), the professor, or an automated grader for things like math that could rely on exact match.

It’s similar for LLM grading. You can have a human grade it, or an LLM act as judge. Typically, both get used.

Early on, I think it’s important for humans to review, especially when it comes to judging whether an agent classified something correctly or made the right call.

Once you scale up and have more evals, an LLM-as-judge can take over scoring more cases against the same rubric. But every so often, a human should grade a sample of what the LLM graded, cross-check it, and recalibrate the rubric if needed, the same way a professor or TA occasionally double-checks an automated grading system.

A Grading Matrix, Not a Final Grade on a Report Card

It’s not just an A- or a B+ on a report card. What you actually need is a grading matrix that shows what you did well and where you fell short. The same goes for LLMs. They need to know what they’re failing at and what they’re doing well. If completeness is crossing the 95% threshold but accuracy sits at 80%, below threshold, you know you need to harden the architecture or prompt to get the agent right more often. If precision is climbing but recall is dropping, you know you’re letting too many issues slip through as false negatives.

Once you think about it this way, evaluating and improving LLMs becomes more structured, the same way a good grading rubric in college helped you actually grow.

I feel like “embedding in a customer’s org” is very much a consulting concept. I had an internship in consulting and considered pursuing it full time. The job was literally being on the client’s site, sitting with customers for hours, talking to them, and understanding their business processes to come up with improvement plans. But what actually goes on during that time to drive adoption, especially when your job is to ship a product instead of a slide deck?

I’ve been living a harder version of this myself, especially with healthcare customers, who tend to be skeptical of digital transformation, operate under heavy regulation and compliance, and move through long deal and adoption timelines. It’s not as simple as writing a good spec from one or two customer/stakeholder interviews, executing against it, and giving weekly updates. It’s rarely that smooth.

Here are some practices I’ve picked up along the way, through plenty of trial and error.

#1: Spend the First Few Weeks Just Being a Good Observer

This is a practice I learned during my consulting internship. One summer in college, I was tasked with helping a large electronics retailer digitally transform its inventory management. I assumed the first set of tasks would involve analyzing inventory data, talking to customers about pain points, and doing some modeling. It turned out to be a lot more “passive” than that.

It was purely sitting at a few different retail stores of that company and observing how they operated, for the whole day, while the shop was open. I logged everything on a sheet of paper, paying close attention to inventory operations: who did what, what moved from where to where. At first this felt tedious. I remember thinking, “why can’t we just ask the ops managers instead of observing them?” I did that for the first two weeks of the study and thought it was a waste of time having consultants sit in silence at a shop.

I later realized there’s no better way to diagnose the current state and identify real problems than being in the operation and observing the business process directly. Interviews aren’t always reliable, and data doesn’t capture what’s happening behind the scenes, including the frustration that comes with it.

The same is true if you’re deploying an AI agent for, say, handling a health payer’s prior authorization requests. You still need to analyze the current business process to build something that automates and solves the right problem, but what is the problem, really? The most accurate diagnosis comes from careful, objective observation of the people handling these calls and requests: the mild frustration on their faces, the fields they fill in, what causes delays and bottlenecks, the conversations they have along the way.

#2: Understand the Ask Behind the Ask

When you’re embedded with a customer trying to understand what they actually want, it could be as simple as them asking you to build something. Take the prior authorization example: an insurer customer might ask you to build code that auto-classifies each healthcare provider operations request into buckets based on certain keywords. But you have to be careful not to just be a tech vendor executing literal requests.

A customer is an expert in their current workflow, but they can’t always envision what’s possible with your product, nor do they fully understand the implications of what they’re asking for. So you have to understand the ask behind the ask.

In this case, the insurer asked for deterministic keyword-based sorting, but what they actually want is to cut down the time spent reviewing and classifying each request. The how they proposed isn’t necessarily the best practice. That part is on you to figure out. Maybe a lightweight LLM classifier is more accurate than exact keyword matching, since keyword matching alone tends to produce a high escalation rate. Your job is to understand the need, not take their proposed solution literally.

#3: Sell on Metrics, Get Buy-In

This ties directly to the point above. Once you understand the ask behind the ask, at some point you need real buy-in from the customer, often from executives. Depending on the deal, this might happen pre-sales or post-sales, but either way, your goal is to earn the trust needed to fully embed and drive adoption.

The key is to sell on metrics or goals they actually care about. If you did the observation work right, you’ll already have a sense of what matters to them. From there, you can set up interviews with the stakeholders who manage these teams and their metrics. For the prior authorization (PA) team, that might be the head of PA, whose success is measured by something like percentage of requests processed.

Whoever is driving the adoption initiative, usually someone senior, will have a clear metric in mind. Your pitch should build toward that. How does this workflow move that metric? Is there proof or a projection behind it? What concerns or skepticism have come up about automation along the way? Those should all be part of the pitch too.

It’s tempting to lead with the mechanics of the solution, especially when you’re excited about the technology. But senior leadership cares whether it delivers the cost savings or metric improvements they’ve projected, not how the model works under the hood.

#4: Strong Documentation Is King

Successful embedding means the rest of the project has to be maintained well.

Coming from startup and lean environments, I wasn’t used to heavy documentation, and I used to think it slowed things down. But in customer-facing deployments as a FDPM/FDE/Deployed Strategist, documentation is essential for alignment and for leaving a clear record.

A project charter or timeline should be drafted early, during the scoping and observation phase, to set expectations. Customers often don’t understand what it takes to build what they’re asking for, and that’s where scope creep comes from. You have to be explicit from the start about what you will and won’t build. Standard in-scope and out-of-scope documentation, listing user stories and requirements, goes a long way here.

Once you move into documenting the actual spec, it’s just as important to keep mapping details and aligning with the customer as you go. Using the prior authorization example, I’d typically build a flow chart of the entire workflow I’m imagining, from how an authorization request comes in from the provider to the insurer, whether we’re building that intake ourselves, through a classifier agent, and so on. It doesn’t need to be technical for the customer, but it should be detailed enough for them to understand the mechanics and confirm the workflow matches their expectations. That flow chart becomes the map you use to communicate regularly, often weekly, and it becomes the blueprint that drives the conversation: here’s what we’re building this week, here’s what’s next.

Sitting with customers, embedding in their world, can feel foreign for someone who had been sitting behind computers building products or drawing out roadmaps. But once you understand what you’re actually trying to get to, it becomes a lot clearer what conversations you need to have and what work needs to happen to get there.

The Problem With Ad-Hoc AI Development

My first attempts followed the same pattern: open Claude, describe the feature as detailed as possible — user stories, acceptance criteria, the works — get the code, paste it in, and iterate.

This didn’t get far. There was no memory between sessions, no structure, no audit trail. It was fast at first but got chaotic quickly.

After enough Reddit posts and YouTube rabbit holes, the lesson became obvious: Claude is only as structured as you are.

Rethinking the Role

What really forced me to think differently was building a personal finance app — LLM-powered transaction categorization, PDF parsing, data pipelines. Complex enough that hoping for the best wasn’t a strategy.

The insight was this: solo developers wear every hat — PM, engineer, tech lead, QA. In real teams, those roles hand off to each other through artifacts: tickets, PRDs, code reviews.

So I built a set of slash commands that mirror those roles exactly. Each command owns one responsibility, takes a defined input, and produces a handoff artifact for the next stage.

Slash commands in Claude Code are markdown files — predetermined instructions you invoke manually at your own pace. They’re loaded only when called, not sitting in context permanently. I think of them as product team folks with detailed instructions who can call on demand.

The Pipeline

This is the high-level slash command structure I developed.

Stage 1: /create-issue — The PM Brain Dump

In mid-development, my ideas always evaporate. This command is meant to capture them.

I throw in a rough thought, it asks minimal clarifying questions, then creates a Linear ticket and saves a local markdown file to .claude/backlog/.

The reason why I write it to both Linear and a local file is that Linear is for status tracking, but the local file is what Claude actually reads — no API call needed, available in the same repo, survives across sessions.

Stage 2: /explore-feature — PM and Tech Lead in the Same Room

The real problem I was hitting wasn’t bad code — it was jumping to code before understanding the full picture. Dependencies I hadn’t thought about, edge cases I’d missed, scope that was still fuzzy.

This command is that early planning conversation: it reads the relevant files, maps out integration points, and surfaces ambiguities. Crucially, it’s a back-and-forth loop — it asks me questions, I answer, it digs deeper — until there’s genuinely nothing left unresolved.

When the loop ends, it writes .claude/context/<ticket>.md: a structured artifact capturing every decision made. This is what makes the pipeline session-independent — the next command reads this file, not the conversation.

Stage 3: /write-prd — Alignment in Writing

Every team has the “I thought we agreed on X” problem (Solo or not).

This command reads the context file from Stage 2 and formalizes everything into a PRD — only what was confirmed, nothing added. It breaks the work into ordered tasks with emoji status tracking, so the next stage has a precise, executable plan rather than a vague description.

It also pushes the full PRD as the Linear ticket description that acts as one source of truth.

Stage 4: /execute-prd — The Engineer Who Follows the Plan

Claude going off-script is a real problem. Implementing things that weren’t discussed, adding “nice to have” scope, skipping steps. This command enforces discipline: read the PRD, execute one task at a time, update the status emoji after each, stop and surface a blocker explicitly if something’s wrong.

Stage 5: /review-code — The Senior Engineer Who Wasn’t in the Room

Self-review is a bad review. This command reads CLAUDE.md first to load the architecture rules, then diffs the changes and flags issues across three severity tiers:

• CRITICAL — will cause bugs or data loss
• WARNING — violates architecture rules
• SUGGESTION — style or improvement

Stage 6: /commit and /deploy — Closing the Loop

These are two separate commands intentionally. /commit is local and reversible — it creates a checkpoint, writes a conventional commit message, and stages only specific files (never git add -A, never secrets). /deploy is the public, irreversible step: push to remote, open a PR, update the Linear ticket to In Review.

Separating them means review-code can sit cleanly between the two. You can commit incrementally through a session without shipping anything, then deploy only when you’re satisfied.

What Makes It Work Across Sessions

These separate slash commands are like having different individual contributors. So I needed to make sure these commands work as a team together:

1. CLAUDE.md is the always-loaded foundation — architecture rules, data flow, file map, forbidden patterns. Every slash command inherits this context automatically. It’s the onboarding doc for Claude, and as a side effect, it turned out to be useful for me too.
2. Local backlog files are how commands talk to each other across sessions. Each ticket has a corresponding .claude/backlog/MYF-XX.md that Claude can read directly, without hitting the Linear API.
3. Context files are how exploration survives into a new session. /explore-feature writes .claude/context/<ticket>.md when it finishes. /write-prd reads that file first. The two commands can run days apart and the handoff is clean.

Where This Is Going

The next iteration for my development team is multi-agent patterns. The distinction: slash commands run sequentially in a single Claude instance — one session, one context window. Multi-agent means spinning up parallel Claude instances, each with their own context, coordinated by an orchestrator.

Multi-agent adds coordination overhead, so it’s worth it only when the work is genuinely parallel and the codebase is large enough to benefit.

Closing

I didn’t set out to build a whole product management system. I set out to stop losing context between Tuesday and Thursday. This ended up being a pretty practical setup. Seven commands, each with one job, chaining into each other through files. It’s not perfect and I’m still tweaking things, but it’s the closest I’ve gotten to feeling like there’s actually a process behind how I build.

It’s an understandable reaction. Agents are genuinely impressive, and the anxiety about what they mean for traditional software companies is not irrational. But I think the narrative conflates two different questions: are agents better? and does that mean software companies disappear? The answer to the first is mostly yes. The answer to the second is more complicated and more interesting.

Why Agents Are Actually Superior

To make the case that software companies aren’t doomed, you first have to take seriously the case that agents are a real step forward. Because I think they are.

Traditional B2B SaaS was built around a seat-based model, and the value it delivered was always somewhat fuzzy. Your company bought a CRM to manage deals, a knowledge management tool to organize information, a project tracker to coordinate work. But measuring what any of that actually produced was hard. “We saved X hours” ended up in a lot of investor decks, including ones I’ve helped put together, but it was always a soft metric. Productivity support is difficult to quantify. The relationship between the tool and the outcome was indirect.

But agents are different in a meaningful way. They don’t support the work — they do the work. An agent doesn’t give a sales rep a better interface for managing a pipeline; it sends emails to strong leads and closes deals on their behalf. It doesn’t help a customer success team triage tickets; it responds to and resolves them, with a measurable containment rate. That’s a genuinely different value proposition, and it’s one that’s easier to see, easier to justify in a budget conversation, and easier to renew.

So yes. I would argue agents are better at delivering measurable outcomes than a lot of what traditional SaaS was doing.

But Who Actually Wins Here?

If AI is the future of software products, the question is: who would win the game?

One answer is foundation model companies: OpenAI, Anthropic, Google. But that’s a separate, capital-intensive landscape, one that requires R&D at a scale that makes it difficult to break into. The real action is in the layer above: companies building agents on top of those models.

And here’s where it gets interesting. If you’re building an agent-based product on top of commodity model infrastructure (Opus, GPT), what’s your actual moat as a company?

Moat #1: The Ability to Sell

Agentic products still need to be sold, scoped, and trusted by enterprise buyers. And the stakes are higher than they were in traditional SaaS. When you hand an agent access to your CRM, your inbox, your customer communication channels — you’re not just buying software, you’re making a significant bet on the company behind it.

That means brand, relationships, and sales execution matter enormously. And this is an area where some traditional SaaS companies may have a real, underappreciated edge. A company like Salesforce has account executives who know their buyers deeply, have navigated complex procurement cycles, and have earned institutional and enterprise trust over decades. That’s not nothing. It’s a muscle that takes a long time to build.

Well-known founders and early-stage startups with strong reputations in a specific vertical have a version of this too — founder-led sales, credibility with a particular buyer community. But the common thread is that distribution and trust are moats. In an era of agentic products, the “salesforce” (lowercase) may be the most underrated competitive advantage of all.

Moat #2: Forward Deployment and Customer Embedding

Agents are not out-of-the-box products. Unlike a self-serve SaaS tool where you may hand over a login and a user guide, deploying an agent requires a deep understanding of a customer’s specific workflows, their existing tool stack, their team structure, their edge cases. You’re not selling software. You would be rebuilding how a company operates, with software as the instrument.

This has given rise to a new kind of role across AI companies: Forward Deployed Engineers, Forward Deployed PMs, deployed strategists. The job is part “consultant”, part product manager, part implementation engineer, part account manager. These are people who sit at a client’s office, map their current workflows, push back when a proposed design doesn’t fit, and build something that actually works in that specific environment. It’s deeply human, deeply relational work — and it’s nothing like a traditional job of triaging features and simply writing specs.

The companies that build this capability, the ability to embed with customers, iterate quickly in their environment, and become genuinely indispensable to how they operate, will be very hard to dislodge. This is a stickiness that goes well beyond switching costs in the traditional sense. It’s organizational memory, embedded in another company’s workflows.

Back to Salesforce

Which brings us back to where we started. This week, Salesforce stock jumped 7.6% after a blowout earnings report — $3.88 in adjusted EPS against a Wall Street expectation of $3.12, with $11.13 billion in revenue, representing 13% year-over-year growth — driven in large part by momentum from Agentforce, its agentic AI platform.

The company that was supposed to be the cautionary tale of the AI disruption era just posted one of its strongest quarters in recent memory. Not because agents aren’t real, or because the old SaaS model survived intact. But because Salesforce had something most startups don’t: decades of enterprise relationships, a battle-tested sales organization, and the resources to build a forward deployment practice at scale.

Not all B2B SaaS companies are dead. The model is just changing — from selling seats to delivering outcomes, from shipping features to embedding in workflows. The companies that survive and thrive will be the ones that figure out how to do both of those things well. That requires a different kind of product, a different kind of team, and a different definition of what it means to build something that sticks.

As a product manager at a digital health platform, one of the recurring tasks I deal with is documenting product releases. Every time we ship something new, the same information needs to end up in at least three places: a product update log in our user guide/documentation, a newsletter email to our users, and a rotating set of feature tips on our login page.

Each of these has a different format, a different tone, and a different audience.

• User guide release note page: Needs to be structured and role-specific — grouping features by who they’re for and written in a way that’s practical and easy to scan.
• New feature email: Needs to be warmer and more benefit-driven, the kind of writing that makes someone actually want to read it.
• Login page tips: Needs to be shorter, punchier, designed to make someone who’s logging in at 9am discover something they didn’t know the product could do.

The problem is that all three are based on the same source material — the same GitHub PRs, product issue description, the same internal documentation, the same user guides our writing team produces. The information doesn’t change. What changes is how you frame it, what you emphasize, and how you write it up.

For a while, we just did this manually. It works, but it’s slow, and the quality is inconsistent. By the time you’re writing the third version of something, you’re not giving it the same attention you gave the first. Features end up under-described or described in a way that doesn’t quite fit the channel.

So for our internal hackathon, I decided to build a tool to handle the repurposing work.

The idea was simple: a small web app where you add the features you’re releasing, paste in whatever reference material you have for each one, and check which content channels each feature belongs in. Hit generate, and it produces a first draft in the right format and tone for that channel. Three channels, three separate outputs, all from the same source material.

Building It Without Knowing How to Build It

I should be upfront about something: I’m a product manager. I understand systems and I can generally read code, but I don’t sit down and write a Node.js backend from scratch on a regular basis.

For this project, I used Claude — both through the browser for planning and architecture conversations, and through Claude Code in the terminal, which can read directly into your codebase and make edits in context. The combination turned out to be a fairly natural way to work. Browser Claude for thinking through problems and making decisions upfront, Claude Code for actually writing and modifying files once the direction was clear.

The planning conversation was where I spent the most time before writing a single line of code. I wanted to make sure the architecture made sense before jumping in, so I framed it the way I’d frame a conversation with a senior engineer — giving context about what I was trying to build and what constraints I was working with, and asking for an opinion rather than just instructions.

The exchange went roughly like this:

Me: I want to build a tool where I can input a list of product features — each with a name and a block of reference content — and generate three different types of release note content from them: a user guide entry, a newsletter email, and a product tip slide. The user should be able to check which features go into which output type, reorder them by priority, and generate each artifact separately. I want to use the OpenAI API for the generation. What’s the simplest architecture that would actually work here?

Claude: A plain HTML/CSS/JS frontend — no framework needed — talking to a small Node.js Express backend that handles the OpenAI API calls. The backend is necessary because you can’t safely expose your API key in frontend code. You’d have one POST endpoint that receives the artifact type and the list of checked features, builds a prompt, calls the API, and returns the result. All the state — which features exist, what content they have, which boxes are checked — lives in the frontend in a JavaScript array. The backend doesn’t need to know anything about state.

Me: That makes sense. What files do I actually need?

Claude: Four files: server.js for the backend, and inside a public/ folder: index.html, style.css, and app.js for the frontend. Your .env file holds the API key and never gets committed to git.

That framing — one endpoint, state in the frontend, four files — gave me something concrete to build toward.

From there, most of the actual development happened through Claude Code in the terminal. I’d describe what I wanted, it would write or modify the relevant files, I’d open the browser and test, notice something was off, and describe the problem.

A good example of how this actually goes: I asked for drag-and-drop reordering and it built it on the PR input cards on the left side of the UI. That wasn’t what I wanted — I wanted it on the matrix rows on the right, so users could reprioritize features right before generating.

One clarification and it moved. That kind of iteration — build, test, notice, correct — is pretty representative of the whole process.

Getting the Prompts Right

This is where most of the actual work went, and where the most interesting decisions happened.

The first version of the prompts was pretty generic — describe the feature, write it in the style of a user guide, here’s an example. The output was fine but not quite right. The model was pulling in too much technical detail from the source material. A PR description might explain why a certain architectural decision was made, or how the feature handles an edge case in the codebase — none of which is useful in a release note. What we want is the user-facing benefit: what can someone do now that they couldn’t do before, and why does that matter to their workflow.

The fix was adding an explicit section to each prompt that I called HOW TO READ YOUR INPUT:

HOW TO READ YOUR INPUT:
You will receive content from multiple sources — GitHub PR tickets, user guide drafts, or both.
- FROM GITHUB PR TICKETS: Ignore technical implementation details, code decisions, and developer
  justifications. Only extract: what the feature does for the user, what problem it solves, and
  any user-facing behavior described.
- FROM USER GUIDE DRAFTS: This is your richest source. Extract: feature descriptions, use cases,
  user benefits, and any specific examples of how researchers or coordinators would use it.
- NEVER write about: how the code works, why a technical decision was made, or implementation
  tradeoffs.
- ALWAYS write about: what the user can now do, why it matters to their research workflow, and
  concrete examples of the benefit.

This made a significant difference. The model started treating PR content and user guide content differently, which is exactly what a human writer would do — you skim the PR for context, but you write from the user guide.

Few-Shot Examples

Style rules help with structure, but what really brings the output in line with what we actually want is few-shot examples — showing the model real before-and-after pairs rather than just describing what good looks like.

After the style rules in each system prompt, I added a section with example inputs and their ideal outputs. The examples came from taking real feature release note content we’d already documented manually, pairing them with the raw source material we would have fed in, and using the hand-edited final version as the target output.

For the user guide prompt, an example pair looks something like this:

EXAMPLE INPUT:
FEATURE: Survey Dictionary adjustments
CONTENT: This updates the survey dictionary export. Added a "Published" flag to the export which
indicates whether this is the current published version. WebViewSteps are now included in the
questions list. InstructionStep content items are now included in the dictionary since they can
have a result.

EXAMPLE OUTPUT:
For Data Managers
* Know which survey version is published to the project. The __survey dictionary export__ now
  includes a Published column to show whether this particular survey and version is published to
  the project. WebView and instruction steps are also now included, giving you a more complete
  codebook for downstream data use.

A few things this example teaches the model beyond what the rules say:

• The feature name “Survey Dictionary adjustments” is a raw developer title. The output rewrites it into something a user would actually understand.
• The output is one sentence of context followed by one sentence of detail.

Three to four real examples per prompt felt like roughly the right number. More than that and the model seemed to startpattern-matching too literally to the examples rather than generalizing from them. The quality of the examples matters more than the quantity — one well-chosen example that covers an edge case is more useful than three examples of the same type of feature.

What Actually Changed

Before the tool, drafting the user guide entry, the email, and the product tips for a release would take ~1–2 hours each — and that’s not counting the back-and-forth review cycles where you’re comparing versions and making sure the same feature isn’t described differently across channels.

Now each artifact takes about 30 seconds to generate. The output isn’t final — you still need to read it, adjust the wording, make sure the tone is right for the channel — but the first draft is already in the correct format and structure. The editing pass takes maybe 15 to 20 minutes instead of a couple of hours.

The less obvious benefit is consistency. When you’re writing three versions manually, you make different emphasis decisions each time, often without realizing it. One channel gets a better explanation of a feature than another because you happened to think of a good example on the third pass. With the tool, all three versions start from the same source material and the same prompt, so the coverage is more even even before you start editing.

Next Steps

Taking this further, I could build a small prompt management interface — a place where you can edit prompts, add examples, and test changes against real inputs. For an internal tool, this is probably more than what we need. But for something I’m productizing — where multiple teams or multiple companies are using the same underlying tool with different style preferences — it’s the right architecture. The prompts become a product surface in their own right, not just a detail inside the server code.

For the specific problem of repurposing the same content across multiple channels, language models are genuinely well-suited. The source information is the same. The transformation rules — different tone, different structure, different emphasis — are learnable from examples. And the volume is low enough that even small improvements in consistency and speed add up meaningfully over a release cycle.

As a Product Manager building a healthcare platform for clinical trial and digital health researchers, as well as patients who self-monitor symptoms and treatments, I spend most of my time thinking about care workflows for patients and health studies: collecting data from patients, organizing admin tasks between study coordinators and patients, and enabling patients to view their health data and trends.

Although there are great services out there that make parts of care more accessible and efficient, it still feels like healthcare in the U.S. is framed as an industry where increased consumption is seen as failure.

I recently came across a fantastic article by a16z called “Infinite Healthcare: What’s It Worth?” written by Jay Rughani, Jane Rhee, and Julie Yoo. My piece is a short summary of some of its key ideas, along with a few of my own thoughts as someone building in this space and seeing the shift toward new care powered by AI.

The Reactive Care Problem

The first major point is that healthcare is heavily focused on reactive, retroactive care, where high usage often indicates failure and high costs. The article highlights that “today’s healthcare system is dominated by reactive care delivered after something has gone wrong, plus the administrative machinery required to ration access.”

This is quite counterintuitive compared to many other industries, where high usage should be celebrated.

Because doctors, surgeons, and clinicians are scarce resources who provide reactive services and interventions, medical expenses are structured around high fee-for-service rates.

Whereas there is arguably much more value in proactive and preventative care. The article makes the point that proactive care generates significant consumer surplus and positive externalities for society by reducing hospital inpatient days, increasing work productivity, adding to economic output, and increasing tax revenue as people work and live longer.

AI and the Rise of Proactive Care

AI-driven cancer diagnostics, AI-enabled health coaching, AI assistants handling subclinical admin tasks, sleep trackers, meal logging, and self-monitoring apps for symptoms and treatments are all services that have become significantly more powerful with the development of AI, LLMs, and better analytics.

When consumers use these services, the value add can be massive.

But there’s a complexity: if consumption rises while pricing structures remain the same, it could still lead to higher overall medical expenses.

The Jevons Paradox in Healthcare and Access-Based Business Models

This is where the article provides interesting insights about the business models healthcare should move toward.

The authors describe two tiers of services:

1. Information-driven work: “clinical evaluation, diagnostic reads, psychotherapy, triage.”
2. Physical interventions: “procedures, surgery, hands-on treatment.”

Information-driven tasks are becoming cheaper, more accessible, and more efficient with technology and AI. As their marginal cost decreases, the business model may shift toward selling “access” rather than charging per individual service.

This connects to the Jevons Paradox, where “as a service gets more affordable, we tend to consume dramatically more of it, and business models inevitably reorient from metering units to selling access.”

We’ve seen this shift from artists selling CDs or albums in stores or on iTunes to subscription-based access through Spotify and YouTube Music. The same happened with DVDs and movie tickets moving toward Netflix and Hulu. Healthcare may be facing a similar paradigm shift.

Some services will likely remain fee-for-service, especially those tied to physical diagnosis or treatment. However, even those costs could decrease as treatments become more accurate and effective.

Other services may fit better into alternative models. a16z mentions a few:

• Per workflow: charging for a multi-step set of tasks. Many AI-enabled admin workflows could be priced this way instead of being bundled into singular service fees per clinic visit.
• Per episode: pricing for a defined treatment period rather than charging for each individual treatment within that period.
• Per patient: a model offering bundled or unlimited access to certain services.

Under these models, increasing care consumption would not necessarily drive uncontrolled cost growth. Instead, it could incentivize better and more continuous care.

Technology Refocuses the Core Value

Technology is brilliant in that it pushes industries to focus on the core value of their services.

Sales SaaS tools liberated sales reps and account executives from manually organizing leads, scheduling calls, and taking notes, allowing them to focus more on building relationships and closing deals. Productivity tools help students and workers spend less time finding scattered information and more time getting actual work done.

Similarly, many AI-driven care services are making information work — diagnostic reads, admin tasks, scheduling, evaluation — faster and more efficient. This allows clinicians to focus on delivering higher-quality interventions, surgeries, and treatments.

This shift operates not only at the service level but also at the business model level. As consumption increases and the economic unit cost decreases, powered by technology and , models may move toward access-based structures.

This creates a positive feedback loop: as the cost of proactive care decreases, consumption increases. As consumption increases, more companies and providers focus on offering efficient, preventative care powered by digital health. That increased competition and scale can further reduce costs, while reserving resource-intensive physical interventions for those who truly need them.

Clinicians, in turn, can allocate their time more effectively instead of spending unnecessary hours on manual note-taking, organizing lab results, or performing repetitive data entry. Technology handles what it can do better, while clinicians focus on high-value physical care.

It could be something lightweight — “To stay consistent, we recommend keeping your daily journal under 300 words.” Or more structured, like “Create these buckets to track sales leads and add a status field here for better visibility.”

These are essentially best practices you want users to follow to:

• Fully explore and maximize your product’s capabilities
• And, more importantly, reach the state of “success” efficiently

As a Product Manager, though, I’ve found it surprisingly challenging to define, implement, and surface these best practices in a way that actually helps users. In this piece, I’ll share some of the ways I’ve introduced and prescribed best practices to customers.

Why Best Practices Matter

Why not just offer maximum flexibility and let users decide what works best for them?

Every product exists to deliver value. Ultimately, its success is measured by whether users actually experience that value.

Sure, you may not want to control every path a user takes. But as a builder, you want to maximize the number of users who feel that aha moment — and reach it as efficiently as possible.

If you’ve done your job studying users and their pain points, you likely understand what behaviors increase their chances of success. You know which setups, configurations, or workflows meaningfully impact outcomes — and which can be left as intended variations among users.

For example:

• In a GenAI marketing message generator, how should someone specify the tone parameter to generate a strong LinkedIn blurb? Do adjectives improve output quality? Do detailed descriptions actually matter?
• In a travel events app, how should someone configure notifications to consistently discover relevant experiences? Or are the configurations something that can be intentionally varied and not follow a set of practices?

Best practices, in this context, are simply informed opinions about how to use the product in ways that reliably drive value. Enforcing them isn’t about restricting freedom — it’s about increasing the surface area of user success.

But this only works if a few prerequisites are met.

Before You Prescribe: The Prerequisites

Before even thinking about surfacing best practices, there are two obvious things that need to be in place.

1. Study your users and what actually brings them success

You can’t just come up with a set of best practices in your head. You need to observe how users use the product and what the outcomes look like.

Who stuck around longer in your app? What configurations or settings in the productivity tool you shipped actually shortened their time to complete tasks? What parameters did your most successful users input into your GenAI tool? These are the patterns you need to study.

Looking at cohort-level analytics in tools like Amplitude, Mixpanel, or Heap can give you insights across large groups of users. In some cases, directly observing or interviewing customers may give you even richer insights.

2. Document these best practices internally

This might be a simple doc for yourself if you’re a solopreneur, or something shared with your customer success team so everyone is aligned on what a successful product experience looks like. It could also be shared across PMs so that prioritization decisions reflect these opinions.

These “proven” best practices should be clearly documented so that you and your team understand which variations are acceptable in your product — and where you intentionally hold an opinion about how users should use it.

How to Prescribe Best Practices

Once you’ve formed strong, evidence-backed opinions, the next question becomes: how do you introduce them?

I think about this in two buckets:

1. In-product
2. Outside the product

You might notice that some of these recommendations overlap with the strategies I’ve shared previously about unblocking the user struggle, but the focus is here is more on prescribing opinionated practices rather than just moving users forward beyond friction points.

In-Product

Action-Based Tooltips

You might’ve come across those annoying product tours that you immediately click “Skip” on when signing up for something new. While those tours may contain best practices the product team wants to surface, they’re often shown at the wrong time — right at the beginning, when you don’t even have a clear goal yet.

Instead, add tooltips around the product that are action- and time-driven.

For example, when a user is about to generate their first LinkedIn draft in your AI marketing tool, you could show a tooltip next to the tone parameter saying something like:

“Using descriptive adjectives here improves output quality.”

That timing is far more relevant than showing guidance before the user even knows what they want to write.

Of course, you shouldn’t overdo this. Too many similar-looking nudges will desensitize users and make them annoyed. But when tooltips are timely, specific, and directly tied to the action the user is taking, they can be extremely effective.

I’ve found that some low/no-code tools like Userflow can be helpful for experimenting with this quickly.

Hover-Over Tooltips

In some cases, triggering tooltips based on actions may feel too intrusive.

Sometimes you just need static hover tooltips — where users can hover over an icon and see a recommended best practice for the feature they’re exploring.

These are more subtle than action-based nudges. They may be slightly more buried, but for features where it’s unclear what event should trigger guidance, hover tooltips can do the job without interrupting flow.

Templates

This really depends on the product, but in many cases, templates are one of the strongest ways to surface and subtly prescribe best practices.

Starting from an empty state in a CRM tool can be daunting. Instead, you could create templates tailored to different use cases — for example:

• A startup lead routing setup
• A Kanban board for large contracts
• An account manager view focused on upselling

You can intentionally build your well-studied best practices into these templates.

Ideally, the configurations and settings you’ve carefully designed into templates serve as references. Users can learn by seeing what “good” looks like, and they can form these practices as behaviors after learning them from your curated templates.

Templates don’t just solve the cold-start problem — they quietly encode your product opinions from the start.

Outside the Product

User Guides

One of the most straightforward ways to share best practices is through user guides.

For each section or feature area of your product, write an article that clearly outlines:

• What the best practice is
• Why it’s recommended and how it helps the user succeed
• A step-by-step guide on how to implement it

But the more important part isn’t just writing the guides — it’s surfacing them at the right time in the user journey. These can be powerfully paired with action-based or hover-over tooltips that link directly to the relevant guide.

Customer Calls

For high-touch products that require onboarding, setup, or implementation support, this is almost mandatory.

Instead of walking customers through features in a neutral tone:

“You could set up your Kanban board to include bucket A, B, and C…”

Shift the tone to be more opinionated:

“For a team like yours, your Kanban board should include A, B, and C to maximize visibility and track changes across cross-functional teams.”

Staying confidently opinionated (when your recommendations are well-founded) makes you sound more credible. It also increases the likelihood that customers follow your guidance — whether it’s delivered in a call, tooltip, or user guide.

Emails

You could also run a series focused on best practices and send it to new users or users actively exploring certain features.

The most effective approach is to cohort users based on feature usage and send targeted emails that teach relevant best practices.

These are less immediate than in-product tooltips, but they’re well-suited for actions that require more time and thought — like setting up a budgeting spreadsheet or configuring an entire workspace.

Opinions Can Drive User Success

Again, I’m sharing these approaches assuming you’ve already built strong, evidence-backed opinions about how users should use your product.

Once you’ve done that work, it becomes your responsibility — as a builder, PM, or account lead — to actively surface and recommend those best practices.

“User-first” doesn’t mean unlimited flexibility with no guidance. It means prioritizing user success — and doing everything possible to help users reach value efficiently.

And the stronger your well-founded opinions are, the more success your users will experience.

Last October, I had an incredible opportunity to attend a NYC-based startup and entrepreneurship conference for Koreans called Koom Startup Festival. Hosted by the United Korean Founders, the event brought together Korean industry experts, entrepreneurs, and investors from around the world. It’s been a while since the event, but I wanted to transcribe the notes I took that day — to keep a record and to share a few insights about entrepreneurship, the future, and where things might be headed.

Yup Kim — Chief Investment Officer at TMRS (Texas Municipal Retirement System)

I first came across him through a video interview and was struck by his principles around investing, work, and where the world is headed. It was great to hear his thoughts live.

• He described the role of a CIO as essentially being tasked with predicting the future — by gathering information from others and placing bets based on that synthesis.
• Investing, in that sense, is really an ideas business. It’s about collecting philosophies, principles, and perspectives, then mixing and testing those ideas to see where the future might go.
• One thing that stood out was how important communication is in investing. Conviction and concision matter. Mediocre ideas with excellent communication can take you further than perfect ideas.

John Kim — CEO at Sendbird

Over the past few years, I’ve met folks from Sendbird, and it’s been fascinating to watch the company evolve — from a chat and messaging API provider to an agentic AI platform through delight.ai. John is a prominent figure among Korean founders in the Bay Area. His founding stories, insights into where agentic AI is headed, and general advice are consistently inspiring.

• On AI agents replacing human work: while humans are limited to serial processing, AI agents can operate in parallel. We’re nearing a point where the number of AI-agent conversations is soon to surpass human-to-human conversations.
• The talent archetype is also shifting. Instead of prioritizing past experience, proven playbooks, or logos on a resume, what matters more now are first principles, rate of learning, and the ability to design systems — how someone can structure AI architecture X to build outcome Y.
• So what does it mean to be a “100x employee” when AI agents can arguably think better than humans? In John’s framing, a 100x employee is bounded by AI budget, not time. Their role becomes planning, designing, and prompting the agent — while execution is largely handled by AI.

Sophie Kim — CEO of Kurly

Kurly may be unfamiliar to many in the US, but it’s a revolutionary online grocery platform that pioneered next-day, early-morning fresh food delivery in South Korea. Kurly has recently begun expanding into the US market. Sophie shared her motivations behind founding the company.

• For her, the key was focusing on a business that would remain relevant even as humanity changes — something rooted in fundamental human desires.
• She made an interesting analogy to Christianity: just as Christianity has “sold” the promise of eternal life for thousands of years, she wanted to pursue a value proposition that wouldn’t erode with time.
• Her vision is that when her time eventually ends, the company will be in the strongest form it has ever been — delivering the best experience it possibly can.

Heeeun Park — Partner at Altos Ventures

Altos Ventures is a pretty legendary VC firm with early investments in companies like Roblox, Coupang, and Toss. Partner Heeun Park shared insights on industry outlooks in Korea and among Korean founders.

• Healthcare and cosmetics seem especially promising.
• In Korea, many of the top students have traditionally gone to medical school to become doctors. But instead of following the conventional path of residency and fellowship, a growing number of med students are now founding companies — driven by a stronger entrepreneurial ecosystem and increased VC activity.
• Coupled with that is Korea’s exceptionally high standard for beauty. High expectations from consumers tend to push companies toward better services and products. The result: strong prospects in health software, medical devices, beauty products, and clinics.

Richard Park — Founder of Ascend Partners, Founder & Former CEO of CityMD

Richard Park’s story — going from an immigrant child who didn’t attend college to founding the largest urgent care provider in New York and New Jersey — is genuinely inspiring.

• After high school, instead of going straight to college like many Korean immigrants, he opened a small local business: a one-hour photo store.
• He eventually went to medical school and became an ER doctor. But the idea stuck with him — bringing the speed and convenience of that one-hour photo concept into healthcare. That idea ultimately became CityMD.
• Even in business and investing, he emphasized the importance of principles. His father, who ran a restaurant in NYC, refused to sell alcohol despite financial/profit pressure. He believed in that decision and stuck to it. That quiet consistency left a lasting impression.

At the same time, there was plenty of instability. Even if I could “expect” the unexpected, I was still hit with new challenges and problems as a Product Manager. Outside of work, figuring out where I’m headed in my career — where to focus and how to grow my skills — has gotten harder to pin down as time went on. And outside of my career, the uncertainty showed up in bigger questions: where I want to be, what I want to be doing in the next x years, and where I want to allocate my energy…

Looking back, though, this year was filled with inspiring insights, fruitful successes, and meaningful failures that helped me zero in — along with people who pushed me to grow and content that stretched how I think.

Some of my 2025 wrapped:

Products that impressed me in 2025

Veo 3
I like to make films and videos, so the Veo 3 release was a pretty big moment for me. I’d seen earlier video generators — they were fascinating — but I never seriously considered using them since I wasn’t making AI short-form content or anything. Then Veo 3 came out, and it kind of changed my mind. I’m still not using it to replace live-capture videos, but I do use it to augment them.

Most recently, I used it to create a show intro clip that’s a parody of a ’90s TV show. I only had screenshots of the original intro as references, and I played around with describing and prompting (basically acting like a film director) how the intro should look and play out. It did a fantastic job recreating the intro in the style I was going for.

A good Veo user is:

1. someone who understands how Veo interprets and processes prompts (the Hollywood equivalent of a director who really knows their actors and what nudges work best), and
2. someone who can clearly prompt and iterate on those prompts (the equivalent of adjusting direction for the actors and crew).

Tempo
This might be an odd one, but it’s very specific to my hobby. I play drums in a church worship band, and Tempo is the metronome app I use. There are hundreds of metronome apps out there, but this one feels like the standard among session musicians for a few reasons:

• Low floor: Set a BPM, add a time signature, and it clicks on the right beat. You hit the core value in literally 2–3 taps.
• High ceiling (for a metronome app): Plenty of useful customization — accent placement, presets, different click sounds, display options…
• Network effect: I discovered it by looking at what other session musicians were using and asking around. They were all on Tempo. It clearly crossed critical mass. Hard to beat that.

Projects I had fun with this year

At work, rebranding what was once an app for participating in health research studies into a more general health data-tracking app. It’s been a fun journey thinking through value propositions, ideal customer profiles, what would actually resonate, and which UI/screens would speak to people. It was more than just altered copywriting and a new landing page; it was all about rethinking about what pain points that these health-conscious users would feel in the current health data ecosystem, finding where our solutions fit into the market, and rebranding the app with new product marketing pieces that could echo those features.

Outside of work, I built a movie-logging tool. My personal pain point after watching movies is that I’m terrible at remembering takeaways. Right after the movie (or closing a Netflix tab), my feelings are vivid — but a few weeks later, or after a few more movies, I can’t even remember what I liked or disliked. So I made a quick logging app where I write a one-sentence reaction right after watching, plus a memorable line from the movie. It helps me remember how I experienced the movie, not how others framed it. It’s really just a utility for myself — but maybe it could turn into something more.

Movies I enjoyed this year

Speaking of movies, here are a few I watched this year that I loved (not necessarily released this year).

The Phoenician Scheme (2025)
Another great Wes Anderson film. It feels like an adventure game with multiple stages and quests — and that feeling comes through not just in the plot, but in the differently themed colors, art/design, sets, and characters. Wes Anderson’s signature humor cues and rhythms feel especially refined here. I laughed a lot.

The Killer (1989)
John Woo’s Hong Kong film, released at the tail end of the golden age of Hong Kong noir. I watched this because IFC Center — New York’s art-house theater — was running a Hong Kong noir series. Chow Yun-fat’s portrayal of a cold-looking killer with a warm heart pairs beautifully with John Woo’s iconic style: slow motion, extreme close-ups, dramatic music, and intentional silence.

The silence stood out the most — it heightens tension by deliberately stripping away dialogue and music at key moments.

Books that inspired me this year

How to Become Famous: Lost Einsteins, Forgotten Superstars, and How the Beatles Came to Be
I talked about this book in my previous article, but it argues that there’s no fixed “recipe” for success — and that success often can’t be replicated under the same conditions. Timing, exposure, and serendipity matter far more than we like to admit.

It made me think about how “origin stories” and “success recipes” are always written in retrospect. Maybe outcomes aren’t as controllable as we hope, so the best move is to increase the number of attempts and stay ready for that rare, lucky break.

The Singularity Is Nearer
Ray Kurzweil’s breadth and depth of insight into artificial intelligence is phenomenal. He lays out progressive yet credible predictions around the singularity — when AI surpasses human comprehension. I’m still working through the book, but I’m just fascinated by the story of the groundwork that has already been laid to get us here, and how that shapes what comes next.

Ironically, as a tech PM, I often default to a narrow view of AI — at a feature-level or a tech solution to “tech” pain points. This book forces me to zoom out and think much bigger, about how humanity itself might change.

I often feel a little empty at the end of the year, looking back and struggling to pinpoint clear growth moments or big achievements. But writing this reflection makes me realize that maybe a “good year” isn’t just about obvious growth — it’s about the ideas I have absorbed along the way, through work, content, writing, experiences, and the quieter shifts in how I think.