Social Job

Teams that wrote requirements purely as features kept running into outcomes they couldn't explain. The demo goes smoothly, the person watching says it looks good, and the deal never moves. Going back through the feature comparison shows nothing missing.

What was actually in the way often wasn't a feature. Whoever proposes switching tools internally also carries the risk of hearing "why did we change this?" six months later. Suggest replacing a tool that 45 people use and the decision sits in front of 45 people. If it goes well nobody says anything; if it goes badly a name is attached to it. That risk had no column in the feature table, so it never appeared in a requirements document.

Jobs to be done (JTBD) — the view that reads demand through the job a customer hires a product to finish — treats a single decision as three layers stacked on each other. The social job is the name for the layer where other people's eyes are involved. Once it had a name, "great demo, no contract" turned into a question with a specific place to look.

It works because somebody is watching the decision. That's why the same product gets judged differently when one person uses it alone and when a team adopts it in public.

The three layers divide like this. A functional job is the task that has to get done, so it's confirmed by results. An emotional job is how someone wants to feel along the way, so only they can report on it. The social job is the only one of the three with a third party in it, which means part of the outcome stays outside the customer's control.

Take one apart and three pieces come out.

1. Who is watching — colleagues, a manager who holds the decision, or outsiders like customers and job candidates. Whose eyes matter changes what the product needs to provide, so this piece gets settled first.
2. How they want to look — as someone who stays on top of things, as someone whose judgment is reliable, or as part of a team that has its act together.
3. How they'd look if it fails — the version of the story where the switch goes badly. This piece pulls hardest. People move more to avoid looking bad than to look good, so the safest-looking option often wins over the best one.

Customers don't say any of this out loud. Ask why adoption stalled and the answer is that the security review isn't finished. That's not false, but it isn't the whole thing either. Nobody reports having decided based on how they'd be perceived; they substitute a reason that can be said in a meeting.

The strength of this layer scales with how public the decision is. A note-taking app one person uses alone barely has one, which is why features alone can sell it and why consumer tools get evaluated so quickly. A tool a whole team has to move onto together is the opposite case — here this layer holds the decision.

Four places, in the order you find it, write it, build for it, and talk about it.

1. Interview interpretation — a switch interview, where you find someone who recently changed products and walk back through the moment they switched, surfaces this layer when you ask about hesitation. Ask what they liked and you hear about features. Ask what made them hesitate and you hear about what someone else would say.
2. Requirement statements — it goes in the expected-outcome slot of a job story. "When I send a new hire a single document link, I want to leave the impression that this team is organized" has the shape.
3. Screens and features — weight goes to whatever other people see. The first screen behind an external share link, how an exported document looks, whether a document list reads as tidy. The inverse also applies: a screen only its owner ever sees doesn't earn investment on these grounds.
4. Supporting the internal champion — the product side builds the case that person has to make inside their company. A page on permissions and security, an example from a company of similar size, a clear account of how reversible the move is. Product positioning, the place this product is meant to occupy in a customer's mind, has to use the same language as that case.

"The features are all there, so why isn't it closing? We never gave the person championing it anything to say internally."

The blocker isn't the product; it's the risk that person is carrying.

"Only the owner ever sees this screen. It's not where the polish belongs."

No outside eyes reach it, so this layer gives no reason to invest there.

"The external share link doesn't show the team name anywhere. This screen goes out to their customers."

Users forward this view to other people, so it gets judged by a different standard.

At Pagedeck, Mia ran six switch interviews to understand why three enterprise accounts stopped after the demo. All six said the features were fine. Three of them said the same other thing: proposing that the whole team drop the tool they already use is uncomfortable. Sofia added what she'd seen from her side — the document buyers actually asked for wasn't a feature comparison but the procedure for reversing the migration if it went wrong. So what the team built the next quarter wasn't a feature. It was a guided path showing that existing material moves over in two days and can be rolled back at any point.

The most common position is that this is vanity and can be ignored. Wanting to look good to other people doesn't feel like a real need. But this layer is risk management rather than taste. The person who proposed the change carries actual exposure, and until that exposure shrinks the decision keeps sliding. Ignore it and ship ten more features and the demo success rate holds while the contract rate stays exactly where it was.

The other misreading hands it to marketing. Managing how someone is perceived sounds like a messaging problem. But the places this layer binds are mostly inside the product: what the external share view looks like, whether a migration is reversible, how finely permissions can be split. None of that can be fixed with copy. Treat it as an advertising job and what the buyer heard in the demo stops matching what they see on screen, and the mismatch surfaces at the last step before signing.