The marginal utility of what I’m doing right now
Last time, we prompted an AI to generate a beautiful PRD for a biodiesel drone that should never exist. The document was lovely. The idea was terrible. And while it was easy to tell the difference this time, it’s also easy to see how toning down the prompt just a bit would make it much trickier to spot the vapidness of the output.
That's the trap: when artifacts look right, we assume the thinking behind them is right too, especially if we weren’t there to vet the process. But in this case, the artifact wasn’t the work, it was just evidence that work happened. Or, was supposed to have happened.
Today, I want to share the framework that helps me spot the difference between value-add actions and expensive theater. It's helped teams figure out where AI actually belongs in their stack. More importantly, it's helped them stop wasting humans on tasks that don't matter.
Work, Friction, and Waste
So, how can you tell the PRD isn’t the part “that counts?”
There’s a simple framework for understanding the impact of the action you’re taking or the artifact you’re building: Work, Friction, & Waste. You might recognize the terms from an intro physics course, or from similar concepts from Jobs-to-be-Done1 (Work, Work-of-Work, and Waste), or Lean and Six Sigma (Work, Motion, and Waste)2. The concepts are similar, but to the uninitiated, the word choice of “Friction” is, in my opinion, way more intuitive.
Depending where you first heard them, the definitions taught to you for each of these items could have been quite complex. I personally like keeping them extremely simple:
WORK → What customers pay you for
FRICTION → What allows you to get paid for Work
WASTE → Everything else
I’ve spent a lot of time thinking through and boiling down this framework - first picking up elements as a consultant, then really building out and testing the theory for modern work at Slack, and now at gigue adapting it to how humans should be employing AI. Since I suspect most folks haven’t put nearly that much thought into it, I’ll take a sec to walk through where I’ve gotten with it:
What is the definition of each activity?
How does it look in practice? (we’ll use a “Mutually-Aligned Action Plan” (MAAP) example to help with the nuances)
How should I invest resources in this activity?
Work
Work is the most important of the three activities. There is a simple brightline for what counts as Work and what does not: Work is something the customer would pay you for3.
Be very careful and very strict with this definition: it’s tempting to say “the customer won’t pay us unless we have professional marketing copy” or “the customer won’t pay us unless we build this deck for the MAAP call” - sure, but they won’t pay you for the copy / deck itself, which changes how you handle the time and effort you invest into those assets4.
That does not mean that only Product is Work, or only Sales is Work. Customers will pay for SOC2 compliance; customers will pay for net-60 payment terms; customers will pay for reliable on-time delivery; customers will pay for <5 min response time on service channels with >97% SLA during business hours.
This is not an excuse to be elitist or to partition the functions of the business into haves and have-nots. It’s a strategic razor for activity: for everyone, whether they roll up to Product or Sales or Legal or Finance or Ops or CX, will the energy they spend on this particular activity return revenue or not?
Because Work is something the customer would pay you for, there is generally good reason to improve it at any given time5. Not every dimension a customer will pay for has high ROI - clever product design is still a thing - but at a super-high level “improving the Work” is a good use of resources provided you can tactically figure out the right way to do so.
Friction
Friction is activity that is necessary to effect the trade of Work for money with the customer. That definition is broader than the Work definition (Friction is not just e.g. finserv APIs and delivery couriers - it is anything that has to happen for the exchange of value to complete). The activity of building the MAAP deck from above? Friction6.
Think of the classic physics example of pushing a box on the ground (the one I used in my diagram). The effort you spend pushing can be split into two parts: the effort that moves the box along the straight line, and the effort spent overcoming the drag where the box touches the ground. You can’t not spend the effort on Friction: if you decline to spend it, the box doesn’t move and the Work doesn’t get done.
But, unlike your undergrad physics homework, you control the terms of engagement. You don’t have to choose scenarios with high Friction, and you definitely don’t want to optimize for high Friction7. Instead, you want to optimize for Work-over-Friction - how can you maximize the Work you get done and minimize the Friction it takes?
Take the MAAP example - let’s say the Work is a SaaS product, but the customer is also in part paying for security vis-a-vis an ELA with legal protections, payment terms instead of credit card transactions, and implementation help we’re setting up on this action plan. Some parts of this process, then, are Work, and some aren’t. How can we minimize Friction?
We could skip the Mutually-Aligned Action Plan step altogether, but that actually materially impacts the odds we get a contract signed, and definitely impacts the odds that contract renews (because it reduces the value the customer gets from the contract, so it becomes something the customer would pay for - just not how you’d traditionally think of it). Ok, so Work is happening in that step, we don’t want to throw out the baby with the bathwater here.
Do we need the deck to be built custom for every single customer, every single time? Probably not - there’s probably a good MAAP template that needs small tweaks each time, and we probably get better results that way. Friction pulled out.
Do we need to align the MAAP with the customer? Definitely. It’s in the name. How much back-and-forth do we need? When do we pull the champion in? Can we ghost the doc, prep a live tracker, pre-stage the artifacts we know they’re going to want, hook the doc into our conversation to get dynamic updates? Every bit of Friction we’re pulling out is helping, and every time we improve actual alignment and plan adherence is doing actual Work - it’s the service the customer is (about to be) paying us for.
Do we need meetings for all this? A champion meeting? A draft session? An exec sponsor review? Weekly check-ins? Again, we’re solving for maximizing the alignment of the teams against how much effort it takes to get said alignment. Meeting-phobia vs technophobia is a team preference question, in my experience… but you can get pretty clever on firing updates proactively, early, and eagerly to short-circuit the perception that misalignment has happened or could happen, which pushes the Work / Friction balance decidedly in your favor.
It’s often tempting to do the exact opposite of this approach in practice. Mutually-aligning with a high-value customer is important! and you can talk yourself into spending hours or days on fine-tuning the deck, discussing the ins and outs of punctuation and meeting cadence (which is tipping into the Waste section we’re getting to next) because you’ve convinced yourself that this is what they’re paying you for.
They’re not.
They’d much rather that energy go into the actual relationship and execution of the deal and implementation, rather than the spit and polish of the deck that merely implies relationship and execution, or the meetings about the meetings about the alignment around the implementation that start to actually impinge on the implementation.
The key dynamic for Friction is that investments into Friction assets can be helpful, but they have very low ceilings before they start getting counter-productive. Meanwhile, basically every effort you put into removing time and effort spent on Friction pays dividends, because it increases the Work any given team member can get through their pipeline & get done in a day.
Each little trick you can pull that doesn’t affect Work but does remove Friction usually benefits you8. You may not hear the benefit straight from the customer - remember, they often don’t really care because they’re not paying you for Friction - though in reality low Friction processes often get noticed and commented on because they imply that other processes will also be smooth; they set positive future expectations. They become a source of expected value in their own right (but they still aren’t Work yet).
Waste
The last term in the framework is Waste - which is probably the easiest to understand and the hardest to root out fully, especially in larger companies. Most companies I’ve consulted for, sold into, or advised have codified pretty decent amounts of waste into their processes and convinced themselves that it’s completely irreplaceable9.
Before we get too far: a ton of folks get frustrated by processes that feel Wasteful but do have purpose (maybe not Work, but at least Friction). Those could be regulatory checkboxes, accessibility concerns, or prep and coordination for a team whose processes just aren’t visible to the person accountable for the action.
The best practice in these situations is, to the greatest extent possible, to label what things are. Even if you can’t be precise, saying something like “this process creates xyz metadata which protects us from liability”10 helps both with morale and with humans + agents trying to figure out what pieces of any given process they can adjust or excise entirely.
This will become even more important as more agents get involved in your workflows. Not because they have more morale issues than humans (obviously) but because they aren’t expecting to or particularly adept at reading between the lines, and the un- or under-labeled data and processes are the ones agents mishandle.
Ok, but: there’s a bunch of things that don’t fall into that category. They’re not things the customer would pay for, and they’re not necessary for getting paid. Maybe they’re coordination artifacts, maybe they’re vestigial flows from an abandoned consulting project, maybe they supported a long-since deprecated piece of software.
Moving a contract forward is Work, and therefore so is mutually-aligning with them on the contract and implementation plan. Building the deck that spells out that plan is Friction - necessary, but there’s a (very shallow) upper-bound on how much work is actually valuable, and there’s a very clear straight-line to value for every minute and calorie you can take out of the deck-building process (because it opens up more Work throughput for those AEs / SEs / etc).
Holding MAAP deck review internal syncs? Could be Friction - depends on how mature your team is - but the longer they go on, the more likely they’re Waste. The customer definitely wouldn’t pay for them (so can’t be Work) and while they might have a straight-line dependency to delivering work for a brand-new junior AE warming up to the company’s MAAP process for the first couple times, odds are they stop supporting Work and start supporting bad habits really quickly.
If the MAAP doesn’t get built without the sync - big problem, and running a Wasteful meeting on repeat is not the right way to handle it. If an exec can’t gather context on the deal without the sync (despite having a CRM and a RevOps platform and a team channel and an account channel and 12 other expensive tools) - also a big problem. That weekly pipeline review where everyone reads their deals out loud like so many bedtime stories while the VP could have just read the CRM updates he asked for? Pure Waste. One company I worked with killed it, saved easily 5+ hours per week per rep, and saw no change in forecast accuracy11.
Not all meetings are Wasteful, but meetings that are crutches for basic accountability definitely are.
Waste has maybe the clearest investment criteria of all three: invest in removing it, wherever you find it. No Waste activity merits an incremental calorie, and cutting ruthlessly will often expose things about the business you didn’t know.
Given the mandate for AI and agents in most companies right now, you have a moment: if you’re frustrated with anything about the way your job works, now’s the time to propose a change. (If it involves, even tangentially, the use of AI, odds are you’ll get greenlit).
To recap
Once you see the actions you take through this lens, you can't unsee it. Every meeting becomes a question: is this moving us forward or just keeping us busy? Every document becomes a test: would the customer pay for this or are we just play-acting?
The framework is simple. Applying it is hard. Because it means admitting that a lot of what we do every day does us no good.
Next time, we'll put this framework to task. We’ll figure out how to assign activities to humans and agents based on Work, Friction, and Waste. Spoiler: in the MIT study that showed 95% of companies got no or negative ROI from their AI projects, the number one culprit was tapping agents to execute Waste activities instead of cutting them outright.
Not going to go into the J2BD framework, but the basics can be found here: https://www.christenseninstitute.org/theory/jobs-to-be-done/
Also going to skip over the details on Lean, but the basics are here: https://theleanway.net/The-8-Wastes-of-Lean
Example: When Stripe simplified payment integration from weeks to minutes, that was Work. Not the documentation, not the sales deck: the actual reduction in developer time was incremental value that customers were willing to pay more for. (When their customers implemented Stripe to simplify their payment integration times or streamline their payments or invoicing, that was reducing Friction from their perspective. We’ll get there soon.)
Put another way: both Work and Friction are on the critical path to getting paid. That doesn’t make them equally valuable: some parts of the path ought to be shorter, and the difference between Work and Friction is “where can I shorten the critical path” versus “where would shortening the critical path turn around and bite me?”
You’re going to find exceptions to this everywhere - recessions, negative cash flow, margin pressure, death spirals, product deprecations, etc. Those are valid, and not the point. “Improving the Work” doesn’t mean gold-plating the commodities you sell: it means finding ways to continuously improve the price / cost / margin / value of your core products and services, according to your strategy, because directing that energy into improving Friction or Waste outputs is by-definition a less-valuable use of your resources. (Directing that energy into reducing the resources you spend on Friction or Waste, however, may be quite competitive)
Example: When Uber eliminated the need to handle cash or cards at the end of rides, they weren't changing the Work (the on-demand phone-based transportation). They were removing Friction: that awkward fumbling with payment that added time on the critical path but generated zero value. Instead, when the ride ended, you just… got out of the car. No waiting, no talking, no buttons, no hoping you had cell service. The ride quality stayed the same, but removing that transaction friction made the whole experience smoother and opened up their pipeline for more rides per driver per day and more rides per passenger per day. You wouldn’t have paid extra for no-contact payment terms, but it did become a source of expected value (it set baseline expectations that competitors didn’t meet, and it implied higher value on Work elsewhere for both buy-side and sell-side users).
This is why I don’t personally like “Work-of-Work” or “Motion” as the names for this term: they give the misguided impression that more Work gets done proportionately with the increase in Motion / Work-of-Work, which isn’t guaranteed to be true. You can create tons of useless Motion / Work-of-Work in service of the same amount of Work. Friction’s a better analogy for capturing that dynamic.
I made reference to the Lean term “Motion” and - while I prefer the connotations of the term “Friction” - I do recommend looking for Lean resources on how to minimize Motion since there’s already a slew of literature on the subject, usually referenced under “Lean Back Office.” Same for “Waste” later on.
Feel like it’d be mean-spirited to give a named case study here like the others :)
Instead of what the truth might be, e.g. “we would have lost a court case, but we took a super-secret settlement, and now we have to label all our shipments just so or we go right back to court again.” Obviously that’s a non-starter, but you don’t have to lay out all the gory details to provide enough context.
Turns out, if you invite n AEs to a t-minute-long status sync and have them each report for an equal amount of time, you systematically burn t(n - 1) minutes each time, since each rep spends (n - 1 / n)% of their time doing nothing, maybe listening to other people rattle off their CRM status, probably just multitasking or zoning out waiting for the meeting to end. These aren’t usually the “learning opportunities” they’re cracked up to be, especially when the attendee list gets long. 10 reps in an hour-long sync? 90% wasted time for each, burns 540 minutes for no good reason, not counting the time they needed to prep the updates and reschedule other conflicts. If they’re each at $150k OTE, that’s at least $675 per sync you didn’t need to spend. Replace these sessions: automate status updates, use meetings to handle direct tactical asks, and only invite the exact people needed for the ask.