docs/project-elevator-pitch.md holds an unformatted draft of your team’s internal project summary that runs 12 paragraphs long.
Structure of this pitch document
Right now, the file is packed with granular details that matter for internal alignment: technical specs for your latest API update, bug fix logs from the last three sprints, unedited feedback snippets from 17 beta testers, and notes from three stakeholder check-ins. None of that content works for the 30-second spoken pitch you’re expected to deliver at next week’s open source demo day, where judges and audience members only have bandwidth for high-level, easy to follow context. The demo day organizers shared a required structure for the spoken pitch that maps exactly to five targeted sentences, each answering a specific question attendees will have within the first 10 seconds of hearing about your project. The first sentence covers who the project is built for, the second covers the core job it does for those users, the third covers how it delivers that job better than existing alternatives, the fourth covers a clear scope limit to avoid overpromising, and the fifth covers your team’s next immediate milestone. This structure cuts out all unnecessary fluff, ensures you hit every key point within the allotted time, and leaves room for attendees to ask follow-up questions about the details that matter most to them.
Edit the full draft down to the required five spoken sentences
You work through the draft to pull only the relevant details for each sentence, following a simple process to avoid missing key context:
- Pull every line that references end user identity from the draft, group them into a single sentence that clearly states who the project is built for, excluding internal team or stakeholder references that don’t matter to external audiences.
- Consolidate all references to core functionality into one plain-language sentence that describes the job the tool does for those users, skipping technical jargon like container orchestration or edge caching that most demo day attendees won’t recognize.
- Compile comparative feedback from your last user survey into one sentence that explains how this project solves the user’s problem more effectively than free or paid alternatives, focusing on tangible user outcomes rather than internal process wins.
- Pull the documented scope guardrails from your team’s public roadmap to write one sentence that states a clear limit of what the project will never support, to set expectations and avoid misalignment with potential contributors who might want to add out-of-scope features.
- Cross-reference your team’s current sprint goals to write one sentence that states the next actionable milestone for the project, with a concrete timeline for delivery.
You don’t overcomplicate the wording, since this is a spoken pitch, not a formal press release: short, simple words work better than complex phrasing that’s hard to say out loud without stumbling. Illustrative example: If your project is a free inventory tracking tool for handmade craft sellers, your five sentences might read: “This tool is built for independent handmade craft sellers who run small online stores without dedicated operations staff. It cuts down the time spent tracking raw material stock and customer order fulfillment by automating manual spreadsheet entry. Unlike paid inventory tools that charge per monthly order volume, it supports unlimited order tracking for no cost, so sellers keep 100% of their revenue. It will never add e-commerce store hosting functionality, so it stays lightweight and integrates with every existing store platform. We will roll out the new bulk order import feature to our 14,000 current active users in the next 21 days.” If you want to align this pitch with the audience targeting frameworks shared in Build Next Stack’s startup demo playbook, you can tweak the wording to lead with the most pressing user pain point before naming the user group, but the core five-sentence structure stays the same. You paste the final five sentences into the markdown file, deleting the long draft, and add a single line below linking to the full internal project summary in your team’s shared drive for anyone who asks for deeper technical context.
Next time you open this markdown file
When you open this file next, you are 90 seconds away from walking on stage for your demo day pitch, and you pull it up on your mobile device for a quick refresh to calm last-minute nerves. The five sentences load immediately as the first content in the file, so you don’t have to hunt for the core pitch right before you present. You also saved a copy of this file to your team’s shared folder, so your co-presenter can access it if they need to step in to lead the pitch last minute due to an unexpected conflict. After the demo day, you update the file as needed to reflect your team’s progress: you swap out the milestone sentence every time you hit a major sprint goal, you adjust the value proposition sentence if user feedback reveals a new, more compelling benefit, and you add a section of common follow-up question answers below the core five sentences for quick reference during outreach calls. This file becomes your go-to reference any time you need to explain your project quickly: for cold outreach to potential open source contributors, for intro calls with investors who focus on open source tooling, for community onboarding sessions for new users, and for conference talk abstract submissions where you only have a few lines to describe your work. You also link the file to your project’s public GitHub README, so any new visitor to your repository can immediately understand what the project does, who it’s for, and where it’s going, without sifting through hundreds of lines of technical documentation first. You never add extra content above the five core sentences, so the file stays useful for quick reference no matter how much extra context you add to the bottom over time.
