Explain Your Project in Five Spoken Sentences

explain-your-project-in-five-spoken-sentences

Explain Your Project in Five Spoken Sentences. A Build Next Stack field guide for learners shipping small projects.

Record before you polish slides

Written READMEs hide fuzzy thinking behind headings. Spoken sentences expose gaps in ten seconds—you stall, you hedge, you say kind of. Record voice memo before you polish slides or portfolio copy. Phone voice memo app is enough; do not wait for a microphone.

Listen once without editing. Count sentences—if you hit twelve, scope is undefined. Five sentences force prioritization. Recording weekly on the same project tracks clarity progress better than redesigning the logo.

Transcribe only after listening. Editing while transcribing hides ums and hides fuzzy thinking. Maya’s first recording was eighty seconds for five sentences; week four was forty-two seconds with clearer risk language.

She also records standing up for sentence one only—physical shift signals brain that pain language should be plain, not slide-deck formal.

Sentence one names the user pain

First sentence names who hurts and how, without stack vocabulary:

Freelancers forget which client invoices are overdue because totals live in three apps.

If sentence one mentions React, PostgreSQL, or AI, rewrite for humans. Stack belongs later. Pain first proves you are building something, not assembling tutorials.

Pain should be observable—someone could verify it in an interview or support ticket, not a vibe.

Practice sentence one on a non-technical friend. If they nod without asking what is an invoice overdue, pain is concrete enough for sentence two.

Sentences two and three cover stack choices

Sentence two states what you built to address the pain. Sentence three states one tradeoff you accepted:

I built a single dashboard that imports CSV exports nightly. / I chose a static front end with serverless functions so I can deploy without managing a box.

Tradeoffs show judgment. I used the best tools is not a tradeoff. I skipped real-time sync to ship in two weeks is.

Keep stack names accurate but sparse—one sentence can hold two technologies, not six.

Maya dropped sentence three to a single hosting choice—serverless functions—because naming five services made her realize she could not explain why each existed.

Sentence four states what ships this month

Fourth sentence is a time-bound deliverable:

By August I am shipping email reminders when an invoice crosses thirty days overdue.

Monthly shipping language prevents eternal beta syndrome. If sentence four sounds impossible, sentence one pain may be too big—narrow the user or the overdue definition.

Shipped means someone else could use it awkwardly, not that you declare perfection.

Monthly shipping language also helps friends hold you accountable without nagging—they can ask did sentence four ship? instead of how is the project?

Sentence five admits the open risk

Fifth sentence names what still might fail without doom language:

If CSV formats differ by bank, import will break until I add a mapping step.

Risks you can name are risks you can schedule. Hidden risks become weekend surprises. Open risk is not impostor confession—it is engineering honesty.

Avoid fake risks—users might not like colors—that dodge technical unknowns.

Sentence five is where impostor voice appears—maybe nobody needs this. Replace with technical risk you can test: if CSV columns vary by bank, import fails until mapping UI ships.

Listen for filler words as scope signals

On playback, tally basically, just, kind of, maybe. Each often marks undefined scope:

  • Basically syncs everything → define one sync path
  • Maybe mobile later → decide mobile in or out for this month
  • Kind of automated → name the trigger and schedule

Re-record after fixing scope, not after adding jargon. Second recording should be shorter, not longer.

Share the memo with one trusted listener—a friend, a mentor, a forum post asking for clarity feedback. Questions they ask belong in README FAQ, not defensively in sentence five.

When listeners ask who exactly? narrow sentence one. When they ask how is this different from a spreadsheet? sharpen sentence three tradeoff. Listener confusion maps directly to README edits.

Record outdoors or walking for sentence five only—risk language loosens when you are not staring at the IDE that produced the bug you are afraid to mention.

Compare two recordings side by side

Keep last week’s memo and this week’s. Listen alternating sentences—pain in week one versus pain in week two. Did the user get sharper or did you add buzzwords? Sharper user means learning; buzzwords mean anxiety.

Maya noticed sentence four kept slipping to someday notifications until she tied it to a calendar date. Spoken deadlines expose weasel words slides hide.

Store memos in a folder voice-log/ with date stamps. Do not polish them for public release. The archive is for your ear training, not a podcast.

If sentence count exceeds five, delete the weakest sentence entirely rather than merging two into one run-on. Clarity loves deletion.

Maya keeps a text file five-sentences.md with the latest transcript only—no history pile. History lives in voice-log folder; working copy stays one screen for quick edits before README updates.

Weekly recordings also reveal scope creep: if sentence four keeps moving without shipping, shrink the deliverable until sentence four and git history agree.

Record five sentences tonight

Open voice memo, say five sentences using the template, stop. Transcribe roughly if you want text; do not edit while transcribing. Fix sentence one if stack appeared too early. Schedule a re-record after your next shipped feature changes sentence four.

Clarity is a learnable loop: speak, listen, tighten, ship. Five sentences beat fifty-slide architecture diagrams for solo builders who need to know what they are making.

Delete the longest sentence from your first attempt if you exceed five. What you cut is usually stack bragging or duplicate pain description.

After three weekly recordings, paste sentence one into your README intro if it still fits without edits—that alignment means marketing and reality match.

Spoken practice also surfaces features you cannot describe—if sentence two stalls, the feature may not exist yet; build before polishing pitch.

Save recordings even when embarrassing—compare week one to week four side by side and you will hear tighter pain and risk language without reading a single productivity book.