Skip to content
ENTR

Class 14: October 1, 2026 · ENTR 5000

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

Use the sprint to learn from something real

Today was a workday: individual check-ins, conversations with classmates, and progress on the goals you identified for Sprint 2. Across the conversations, the recurring question was: what can you put in front of someone, try, or observe now that will help you decide what to do next?

Sprint 2 presentations and the sprint deadline move to Tuesday, October 13. We will meet normally Tuesday, October 6, and discuss revised presentation guidance. Thursday, October 8, is an independent workday with no regular class meeting.

Test the underlying work before polishing the interface

A useful test often does not require a finished app. Before building a voice assistant, for example, check whether its knowledge and proposed responses are right. Organize the material by topic, then ask people who handle the work to identify missing situations, incorrect assumptions, and better ways to respond.

This separates two questions: does the content solve the right problem, and does the technology deliver it well? Testing both at once can make it harder to understand what needs fixing.

Including the people affected by a product also supports adoption. They can shape the design and understand why it is being introduced, rather than discovering a finished system they had no part in creating.

Customer conversations and competitor research belong together

Look specifically for products that already address the problem you are trying to solve. Find out what they do well, where they fall short, and whether customers actually use them. Existing competitors are information; their presence alone is not a reason to abandon an idea.

Use that context when talking with potential users:

  • What do they use now?
  • What works, and what remains frustrating?
  • What have they considered and decided against? Why?
  • What would make a new approach worth trying?

Start with open questions before showing your proposed features or service tiers. Otherwise, you may learn only how people react to your list. Once you understand their current work, specific options can help you explore priorities and pricing.

Make a reachable list and start contacting people. If your potential users work in public-facing local offices, a brief in-person introduction can sometimes get you further than another round of planning. Research can help you find the right person; the conversation supplies evidence the research cannot.

Make the prototype small enough to try

Ask what a smaller, faster, cheaper, or lower-risk version of the test would look like. A sourcing business could begin with one modest item before taking responsibility for a large, time-sensitive order. A software project can test a working build on a real device before pursuing store distribution. A measurement tool can begin with a short recording before processing a full day.

The point is to preserve the important uncertainty while reducing what you must commit to learn about it. A small test should still tell you something meaningful.

For an app built with Expo, a development build offers a route to testing on a physical device. The setup depends on the platform and build method; use the Expo development-build documentation for the actual steps.

Make automated results inspectable

A number produced by a model or script is a claim to check. For video-based counting, the suggested approach was to retain the start and end frames for each detected event, so a person can inspect what the system counted. Begin with a short test, review the evidence, and then increase the duration.

As a useful verification step, compare some manually reviewed footage with the automated results, including things the system missed. A detected interaction is not automatically proof that someone noticed or remembered an advertisement; define what you are measuring before calling the result an impression.

The broader principle applies to other projects too: design the output so you can see why the system reached its result and whether that result is useful.

Move from ideas to organized work

Capture ideas as they occur, then turn them into issues with enough detail to act on. Ask an assistant to help clarify undefined issues and divide a larger plan into manageable pieces. Review the plan before building.

For a product that generates structured material, identify its component parts and rules instead of treating everything as one block of text. Preferences, phases, timing, and reusable units can become explicit parts of the design. Competitor research can then reveal useful capabilities you have not considered.

Keep using issues and pull requests to connect the proposed work with the changes you make. The earlier GitHub-to-Slack setup handout remains available as a reference.

Early sales can be a direct conversation

For an early service business, a few relevant relationships may be more useful than broad advertising. Identify people who already advise or serve your potential customers and make a short, concrete introduction:

  • Who you are and why you are a credible person to contact.
  • What you offer and what makes it useful.
  • A clear request, such as a brief conversation or inclusion in a referral list.
  • Something valuable for their audience, when you can genuinely provide it.

Keep the message short, use a clear subject line, and plan the follow-up. AI can help find public professional contacts, draft options, and organize the work; review the details and send a message that sounds like you. A useful relationship takes more than a polished email.

Trust and incentives are part of the product

If you promise lower prices, customers may wonder what is being sacrificed: quality, reliability, delivery time, or support. Decide how you will make those tradeoffs visible and establish a record people can check.

Also ask who benefits financially from each choice. A fee calculated as a percentage of spending can create different incentives from a fee tied to savings. Understanding those incentives helps you identify the right customer and explain the value of your offer.

Quince was discussed as a comparison for communicating value in another market; AmericasMart was a reference for bringing buyers, suppliers, and physical products together. These are examples to examine, not proof that a new business model will work.

A venture can aim for measurable impact

Revenue is not the only possible outcome. A project can help more people take useful action or support an existing effort. Define the change you want to produce—such as participation, volunteer hours, or resources raised—and work backward to an achievable next experiment. The goal is evidence of an effect, rather than only a collection of information about a problem.

Between now and Tuesday

Continue the specific next steps from your check-in. Depending on your project, that may mean interviewing users, reviewing competitors, testing a prototype, defining service tiers, or making an initial sales approach. These were individualized plans, not a new identical checklist for everyone.

If we did not get to your project today, you are first in line for Tuesday. For a blocker that cannot wait, DM John in Slack or @mention him in your project channel. No new quiz or separate class-wide written homework was announced.

Optional resource mentioned: The AI Doc: Or How I Became an Apocaloptimist. It was a recommendation during conversation, not assigned viewing.