Category Archives: Strategy

The Principal-Agent vs. Agents Problem

Every human in the workforce has two crude goals:

  1. Be richer.
  2. Be lazier.

Get paid 2x more, or keep salary flat? Get paid more!

Go home at 11:01 PM, or stay up until 5 AM? Go home at 11:01 PM!

This isn’t a moral judgment. It’s just…economics.

Which brings us to one of the stranger problems with enterprise AI: AI can make every employee dramatically more productive without making the enterprise any more productive.

Imagine a Goldman Sachs analyst. At 11 PM, the boss sends over a presentation with the traditional two-word demand: “please fix.”

In the old world, the analyst spends six hours changing fonts, updating charts, reconciling numbers, and moving logos three pixels to the left. The deck is finished at 5 AM.

In the new world, the analyst secretly gives it to AI. The deck is finished at 11:01 PM. The analyst goes home and goes to sleep.

This is obviously a massive productivity improvement for the analyst.

What changed for Goldman Sachs?

Nothing!

The same presentation was delivered. The same analyst is employed. The same salary is paid. The same client is billed. Goldman doesn’t get a bigger fee because its analyst slept six extra hours.

AI created an enormous economic surplus. The analyst captured 100% of it in the form of leisure.

This is the classic principal-agent problem—with a new set of agents.

The enterprise is an ethereal “principal.” It wants more revenue, lower costs, faster turnaround, happier customers, etc. But an enterprise can’t actually do anything. It needs human agents—employees—to act on its behalf.

Now those human agents have AI agents acting on their behalf.

So the chain looks something like:

Enterprise principal -> human agent -> AI agent

The enterprise wants more output per dollar. The human wants more dollars per unit of effort. The AI agent generally follows the instructions of the human sitting at the keyboard.

Guess whose objective function gets optimized first?

This is why AI “adoption” inside an enterprise can be wildly misleading. Maybe 90% of employees use AI every day. Maybe every analyst, associate, paralegal, recruiter, consultant, and salesperson has become 5x more productive.

But if headcount is the same, output is the same, and revenue is the same, the enterprise has adopted AI technologically—not economically.

The employees are richer in time. The principal is not richer in money.

This also relates to a point I made recently: sometimes the user is not the customer.

User = person who actually uses the product.

Customer = person who actually pays for the product.

Normally, user != customer is a strong negative for product quality. If the user and customer are the same person, the product, sign-up flow, onboarding, etc. all have to be great. If they’re different, the customer can force the user to tolerate an awful product.

But AI introduces a different—and more interesting—version of user != customer.

The human agent is the user. The enterprise principal is the customer. And their goals are not necessarily aligned.

The Goldman analyst might LOVE a product that turns six hours of work into sixty seconds. But the analyst might love it precisely because Goldman doesn’t know how much time it saves.

What happens if Goldman finds out that every analyst is secretly producing presentations in sixty seconds?

Two logical options:

  1. The analyst class can be smaller.
  2. The existing analysts can produce 5x more work.

    Both benefit Goldman.

    Neither necessarily benefits the analyst.

    So the analyst has a perfectly rational incentive to use AI—and an equally rational incentive to hide the productivity gain. The best product for the user might be one that the customer can’t see!

    This is also why banning AI inside enterprises will often just create “shadow AI.” If a tool gives somebody back six hours of sleep, a corporate policy memo is unlikely to stop its use. The tool is effectively part of the employee’s compensation.

    The real enterprise opportunity, then, isn’t merely to get employees to use AI. They’re going to do that anyway.

    The opportunity is to get the principal to capture some of the benefit.

    That might mean selling completed outcomes instead of employee tools. Don’t give the analyst a faster way to make the presentation; make the presentation.

    It might mean redesigning workflows around the new level of output. If something that took six hours now takes one minute, the deadline shouldn’t remain six hours away forever.

    It might mean measuring throughput, turnaround time, revenue, resolutions, or other outcomes—rather than counting licenses and declaring victory because “80% of employees used AI this month.”

    And it probably means sharing some of the gains.

    If every productivity improvement results in more work, layoffs, or lower compensation, employees will rationally conceal productivity improvements. If employees participate in the upside—more pay, promotion, flexibility, or even permission to go home at 11:01 PM—they have a reason to reveal what AI can actually do.

    Otherwise, the enterprise will spend billions of dollars buying AI tools that its employees use to work less.

    AI can make the agent lazier.

    AI can make the principal richer.

    The trillion-dollar question is whether it can do both.

    Systems of Record

    What is a System of Record, and what makes some stickier than others?

    A system of record keeps track of the atomic units of a business. Calendars for resources and people (busy vs free), inventory (in stock vs not, delivery dates, costs), personnel (hours worked, vacation days, and salaries), shareholders (ownership, options, and types of stock), etc.

    Some of these items are “static.” Some are read constantly. Some are written and changed constantly. Sometimes there are far more reads than writes, and sometimes the opposite. Some of these are connected to many different “pipes” through APIs or corporate processes; some are used once and virtually forgotten. Some are intermittently read but of tremendous value (e.g., shareholder records!), and some are frequently read but of relatively low value (e.g, conference room calendars).

    Sometimes systems of record bundle these things together, in something that we typically refer to as a “vertical operating system.” ServiceTitan, for example, represents multiple systems of record (or a system of multiple records!). An Air Conditioning business must know its customers (CRM), when its technicians (personnel) are free (calendar), and parts (inventory) that are available for sale, and at what prices (accounting).

    A system of record for the busy/free status for conference rooms in your Miami office? Perhaps a pain to replace, but effectively costless.

    A system of record for tables in your Miami restaurant that grosses $20M a year? Just dropping one hour of records might cost more than the yearly savings of switching to a lower cost system.

    And then, of course, there are systems of record for raw data — literal databases that underpin virtually all systems of record. Ask a CTO running dozens of tables with billions of reads and writes per day how hard it is to swap out a mySQL database for Postgres and you’ll elicit visible anger.

    The stickiness of a system of record is a function of all of these different inputs, against the cost (often front-loaded/one-time) and risk (lost revenue, profits, and mistakes) of moving. Imagine paying $100/month for software where a $1/month option exists, but the one-time labor cost of switching is $3000, and there’s a risk that something goes terribly wrong. It’s quite logical to keep paying $100/month!

    This is part of why greenfields are often superior to brownfields. It’s why finding things outside of the goldilocks zone of pricing, or outside of acceptable satisfaction levels (too hated), is a possible unlock. And as services become the new battlefield, “migration as a service” could *finally* bend the cost/benefit analysis of switching.

    It’s great to be a system of record. I’ve always said that the best companies have hostages, not customers — but the hostages have a lot more tools to free themselves in 2026. Take note.

    Advice on Seeking Advice

    If you try to get advice from anyone *where they lack full context* you can build support for any position imaginable. Imagine: “the hospital refused to do surgery on this patient to fix this problem? Isn’t that outrageous?” without the context of “the patient is 104 years old.”

    Try asking a startup investor: “should I have a co-founder?” vs “Can I get a good co-founder for less than 10% of the company when the company is a few weeks old?” I bet you could get everyone to give you the opposite advice with more or different context.

    It doesn’t mean that getting advice is bad! But you either need to give significant context – or better yet focus on picking the right trusted partner, since it’s virtually impossible to give the FULL story to strangers in 30 minutes. I used to always try to get advice from famous people (it was incredible to me, l was just a nobody kid!) but ultimately context and depth matters.

    The “Comma MBA” Problem and Local Maxima

    The best entrepreneurs constantly “read the room” (or the market) and adjust their presentation style, their mannerisms, their product description, their team, their focus, their advisors — everything. They have the smallest number of axioms (things they accept without questioning). Everything else is subject to questioning, upgrading, and re-synthesis. Particularly since almost invariably they started off at a “local maximum” in terms of talent and advice.

    I call this the “comma MBA” problem. One time we had a nice fellow from Canada come pitch us, and on his business card he had his name, followed by “MBA” in the same way a doctor would put “MD.” His slide deck referenced his MBA, his pitch mentioned how everyone is “good at business” because they have business degrees, etc.

    There’s nothing wrong with an MBA (well, maybe 😂). But what he thought was a positive was not resonating, and he just…didn’t get that hint. And to show I’m not trying to cast shade at MBAs, one time we had a CEO talk about how amazing his tech team was because of their “.NET” prowess — the technical version of the “comma MBA” problem above.

    But let’s take a step back. Imagine that in our MBA friend’s small town, he went to the local business celebrity who seemed very wise, saying “make sure to emphasize the fact that you have an MBA! Otherwise the VCs will not take you seriously!”

    Both the good entrepreneur and the bad entrepreneur would seek advice from the same village elder. But the good entrepreneur would quickly learn and adjust from experience — “wow, that guy is wrong — I didn’t get the reaction/feedback I thought I would.”

    The bad entrepreneur sticks to the village elder’s advice. The good entrepreneur upgrades his/her advisor when it’s clear that it’s a constraint. We consequently give people the benefit of the doubt when they show up with a metaphorical “comma MBA” mistake; the important thing is ensuring they are always trying to learn and upgrade from their metaphorical village elder and resulting priors. And sometimes the village elder is exceptional, too — but it’s statistically rare.

    It’s part of why the founding team is so important. I like to say that there are only two jobs at a startup: selling the thing, and making the thing. That’s it. A very good technical person who knows nothing about sales can be bamboozled by a bad sales guy, and a very good sales guy can be bamboozled by a bad tech person.

    Your co-founder ideally serves an “axiomatic” role. If you can’t implicitly trust your co-founder, you’re in trouble. That’s not to say that the co-founder must be the most talented person in the domain! Rather, because the co-founder isn’t angling for a promotion and has no political aspirations, she just wants what’s best for the company and understands how to make the right decisions. (One useful cultural value at a scaling company: “You should always be willing to hire your own boss.”)

    You will constantly get bad advice. Your job is to know when to discard the advice, but also when the discard the *people* who are clearly meting out bad advice and not doing what’s best for the company. And ideally you surround yourself with talent where you don’t have to second-guess everything and can instead rely on your team — it’s the best way to scale yourself.

    Software Clone Wars of 2004, meet AI Cloning of 2026

    History doesn’t repeat, but it rhymes.

    Before SaaS, and before freemium, there was “shareware” — try before you buy software. This was a concept dating back to the 1980s, where software would be freely distributed on floppy discs attached to PC magazines…dozens of products on one floppy! Written by hobbyists and even upstart companies.

    id Software of Doom fame started out like this, as did McAfee. As did I!

    As things like BBSs, AOL, Compuserve, and eventually the Internet grew in the 1990s, one of the main use cases was downloading shareware.

    And it eventually started becoming a big business. The biggest download site was the appropriately named Download.com, owned by CNET.

    Around the same time, more people in more countries got access to the internet. And this little site called Elance (now Upwork!) survived the dotcom bust and ended up being a leading outsourcing site for everything from translation to, you guessed it, software engineering.

    So now there was a huge opportunity. You pick the number one or even number twenty product on Download.com that’s printing money. You go to Elance. You get dozens of predominantly Indian and Eastern European outsourcing shops to compete / bid on “cloning” it.

    I had a pop-up blocker (how I met @jonoringer), a couple of security products, and a bunch of utilities like a cool macro tool, an email tracker, etc.

    But now I could hire somebody for $500 and have them replicate anything on the top download site on the Internet! It was incredible.

    But it wasn’t. There is such much complexity under the hood that you never see merely by using the product. You see it when designing the product, when receiving hundreds of customer complaints, when realizing how much you could improve your conversion funnel, etc.

    You can replicate something “skin deep” but miss most vital organs. Who knew you needed a Pancreas or two kidneys?

    Elance fundamentally changed the shareware business. Anyone with agency could now hire somebody to clone a product or build a product.

    But here’s what I noticed:

    -cloning almost never worked, because there was too much “dark matter” in these products to be understood or seen when the goal is just rote replication

    -coming up with a NEW idea — much better path, since you have to conceive of all of the myriad corner cases. No free ride to rest on. -technical people still reigned supreme, since they could edit the resulting code from the outsourced shops

    -distribution > product. Now that it was so easy to build (or hire to build!), the advantage went to those with a real knack for acquiring customers. And it couldn’t just be “I uploaded it to the file library” like it used to be in the good old days of the 90s

    Now replace Elance with Claude or Cursor, and repeat this exercise Distribution will rule supreme. Original thought and insight will rule supreme. “Cloning” things at a shallow depth is a fool’s errand.

    Good luck.

    Cheat Code: Try to Pay More

    When I was running my little “shareware” business in college, I hired my first PR firm. Press really moved the needle for us (credibility and reach), and I wanted more. This PR firm had some very big name clients and lots of connectivity to the journalists and publications we cared about.

    There was a monthly retainer, something like $10,000, and I fought hard to negotiate it down to something like $5,000. Almost immediately I was disappointed. I was getting almost nothing from them.

    But of course I wasn’t. The firm only had so many favors they could call in. Should they use them on their biggest customer, or their smallest one? I was their smallest one.

    I had an epiphany: Don’t negotiate down. Negotiate up. Try to be the highest paying customer.

    I fired them, met with this Boston firm named fama PR, told them I wanted to be their highest paying client, and asked them point blank what that would take. I was a college kid and they probably thought this was funny, but we worked out a plan by which I’d pay them $40-$60K+/month (in 2003!) for certain performance.

    If I remember correctly, we had different tiers: get us on The Today Show and that’s $10K, front page of USA Today/NYT/WSJ also $10K, lesser tier $5K, etc.

    We launched this product called DidTheyReadIt in May 2004, and it was on the front page of USA Today, and then Carl Quintanilla came out to interview me for The Today Show. And many more. I still have the PR book they built of all of the appearances. It was insane.

    Mission accomplished: biggest client.

    The moral of the story is you get what you pay for. There are related learnings, too. The principal-agent problem is real. Shared services with no currency are hard. Let’s dive into those.

    This played out many years later when hiring tech recruiters who typically take a percentage of first year salary (of the placed employee). They might take 15-30% depending on the market.

    Remember what a tech recruiter does. They often find a really good candidate and peddle him/her to every company to maximize the chance of earning their fee. (In many cases, they’ll send cold emails about this — “I have 4 amazing candidates!”).

    At TrialPay we once lost a REALLY good candidate and learned that our recruiter (who sent us the candidate!) was ACTIVELY selling him to reject our HIGHER offer and instead take an offer from another company! What the hell? My team was so pissed.

    But of course this happened. We had smartly (and stupidly) negotiated the fee down. Let’s say we offered the engineer $150K, the other company offered the engineer $140K, and you’re the recruiter — would you rather get 30% of $140K, or 15% of $150K?

    Was this unethical of the recruiter? Yes. Is this how the world works? Also yes.

    You get what you pay for. The world is a competition and you are better off maximizing outputs versus minimizing inputs.

    The platform (almost always) wins

    Originally posted as a Twitter thread on November 10, 2025


    The platform (almost always) wins

    The spreadsheet was invented in 1979 by VisiCalc. VisiCalc lost 50% marketshare within 4 years to Lotus, and Microsoft obliterated Lotus within 15 years.

    These “creative destruction” cycles used to take decades. With AI, they can take…months?

    Cloud and mobile made distribution almost instantaneous, and AI makes the creation of software faster than ever in history.

    Which is why moats really do matter, and why systems of record rule supreme. The good news is that there are new systems of record just waiting to be built…for industries that just never had them before.

    https://a16z.com/fruits-of-the-walled-garden/

    https://a16z.com/ai-turns-capital-to-labor/

    Outcome Based Pricing

    Originally posted as a Twitter thread on June 21, 2024


    Can’t wait to see the first “incumbent” (in a large software field…like support, CRM, HR, etc) switch from “per-seat” pricing to **per-outcome** pricing.

    I’m writing an essay on this now, but consider Zendesk at $115/seat per month…or ~$1.4M/year for 1000 agents:

    Let’s say an agent is paid all-in $75,000/year and answers 2000 tickets per year.

    This makes the human cost of a ticket $37.50, and the software cost $.69.

    The human cost obviously massively outstrips the software cost…and unlike software licenses, it can take months to “install” (find, hire, train) a human to occupy that seat. And in many areas there is simply a dearth of qualified humans given licensing latency

    In other words, you can’t simply lift wages and produce more workers…if it’s a role that requires licensing or sufficient training (think mortgage brokers, nurses, etc)

    Not to mention the fact that it’s hard (and cruel!) to “flex” humans. Southwest Airlines can’t hire tons of humans when bad weather threatens to cancel flights and then fire tons of humans when weather is clear. But software is perfect for this

    So: given the rate of improvement in AI for asynchronous support — what will it take for Zendesk to switch from (in the prior example) $115 per seat per month to, say, $10 per successful ticket answered BY Zendesk? Still much cheaper, more flexible, instant provisioning

    It’s obviously going to happen, but how should they price this — it’s the ultimate example of value-based pricing? How to have this interact with existing “seats”? How to have teams not feel threatened by their new AI colleagues filling “seats”?

    Whole industries will change, and new ones will be created now that software can produce the outcome vs simply be the tool.

    Salesforce charges per-seat pricing for salespeople…why not charge per sale?
    Maybe Workday can charge for HR “resolutions”
    Etc

    The Pre-Mortem in Product Planning

    Original Post: https://x.com/arampell/status/1772734627410571443?s=20

    Before you launch a new product, one of the most counterintuitively important things to do is to plan for how to kill or exit the product. FAST.

    This isn’t as simple as it sounds…and it’s crucial for companies with multiple products or consulting work.

    My company, TrialPay, was the leading company doing “offers” en lieu of payment. I realized we strategically needed to be in the more commodity payment processing space, more background here: http://www.arampell.org/2015/11/04/distribution-v-innovation/

    We built this payment business to 9 figures of payment volume, but didn’t have sufficient focus to make it our top priority, and we were nowhere close to being #1 in the space. (Most value accrues to the #1 or MAYBE top 2-3 players).
    But our core clients were using it!

    This is why a pre-mortem is so important. We used our goodwill and “bundle economics” to cross-sell current customers on what had become a 2nd rate product. If we shut it down, they’d be PISSED and would potentially dump us for our core product!

    So what to do? We were honestly stuck. Against the backdrop of massive pressure against our core business, per thread below. We needed to focus on what we were great at.
    https://x.com/arampell/status/1562557849128931328?s=20

    Our only answer was to find a home / new product for our customers. I called the then CEO of Braintree and basically offered our customers and product for free — he said “what’s the catch?” It’s not every day that a competitor (us) voluntarily capitulates…

    But our real competition was FOCUS. It was clear we had lost the battle to be #1 in raw payment processing. Dedicating resources to be a distant #8 was more expensive than getting nothing for this asset.

    The next step was to gingerly mention this to our clients without having them ditch us for our core, profitable offers product. This was hard. But we made it work.

    Being an entrepreneur means being able to make the best of the hand you are dealt but also knowing when and how to switch tables. And switching tables dispassionately — when you have teams and customers “stuck” to the old table — is hard

    This is one of the reasons to be VERY cautious about doing consulting work. Building a custom product for a marquee client sounds great to make ends meet, but you can’t kill it! You’ve just added a liability to your balance sheet. You have to support it…forever!

    Theoretically you could kill it, but then good luck selling another product to that company. If you need to do a RIF, and you’ve gotten pre-paid for this software, how do you cut the team supporting this product that represents 0% of your future…?

    So always, always think about this hidden “liability” on your business. Before you customize, contract, or test something…have a well thought through plan to KILL your new thing. Bake it into all your processes, contracts, code, culture, etc.