Jobs To Be Done for AI Landing Pages

AI can write landing pages faster than you can review them.

That sounds useful until every page says the same thing in a different outfit.

Claude Code, Cursor, Codex, Hermes, and similar agents can turn one rough idea into ten headlines, five sections, three CTAs, and a polished FAQ. The writing is no longer the hard part.

The hard part is deciding what progress the visitor is trying to make.

Jobs To Be Done fixes that by making your agent choose the job before it writes the page:

job evidence -> job hypothesis -> landing-page promise -> activation signal -> measured learning

In plain English: what situation is this person in, what progress do they want, what should the page promise, and how will we know they moved closer to value?

TL;DR: copy this to your AI agent now

Use this before your agent writes a landing page, feature page, comparison page, or launch post:

Use Jobs To Be Done for this product. Inspect the product, docs, landing page, competitors, support notes or reviews if available, and current analytics context. Identify 5 possible customer jobs. For each job, explain the situation, the progress wanted, the trigger, the current workaround, the anxiety or objection, the landing-page promise, and one activation signal that would prove the visitor is moving toward value. Then choose one job to test this week and explain why.

Then ask for the page:

For the chosen job, write one landing-page hero, one proof section, one objection-handling section, one CTA, and one activation event we should measure. Keep every section tied to the job. Do not broaden the page to cover other jobs.

What is in it for me?

You stop reviewing generic pages.

That is the win.

Instead of asking your agent for another “better” landing page, you get a smaller decision:

What improves	Why it matters
The page	It is built around one customer progress story, not a vague audience.
The prompt	Your agent has a situation, trigger, workaround, objection, and success signal before writing.
The readout	You judge whether visitors moved toward the job, not whether the copy sounded nice.
The next week	You know whether to keep the job, narrow it, or test a different one.

That is more useful than a pile of polished variants.

JTBD without the consultant smell

Jobs To Be Done says people “hire” a product to make progress in a situation.

For AI builders, do not turn that into a workshop. Use it as a guardrail for agent-generated landing pages.

A job should force useful decisions:

JTBD piece	What your agent should find	How it changes the page
Situation	What is happening when the visitor looks for help?	Sets the first-screen context.
Desired progress	What outcome are they trying to reach?	Shapes the headline and promise.
Trigger	Why now?	Makes the page feel timely instead of generic.
Current workaround	What do they do today?	Shows what pain the product replaces.
Anxiety or objection	What could stop them?	Decides what proof or reassurance belongs on the page.
Activation signal	What behavior proves progress?	Turns the page into a measurable test.

No job, no page. No progress, no promise. No activation signal, no readout.

Segments are not jobs

A segment tells you who you are talking to.

A job tells you what they are trying to get done.

Those are different decisions.

Bad:

Founder wants analytics.

Better:

Solo AI builder launches three growth surfaces in one week and needs Claude or Codex to know which one deserves more work.

Bad:

Marketer wants more conversions.

Better:

Growth lead needs to prove whether a new ICP page creates qualified activation before scaling the content cluster.

Bad:

Recruiter wants scheduling automation.

Better:

Recruiting team at a 50-person startup needs to book qualified first-round interviews before candidates go cold.

Now the page has something to do. The headline, proof, CTA, and activation event all change.

Turn the job into page sections

A job is useful only if it changes the page.

For the recruiting example, the page should not say:

Automate scheduling workflows for modern teams.

That could be for sales, support, healthcare, consultants, or anyone with a calendar.

A job-shaped promise is closer to:

Book qualified first-round interviews before candidates go cold.

Then every section has a job:

Page section	Job question	Measurement signal
Hero	Does the visitor recognize their situation?	First-screen engagement, low quick-exit rate from the target source.
Problem	Does the page name the current workaround?	Scroll to problem section, time on page, interaction with comparison/proof.
Proof	Does it reduce the main anxiety?	Case-study clicks, integration clicks, security or setup detail views.
CTA	Does the next step match the job?	CTA clicks from the target segment.
Onboarding	Does the visitor reach first progress?	Calendar connected, first interview scheduled, or another job-specific activation event.

This is where AI pages get better. The agent is not only writing. It is tying the writing to a behavior you can read later.

Make the test small

The TL;DR prompt gives your agent candidate jobs.

Do not let it turn that into a giant strategy deck. Pick one job, one page, one promise, one activation signal.

A good one-week test fits in one row:

Job	Page promise	Surface	Activation signal	Kill condition
Recruiting team needs faster first-round scheduling before candidates go cold	Book qualified first-round interviews without another coordination thread	Landing page + demo booking flow	First interview booked or calendar connected by a qualified visitor	Visitors click the CTA but do not connect calendar or book any interview

Small tests are easier to read.

Measure job progress, not copy output

JTBD only matters if it changes what you measure.

Do not ask whether the agent wrote a better page. Ask whether the chosen job moved closer to done.

Good JTBD readouts include:

• which source brought visitors with that job
• whether they engaged with the job-shaped promise
• whether they clicked the CTA that matched the job
• whether they hit the activation event
• whether the objection-handling section changed behavior
• whether activated visitors came back
• whether they showed buying intent or revenue quality

If you use Agent Analytics, connect this to the closed-loop growth analysis guide and ask:

Use Agent Analytics to read the JTBD test for <project>. The job we tested was <job>. The page promise was <promise>. The activation signal was <event or behavior>. Compare source, page engagement, CTA behavior, and activation quality. Tell me whether to keep this job, narrow the promise, or test a different job next week.

The point is not to make the agent sound smart.

The point is to make the next page less random.

A 7-day JTBD loop for AI landing pages

Use this cadence when your agent keeps producing plausible pages but you cannot tell which one matters.

Day	What to do	Agent output
1	Collect job evidence	Review product, docs, competitors, reviews, forums, interviews, and analytics context.
2	Choose one job	Pick the job with urgency, reachable traffic, and a measurable activation signal.
3	Write the page	Draft the hero, proof, objection handling, CTA, and onboarding path for that job only.
4	Instrument the signal	Confirm the CTA, signup, setup, or first-value event is tracked.
5-6	Let behavior collect	Avoid rewriting the whole page before the first readout.
7	Read and decide	Keep, narrow, or kill the job hypothesis based on activation quality.

That is the workflow.

No ceremony. No giant research doc. One job. One measured page.

Common mistakes

1. Asking for personas when you need jobs.
2. Letting the agent choose every job because AI can write every page.
3. Writing the page before naming the activation signal.
4. Treating traffic as proof when the visitor never reached value.
5. Keeping a job-shaped headline while the rest of the page drifts back to generic copy.

How JTBD fits the series

Use Bullseye when your agent needs to choose channels.

Use AARRR when your agent needs to diagnose the growth loop after users arrive.

Use AIDA when your agent needs to find the leaking stage on a landing page.

Use STP when your agent needs to decide who a surface is for before it writes more copy.

Use JTBD when your agent needs to decide what progress that visitor is trying to make.

Read next:

• How to Use STP Marketing When AI Can Write for Everyone for segment, target, and promise discipline.
• Teach Your AI Agent AIDA for Landing Page Analytics for landing-page leak diagnosis.
• Your Product Isn’t One Website Anymore for multi-surface product context.

For setup, use the Agent Analytics Skill guide. For the product-system model behind multi-surface JTBD tests, read Projects, Surfaces, and Portfolios.

Final framing

AI made landing-page production cheap.

Jobs To Be Done is the pause before your agent writes another page for nobody in particular.

Name the job. Name the progress. Measure whether the visitor moved.

Otherwise you are only generating pages and hoping one of them accidentally matters.

Start free with Agent Analytics.

---

Source appendix

• https://strategyn.com/jobs-to-be-done/
• https://hbr.org/2016/09/know-your-customers-jobs-to-be-done
• https://www.christenseninstitute.org/theory/jobs-to-be-done/