Who pays is not who uses
The user and the payer are often different people with different incentives — confusing the two is why the pricing page never converts.
A pricing page can be well written, correctly priced, and still never convert — because the person reading it is not the person the product was designed to delight. That gap has a name: the user is whoever gets value from the product day to day; the buyer is whoever decides to hand over money for it. Most consumer software collapses the two into one person and never makes you think about the difference. A kids’ product cannot collapse them, because a child playing a maths game is, in almost every legal and financial sense, not allowed to be the buyer.
The split hides precisely because it is invisible on the projects where it does not matter. If you built a habit tracker for yourself and are now selling it to people like you, buyer and user are the same person, and every instinct you have about pricing and marketing was formed on that assumption. Point those same instincts at a product where a child uses it, and they misfire in a specific, predictable way: you write copy that would delight the user and wonder why the buyer never clicks pay.
The idea, and exactly how far it goes
Christensen, Hall, Dillon and Duncan’s framing for why anyone buys anything: “When we buy a product, we essentially ‘hire’ it to help us do a job” (Christensen, Hall, Dillon & Duncan, Know Your Customers’ “Jobs to Be Done”, HBR, September 2016). The job is defined by the circumstance the customer is in, not by who they are demographically — which is why two people who look identical on paper can be hiring the same product for entirely different reasons.
Inside the article, one example does exactly what this lesson needs: American Girl dolls. The article separates the girls who play with the dolls from the parents who buy them — the girls hire the doll to help articulate their feelings and validate their sense of self; the parents, described in the article as the buyers, hire the same doll to start a conversation with their daughters about the generations of women before them. Same object, two different jobs, depending on whether you are the one holding it or the one paying for it.
Three buyers for one kids’ product
Take a maths learning site for kids and ask, honestly, who could be the buyer. There are at least three candidates, and each one changes the price, the sales motion, and the product itself.
The child — user, essentially never buyer
The child is the one whose attention decides whether the product works at all: does it hold them past the first five minutes, does it feel rewarding rather than like homework. But a child does not hold a credit card, and in most jurisdictions cannot form a binding contract. Their job for the product is real and it drives retention, but it is never the job a pricing page needs to sell to, because the child is structurally excluded from the decision to pay.
The parent — a consumer buyer with a different job
A parent hiring a maths app is not hiring the same thing the child is. The child wants it to be fun right now. The parent’s job is closer to: give me evidence this is good for my kid, without me having to supervise every session. That job shows up as a demand for visible progress, a sense that the content is safe and age-appropriate, and proof it is not just a screen-time babysitter dressed up as education.
That job shapes the whole product, not just the pitch: a parent-facing progress dashboard, a low-friction self-serve price a parent can put on a card without asking anyone’s permission, and a sales motion that runs through an app store listing, reviews, and word of mouth from other parents. Nobody signs a contract. Somebody taps a button.
The school — an institutional buyer with a different job again
A school buying the same maths app is not a bigger parent. The job a district administrator or teacher is hiring the product for is closer to: does this align with our curriculum standards, will it survive an IT and privacy review, and can I defend this purchase to a budget committee. None of that is on a parent’s mind, and a pricing page built for parents answers none of it.
The price itself changes shape — a per-seat or per-site license, invoiced rather than swiped, often negotiated rather than posted. The sales motion changes shape too: a demo, a pilot, a procurement process with its own paperwork, on a timeline set by the district’s budget calendar rather than by how convinced the buyer feels in the moment.
Why the school sale is a different business, not a bigger version
It is tempting to treat the school as just a parent with a bigger budget — sell the same product, charge more, done. Four separate mechanisms say otherwise, and each one is a real, citable constraint rather than a vibe about “enterprise sales being slower”.
Student data privacy changes what “signing up” means. The US Department of Education’s Privacy Technical Assistance Center, in its February 2014 guidance, lays out how a vendor is typically allowed to hold student data at all: under FERPA’s “school official” exception, which requires the vendor to be under the district’s direct control over how records are used and maintained. In practice, that control is established by a signed contract, or Terms of Service written to contain the necessary provisions. The consumer-style click-wrap TOS that a parent accepts without a second thought is, for a teacher clicking the same button, an unauthorized act of contracting on behalf of the district. The frictionless self-serve signup is not a smaller version of the school sale. It is the wrong shape of transaction entirely.
Federal procurement rules replace “add to cart”. A district spending federal education funds must follow one of a fixed set of procurement methods — micro-purchase, small purchase with quotes, sealed bid, or a proposal process (2 CFR § 200.320), with noncompetitive purchasing allowed only in narrow cases such as a single available source or an emergency. None of those methods has a checkout button.
State law adds its own bid threshold on top. In New York, any purchase contract over $20,000 must go to the lowest responsible bidder after a public solicitation for sealed bids, and school districts are explicitly covered (NY General Municipal Law § 103). Cross that number and the sale is not a checkout flow. It is a formal bid process with its own paperwork and its own clock.
The budget calendar sets the timing, not the buyer’s enthusiasm. A district’s annual budget statement has to be finished at least seven days before the budget hearing and posted publicly for the fourteen days before the annual vote (NY Education Law § 1716). A parent can decide to buy at 9pm on a Tuesday because their kid asked. A school buys inside a fixed annual cycle with statutory notice periods attached, and if you miss the window, the next chance is not next week — it is next year’s budget.
Where people get burned
None of this means the school sale is worse — a signed site-license contract is a far more durable revenue line than a parent who can cancel a subscription from their phone in ten seconds. It means treating it as “the same product, more zeroes” will produce a product built for the wrong job, a price quoted in the wrong shape, and a sales motion aimed at a decision-maker who was never going to click a checkout button in the first place.
Picking one buyer before pricing anything
A single project cannot credibly build for all three jobs at once — the parent-facing self-serve product and the school-facing procurement product pull the price, the sales motion, and often the feature set in opposite directions. The move is to pick one buyer deliberately, before a price gets written down anywhere, and let that choice decide the shape of everything downstream: consumer price on a credit card, or invoiced license through a procurement process. Both can be right for the same underlying product. Neither is right by default, and pricing before choosing is how a project ends up with a page that tries to speak to both and convinces neither.
Retrieval check
For a kids’ learning product: name the buyer, name the user, and name the one thing the buyer needs to see that the user does not care about at all.
Check your answer
User: the child. Buyer: whichever adult or institution you picked — most often a parent, or a school. They are rarely the same person, and the child is essentially never the buyer regardless of which adult it is.
The one thing the buyer needs that the user could not care less about is evidence — a parent wants visible progress and a sense the app is safe and worth the money; a school wants curriculum alignment and a privacy story that survives an IT review. The child wants none of that. The child wants the next five minutes to be fun. A product that only optimizes for the child’s five minutes will struggle to ever get bought, no matter how good those five minutes are.
Now run it: the Buyer gate, on the shelf
This is the Buyer gate run for real — on the projects where a buyer and a user could plausibly be different people, which is a smaller set than the whole shelf and the first thing the exercise makes you decide.
Hands on
Name the buyer, separately from the user
Done when: PORTFOLIO.md’s Who pays field is filled for every project where a buyer and a user could plausibly differ, each named specifically enough to imply a price shape and a sales motion — and the projects where they genuinely cannot be separated say so explicitly.
- Go down the shelf and mark which projects could plausibly have a payer who is not the person using the thing. Anything aimed at children, at employees, or at anyone spending someone else’s budget goes on the marked list. The rest do not need this exercise.
- For the first marked project, write in one line who uses it — the person whose attention decides whether the product works at all.
- Then, on a separate line, write its Who pays field in
PORTFOLIO.md. Name the buyer specifically enough that the name implies a price shape and a sales motion: not “consumers”, but “a parent, self-serve, on a card” or “a school district, invoiced, through procurement”. If two buyers are plausible, pick one — picking later is what produces a page that speaks to both and convinces neither. - Next to it, write the one thing that buyer needs to see which the user does not care about at all — visible progress, a privacy story that survives an IT review, a line item a budget committee will approve. If you cannot name it, you have picked an audience rather than a buyer.
- Repeat for the rest of the marked list. For any project where buyer and user genuinely cannot be separated, write that down too — it is a real answer, and it is different information than not having checked.
- Bring the filled fields into the chat. I’ll push hardest on a buyer named vaguely enough to fit two different price shapes, since that is the answer that feels finished and decides nothing.
What this does not cover
Naming who pays tells you the shape of the sale. It says nothing yet about the shape of the money itself — whether that buyer hands it over once, every month, per use, or never directly at all. That choice comes next.
Read this next — primary source
Know Your Customers’ “Jobs to Be Done”Christensen, Hall, Dillon & Duncan, Harvard Business Review, September 2016 (reprint R1609D) — paywalled after the opening paragraphs
The article’s real claim is that a product is “hired” to do a job — and the job is defined by the customer’s circumstance, not their demographics. Read it for that mechanism. It also contains, in one sentence, the exact split this lesson is built on: a doll doing one job for the child who plays with it and a different job for the parent who buys it. That sentence is as far as the article takes it — everything else in this lesson about parents, schools, and pricing is this course’s extension, not Christensen’s.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.