Class 17: October 13, 2026 · ENTR 5000
Notes from October 13, 2026. These notes record the discussion and instructions given that day. For current requirements and due dates, use the assignment guidelines and semester schedule.
Sprint 2: progress you can show and decisions you can explain
Today’s presentations showed working prototypes, customer conversations, sharper target audiences, and changes in direction based on what teams learned. The most useful reports connected a question, an action, evidence, and a next decision. These notes collect lessons from the discussion; individual project feedback stays in project channels.
Lead with the benefit
A listener arriving cold should quickly understand who the product helps, what problem it addresses, and why the result matters. Explain that before the project’s history, technical architecture, or list of features.
A pivot can make the story clearer: “We learned that this audience needs X, so we are now helping them do Y.” Keep enough of the story to explain the decision, then show what changed. Pitch practice will be part of the next sprint now that the projects have more substance to communicate.
Let discovery change the product
Direct conversations and real-world tests were especially valuable. They sometimes revealed a problem different from the one the initial product was designed to solve. Keep listening for the underlying need instead of trying to steer every response back toward the original feature.
Existing competitors can be evidence that people already pay to solve a problem. They also make it necessary to explain why a particular audience would choose your approach. Finding few competitors does not establish willingness to pay; that still needs a test.
Several practical strategies came up:
- Start with reachable people. Local professionals and organizations may provide better early conversations than paid advertising. An intermediary who repeatedly serves your intended customers can help you understand the workflow and reach a first audience.
- Plan both sides of a marketplace. Buyers need sellers, and sellers need buyers. A narrow use case and advance commitments can help create the first useful exchange.
- Separate encouragement from evidence. Positive reactions from friends are encouraging; watching someone use the product, trying a proposed price, or getting a concrete commitment answers different questions.
- Reduce friction around an existing solution. A useful venture may help people discover and use resources that already exist. Choose a specific outcome to measure instead of stopping at awareness or a large collection of information.
Make the next test small enough to run
A failed prototype can still produce useful information. If an automated detector misses what you can see in the recording, compare the output with a manual check and investigate the setup. Camera angle, distance, field of view, and lighting can affect the result before the model gets a fair chance.
For a video-analysis feature, the suggested sequence was: Can it identify one simple action? Can it give useful, accurate detail? Can you make that process economical? A short, controlled clip is enough to start answering the first question. You do not need a full production system before running that experiment.
Test complete behavior, too. Saving data is more meaningful when it survives closing and reopening the product. An integration that works on the developer’s own computer still needs testing on someone else’s setup. A more impressive-looking output is not necessarily a more accurate model.
For an Apple app, TestFlight provides a way to distribute a beta and collect feedback before a public App Store release. External testing may require beta review. This was a suggested path for relevant projects, not a requirement for everyone.
Trust and delivery are part of the product
The discussion highlighted value in combining automation with trusted expertise, useful data, and access to customers. A faster report does not remove the need for someone to understand, verify, and stand behind it.
Practical development lessons included making failures visible, asking an agent to diagnose a problem before changing the implementation, and keeping private client files out of the code repository. Accuracy, appropriate data access, and what the product promises users all belong in the development plan.
Technical progress and customer discovery can move together. Keep improving the prototype while finding out what people will use or pay for. When one path is blocked—for example, by unavailable data—consider whether the same capability could serve a more accessible problem.
Before Thursday, October 15
No new homework submission was assigned. Come ready to discuss an ambitious but achievable goal for the approximately six weeks remaining before class meetings end. We’ll begin Sprint 3 and break that larger goal into useful steps. Think of Sprints 3 and 4 as connected parts of that effort.
The short, 3½-minute presentation format will continue. Review the feedback in your project channel; peer feedback there is welcome too. The course home collects current course information.
Two optional events were mentioned:
- Society of Entrepreneurs speaker: Tuesday, October 13, 6 p.m., Studio 225. John recommended speaker Shep Ogden, an entrepreneur from his former program. See the speaker-series information and the announcements deck above.
- AI Society speaker: Wednesday, October 14, 6:30 p.m., Correll Hall 0214. A KPMG AI developer is visiting; details were shared in the class Slack channel.