Class 15: October 6, 2026 · ENTR 5000

Notes from October 6, 2026. These notes record the discussion and instructions given that day. For current requirements and due dates, use the assignment guidelines and semester schedule.

ENTR Announcements slides

Today’s focus

Most of class was individual project coaching, followed by preparation for the second sprint presentations. Across the conversations, the recurring question was: What is the next useful thing you can put in front of someone, and what will you learn from it?

Sprint 2 presentations: Tuesday, October 13

The time limit is a hard 3½ minutes. Have your presentation materials ready by 1 p.m. Class begins at 1:15. Watch Slack for the presentation order and the pinned thread for materials.

Use four parts:

1. Elevator pitch — about 30–40 seconds. Who is this for, what does it help them do, and why does that matter? Lead with the benefit.
2. Entrepreneurship progress. Explain the two or three most important questions or blockers you worked on, what you did, and the results. Customer conversations, competitor research, distribution, and business-model decisions all count when they advance the project.
3. AI / development progress. Show the two or three most important things you built, solved, or learned. Connect technical work to what the product can now do.
4. Next priorities. Identify one or two priorities in each domain: entrepreneurship and AI/development.

You do not need to recount every change or demonstrate every feature. Choose what helps us understand the progress and your next decisions. No exact slide count was assigned; a deck or another workable presentation format is fine.

Practice with a timer. The recommendation was at least three runs, aiming for two clean runs under the limit. An example allocation—30 seconds for the pitch, a minute for each progress section, and 45 seconds for priorities—uses 3:15 and leaves a little room. Adjust the balance to fit your work.

John plans to put written feedback in your project channels during the presentations. Peer feedback is encouraged too.

Describe the benefit, then show evidence

A feature describes what a product does. A benefit explains why the intended user cares. “Hundreds of resources” describes an inventory; “helps a busy developer choose relevant tools without spending hours keeping up” gives a reason to use it.

That distinction should shape both your pitch and your next build. A large library or elaborate interface may be useful behind the scenes, while the first customer experience is one relevant suggestion or one completed task.

A useful test can happen before a broad launch. Choose a small experience that already delivers value, put it in someone’s hands, and decide what you want to learn. A specific appointment or commitment can keep “I’ll test when it’s ready” from moving indefinitely.

Customer discovery and product testing overlap, but ask different questions. Discovery explores people’s problems, current alternatives, and willingness to change. Product testing observes what happens when they use what you made. Before designing a detailed test, list reachable people or groups and the uncertainties you want them to help resolve.

Potential partners can also be a route to customers. Someone who repeatedly advises your intended users may help you understand common needs and reach a first audience. Their perspective is useful evidence; it does not replace hearing from the users themselves.

Build, review, and choose the next priority

Several coaching conversations returned to practical development habits:

• Review at milestones. After connecting a major component, ask for a code review covering bugs, missing pieces, and unnecessary complexity. Inspect the findings and proposed changes.
• Keep the work’s context together. A coding workspace can hold the conversation alongside the files the assistant needs. Separate chats can be useful, but make sure decisions and changes return to the working project.
• Save working versions. Commit meaningful milestones so an experiment that breaks something does not erase your last usable version.
• Give independent work a clear boundary. Prepare a specific task the assistant can advance, specify what success means, and review the result. More activity is not automatically more progress.
• Consider the cost of workarounds. Repeatedly migrating between free hosting plans can cost more time than resolving one deployment path. No particular paid service or subscription was required.
• Keep later ideas in a backlog. A future integration may be valuable without being the most useful thing to build before the first round of user feedback.

Be precise about what you have demonstrated

A working demo, a passing test, and evidence of customer value are different achievements. Name the one you actually have.

A system that advises someone to stop an action is different from a system authorized to stop it. Results on a small set of test examples do not establish performance on new situations. Likewise, a polished explanation or visualization does not by itself validate the underlying output.

For products handling uploaded information, understand the full path: storage, analysis providers, logs, and retention. Verify the actual arrangement before making claims. This is part of learning what your product does, not simply writing reassuring copy.

You are not required to prove that every project will become a profitable company. A useful outcome can be learning a capability, discovering a limitation, or finding a better application. The presentation should make that learning visible.

Thursday workday and course resources

Thursday, October 8 is an independent workday, with no regular classroom meeting. Work wherever is useful and devote about a class period to the project. Each student should post an update in their project channel sometime Thursday and @mention John: what you worked on and any questions or blockers. John plans to review these Friday or by lunchtime Monday, October 12.

The new course site is an early version bringing together course information, the syllabus, and summaries. Feedback on organization, missing material, or confusing interactions is especially useful. Slack remains the place for course communication; grades are in eLC.

The site uses Markdown content and Astro, the web framework mentioned in class. Additional integrations discussed are future plans, not available course features yet.

Optional resource mentioned during coaching: Paul Ford’s What Is Code? (2015). It is not a new required reading. The Tuesday announcements deck is linked above; no additional event deadline is inferred from it.