Buyer Persona

In products sold to companies, the person who opens the app every day and the person who approves the invoice are rarely the same person. For a long time, though, teams carried only one page, and that page described the daily user. Screens were designed from it and feature order was argued from it, and the result was a product that got easier to use while contracts stayed unsigned.

The mismatch surfaced late in the sales cycle. A practitioner would like the product enough to propose it internally, and the next person in the room would ask questions without ever opening a screen: which servers the data sits on, whether the contract can follow the company's standard template, whether an admin can revoke a departing employee's account in one action. Nothing in the prepared deck addressed any of it, and putting answers together took another two weeks.

A buyer persona exists so that person isn't met for the first time in that meeting. Keep a page for the approver next to the page for the user and product, sales, and marketing all start aiming at the same person from their own seats.

It uses the same six rows a persona page uses. The rows are identical; what fills them is not.

1. Name and role — something you can say out loud, like Seojin, IT operations lead. The title alone hints at how far up the approval chain this purchase travels.
2. Situation — company size, how many people they administer, and whether they can approve this amount alone. If anything under $4,000 a year is theirs to sign and anything above goes to an executive, write that line down as it is.
3. Goal — not what they want to finish in the product, but what they want this purchase to achieve. Consolidating four scattered document tools into one to cut admin overhead is the right shape.
4. Reasons to object or delay — the equivalent of the user's blockers, which for an approver usually appear as risks. Whether it clears a security review, whether a small vendor will still exist in two years, when the contract for the current tool expires.
5. Decision criteria — what they actually look at. Not editing speed, but admin permission settings, audit logs, usage reports, and how invoices are issued.
6. Representative quote — one or two lines heard verbatim in a meeting. Something like "we can't run the security review on your behalf" is what marks the other five rows as observed rather than invented.

Products sold to companies get one more row: who else is in the decision. Adopting a single tool often moves a practitioner, their manager, a security officer, and a procurement officer together, and that group is the buying committee. One page can't hold all of them, so the person carrying the most weight becomes the subject and the rest get a line listing what each one cares about.

The draft belongs to whoever has actually sat across from this person. Usually sales brings the meeting notes and a product manager shapes them into one page. If the team already keeps an ideal customer profile (ICP) describing which companies fit best, the approver is chosen from inside those conditions. A page written alone by someone who has never met a customer ends up as titles and guesswork, shown once in a meeting and never opened again. Material comes from both won and lost deals — row 4 is filled by why people stalled rather than why they bought, so teams that keep records of lost deals write more accurate pages.

The readership is wide.

1. Sales — what to lead with in a first meeting, and which sections a proposal needs.
2. Marketing — the pitch changes wording. Users hear that it's fast; approvers hear that four tools become one.
3. Product — admin screens, permission settings, and audit logs are things daily users never request, and this page is what moves them up the list.
4. Leadership — it informs how plans get priced and packaged.

Fewer pages is better. Split approvers into five types and meetings start by arguing over which page governs. Start with one and split only once you have customers at genuinely different scales.

"That one's for the buyer persona. The approver sees it, not the daily user."

It's absent from the user request list but it's blocking contracts.

"Row 4 of the buyer persona still says security review. Let's clear it this quarter."

The same reason for stalling has carried across quarters.

"Buyer and user are the same person for us, so we never made a separate buyer persona."

A consumer product needs only one page.

At Pagedeck the page got written when the company started selling to 50-person companies. Sofia gathered records from seven deals that had stalled over three months and the same sentence kept appearing: no material to pass a security review. Mia drew a page from those records, and row 4 came out as security review and offboarding account revocation. Those two lines are why an admin permissions screen landed on the next quarter's roadmap.

Grace uses the page in pricing discussions. It records that approvers ask for annual contracts and proper invoices, which is where the decision to launch the company plan on annual billing first came from.

The most common mistake is treating it as a user persona with a different job title. Same template, same six rows, so changing the name and the seniority feels like enough. But the two people differ starting with how much time they spend in the product at all. An approver often spends less than five minutes a day in it, so editing speed never enters their criteria. Swap only the title and the goal and criteria rows still carry the user's concerns, and a proposal built from that page answers none of the questions the approver asks.

The second mistake is drawing one approver and stopping. One signature closes the deal, so one person looks like the whole job. In practice a security officer and a procurement officer stand in front of that signature, and if either one stalls, nothing else moves. Leave the relationships off the page and weeks pass with nobody able to say where the deal is stuck.