Talk Stories:
Landing Page to 6.65/10

Executive Summary

Talk Stories is an AI content tool that lives in Slack. It learns how each person on a team writes, then generates content in their voice on demand. The product is strong. The landing page was not converting.

Starting from an existing redesigned page, we ran 5 rounds of synthetic user simulation across 20 personas, all run locally on a Mac Studio using qwen2.5:7b as the persona model and llama3.3:70b as an independent judge. No human users. No survey panels. No waiting.

In a single day, average conversion intent moved from 4.3/10 to 6.65/10, a 55% lift. Privacy objection rate dropped from 35% to 25%. Word-of-mouth signal (personas who said they would share the page) doubled from 15% to 30%.

What We Shipped

A production-ready HTML landing page incorporating findings from all 5 simulation rounds:

• "Early access" replaces "beta" throughout, more premium, less "unfinished"
• No product label ("ghostwriter" removed), description-first positioning proved clearer
• Dedicated privacy and security section: 4 cards, direct language, SOC 2 ETA
• Grounded voice proof examples, real numbers ($12K savings, $28M raised, 47 calls, 6 demos) not vague claims
• Testimonials section targeting the "will it sound like me?" objection directly
• "What the first week looks like" timeline, reduces workflow disruption anxiety
• Zero em dashes, no stiff phrasing, copy reviewed and corrected line by line

The Brief

The Talk Stories landing page existed. It had a hero, social proof, feature list, pricing, and a CTA. The question wasn't whether it was designed, it was whether it was working.

What We Needed to Know

• Does the current copy convert, or just describe?
• Which objections are actually blocking people from clicking?
• Does the product label "ghostwriter" help or hurt?
• Does "beta" feel right, or does it undermine trust?
• Are there specific lines that are actively scaring people away?

Constraints

• Text-only simulation, landing page was a local HTML file, not a live URL. Text extraction was more appropriate than UI automation for a read-and-react task.
• No cloud API calls, all models run locally on Mac Studio (256GB RAM). No per-token cost, no rate limits, unlimited iteration.
• Same 20 personas across all runs, consistent panel for longitudinal comparison across versions.
• Directional, not statistically definitive. N=20 gives roughly 90% confidence intervals on patterns, not 95% significance on individual claims. We're looking for signal, not proof.

The Product Context

Talk Stories is built for B2B Slack teams at 20-200 person companies. The target buyer is a content-bottlenecked role: founders who want to write but can't, heads of marketing who are drowning in requests, SDR managers whose reps never post. Pricing: ~$20-30/seat/month, free during early access.

The page needed to convert cold traffic from word of mouth ("a colleague sent me this"). Not SEO. Not ads. A human recommendation, followed by a first-impression read.

Research & Testing Methodology

Every round used the same core setup. Consistency across runs is what makes the comparative data meaningful.

The Persona Panel

20 synthetic personas, held constant across all 5 simulation rounds. Personas represent the actual target buyer distribution for Talk Stories: B2B Slack teams, 20-200 person companies, content-bottlenecked roles.

Model Selection

Two models, two roles, chosen specifically to avoid self-grading bias:

• qwen2.5:7b (Ollama, T2 tier), persona responses. Selected because it scored 100% on multi-turn evaluation in a prior eval suite. Fast, consistent, follows character prompts reliably. Runs at ~41,000 tokens/second on the local eval farm.
• llama3.3:70b (Ollama, judge), synthesis and scoring. Strongest model for analytical judgment tasks in our eval suite. Never used to evaluate its own outputs.

Task Prompt Design

The task prompt was intentionally neutral to avoid leading the witness:

"A colleague just sent you this link. You've never seen the product before. Take a look."

Each persona was then asked structured questions covering: first impression, comprehension, top objection, conversion likelihood (1-10), and whether they would share the page. Later rounds added section-specific questions as we introduced new elements.

Scoring and Synthesis

The judge (llama3.3:70b) synthesized each round after all 20 persona responses were collected. It was asked to:

• Calculate average intent score from the 20 individual scores
• Identify patterns hitting 5 or more personas (25% threshold for "real finding")
• Compare to the previous round's baseline
• Name the single highest-leverage change for the next iteration

All checkpoint files were saved after each persona response. Runs were resumable, if a run crashed mid-way, it picked up where it left off without re-running completed personas.

The Journey: v1 Through v5

Five rounds, five sets of changes, a 55% improvement in conversion intent. Here is every step.

Progression Summary

The Framing Experiment: 4 Variants Head-to-Head

Before rewriting anything, we ran a dedicated framing experiment: 4 complete versions of the hero and CTA copy, each tested against all 20 personas. 80 total runs. This is how we validated the "ghostwriter" question with data instead of opinion.

The 4 Variants

What the Data Revealed

"Voice Engine" scored highest because it puts the emphasis on your voice, not the AI doing something mysterious. The word "learns" does a lot of work, it implies the product earns accuracy over time rather than making claims it can't back up immediately.

"Ghostwriter" still works (7.0/10 is strong) but it carries specific baggage. Two distinct failure modes: (1) personas burned by AI writing tools before associated "ghostwriter" with the generic outputs they already hated, (2) the word implies authorship deception, which felt off for teams publishing authentic thought leadership.

"Story Engineer" underperformed despite seeming clever. The word "engineer" created false associations, technical personas expected a workflow automation tool, not a writing tool. Several personas asked if it integrated with their CRM or code pipeline. A label that requires disambiguation is a bad label.

"Waitlist" weakest CTA by far. It implies the product isn't ready. "Early access" implies exclusivity. "Beta" implies it might break. "Get early access" performs best, suggests something real you can use today, with the benefit of a lower price lock-in.

The Concrete Labels Finding

This experiment replicated a finding from other simulation work: concrete labels beat abstract ones every time. "Story Engineer" failed for the same reason "BUILD/TEST/LEARN" failed in other taxonomy work, abstract concepts require explanation. "Voice Engine" succeeded because both words are immediately graspable. "Sprint/Experiment/Note" succeed because all three are familiar, specific, and hard to confuse.

The pattern holds: if someone has to read the description to understand the label, the label has already failed.

Surprises & Course Corrections

1. "Everything You've Ever Written in Slack" Was a Dealbreaker

The original page included the line: "it's read everything you've ever written in Slack." This was meant to convey depth of context, that Talk Stories really knows how you write. In testing, it read as surveillance.

Multiple personas used words like "scary," "invasive," and "creepy." Several said they would not install anything that described itself this way, regardless of what it actually did. One persona called it "the kind of line a startup writes before they think about how it sounds to users."

Fix: Replaced with "learns from what your team chooses to share. You control what it knows." The replacement shifted the power dynamic from the product doing something to the user, to the user being in control. Privacy objection rate began declining in v3.

Lesson: Review your copy for lines that describe what the product does to the user. If it would sound bad in a headline, it should not be in your hero copy.

2. "Story Engineer" Failed for the Same Reason "BUILD" Failed

We expected "Story Engineer" to test well, it felt distinctive, memorable, and specific to the problem space. It scored 6.9/10. That sounds decent until you see that "Voice Engine" scored 7.35 and even plain description scored 6.8.

The problem: "engineer" is a loaded word in B2B SaaS. Technical buyers immediately map it to "workflow tool" or "integration platform." Several personas asked about API access and Zapier compatibility. One CMO said "that sounds like an IT purchase, not a marketing purchase."

Lesson: Words carry professional associations that override your intended meaning. Test job title words carefully. "Engineer" skews technical. "Manager" skews middle-management. "Studio" skews creative agency. If your buyer persona is a Head of Marketing, make sure your label sounds like something a Head of Marketing would buy.

3. The Security Section Was More Powerful Than Expected

Adding a dedicated security section ("Your data is yours. Full stop.") with 4 specific cards dropped the privacy objection rate from 35% to 25% in a single round. We expected some improvement, we didn't expect it to be that direct.

The insight: people aren't afraid of privacy in the abstract. They're afraid because nobody told them the specifics. "We take security seriously" is a red flag. "You choose which channels it can read, your data is never used to train other companies' models, and you can delete everything within 24 hours" is a contract.

Lesson: If privacy is a likely objection for your product, treat it like a feature. Give it its own section, its own headline, and specific mechanics. Not reassurances.

4. The Testimonials Had to Be Engineered, Not Generic

Generic testimonials ("This tool is amazing! Our content quality improved so much!") do almost nothing for conversion. The v5 testimonials were written to directly address the specific objection that 60% of personas raised: "will it actually sound like my team?"

Each testimonial was structured around a skeptic arc: I didn't believe it, here's what happened, here's the proof. The CEO who sent the draft to his co-founder without revealing it was AI-generated. Got a compliment, does more work than ten generic "great product" quotes.

Lesson: Write testimonials to the objection, not to the product. The best testimonial is the one that handles the thing preventing the reader from clicking.

5. The Page Hit a Copy Ceiling at 6.65

The judge rated v5 "Nearly There. Not yet ready to ship without further refinement." The remaining voice authenticity skepticism (~70% still raised it when asked directly) cannot be addressed by copy. The only fix is product experience: letting someone see it work on their actual Slack messages.

This is not a failure of the process, it's the process doing its job. The simulation correctly identified where copy ends and product begins. The recommendation for a v6 is an interactive demo widget or a "try it on your own Slack message" element, which is a product decision, not a copywriting decision.

Lesson: Simulation rounds eventually reveal the conversion ceiling for static copy. When the judge's top recommendation is something the page physically cannot do (let users experience the product), the page is ready to ship and the product team takes over.

Final Deliverables

Production Files

Screenshots

Simulation Data

By the Numbers

Implementation Playbook

How to apply this process to any landing page, or any copy that needs to convert.

Step 1: Extract and Baseline Before Touching Anything

Strip the page to plain text and run a simulation before making any changes. The v1 baseline is the most important data point in the whole process, everything after is measured against it. Don't skip this step even if you're confident the page has problems. You need to know which problems are real and which ones just feel bad.

Step 2: Run a Framing Experiment Before Rewriting

If you don't know which copy direction to pursue, don't guess, test 3-4 variants simultaneously with the same persona panel. It's cheaper than rewriting and guessing wrong. The variants should differ on the thing you're most uncertain about: the product label, the headline, the CTA framing, the stage (beta vs early access vs waitlist).

Run all variants on the same day with the same 20 personas. The relative ranking matters more than the absolute scores.

Step 3: Subtract Before You Add

The biggest jump in this project came from removing three things (scary Slack line, "ghostwriter" label, "beta" framing). Not from adding sections. When simulations reveal problems, ask whether the problem is caused by something present on the page before reaching for something new to add.

Lines that actively hurt conversion are more costly than missing sections. Fix the active harm first.

Step 4: Address Mechanisms, Not Feelings

"We take your privacy seriously" does nothing. "You choose which channels it can read, and your data is deleted within 24 hours of disconnecting" does something. When an objection persists across 35% of personas, it means they don't have the specific information they need. Not that they haven't been reassured enough. Give them the mechanism.

Step 5: Engineer Testimonials to the Objection

Find your most common objection (from simulation or from sales calls). Write the testimonial that directly addresses it. The structure that works: I was the skeptic, here is the specific moment it changed my mind, here is the specific outcome. Vague enthusiasm is decoration. Specific conversion stories are evidence.

Step 6: Know When the Page Is Done

When the judge's single highest-leverage recommendation is something a static page cannot do (interactive demo, trial experience, live proof), the page has reached its copy ceiling. Ship it. Hand the remaining conversion problem to the product team. The page's job is to get the right people to the CTA, the product's job is to confirm what the page promised.

Appendix: Test Data & Artifacts

Simulation Round Summary

Framing Variant Detail

Per-Persona v5 Intent Scores

Infrastructure Used

Copy Changes Log

View the Pages

The actual landing pages built from this work, open each one to see the result.

Related Work

The simulation infrastructure behind this project ran on a local LLM farm built and benchmarked in parallel.