Starter Duo.

1. Start with a customer, not a storefront
2. Shape an offer and understand the numbers
3. Build a product page that answers questions
4. Run a small launch and learn from it

An online store is a way to present an offer, accept an order and help someone receive what they expected. It is not evidence that anyone needs the product. Before choosing a name or arranging a homepage, describe one customer in one situation. A useful starting sentence is: When this situation happens, this person wants to complete this task, but this obstacle gets in the way. The situation makes your idea specific enough to investigate. Separate the problem from your proposed solution. Someone who struggles to carry lunch and work equipment might want a better bag, a smaller lunch box or a different routine. If every interview question mentions your preferred product, you may miss the real need. Ask about the last time the problem occurred, what the person did, what they tried before and what made the alternative inconvenient. Past behaviour gives you more concrete material than a polite prediction about future purchases. Fictional worked example: Maya is exploring Desktrail, an imagined shop for compact work accessories. Her first idea is a cable pouch for people moving between home and shared desks. Her problem statement says that these workers want to set up quickly, but loose chargers and adapters are difficult to find. In an invented practice interview, a worker describes using an old pencil case. Maya records that description as an observation. She separately records her hypothesis that internal pockets might help. The interview does not establish that the worker would pay for a new pouch. Maya prepares a learning sheet with four columns: observation, interpretation, unanswered question and next check. One observation can support several interpretations. A tangled cable could indicate poor storage, too many cables or an awkward bag. She chooses the cheapest useful check: showing a rough pouch layout and asking the person to arrange their actual items. She does not order stock on the strength of a compliment. Common mistake: describing a customer only as a broad demographic or treating enthusiasm as confirmed demand. A specific situation is more useful than an impressive audience size. A few conversations can reveal questions worth testing, but they do not represent everyone. Useful next step: write one problem statement and arrange a small set of voluntary conversations with relevant people. Explain the purpose, avoid collecting unnecessary personal details and keep exact observations separate from your conclusions. Finish by naming the assumption that could most change your decision to continue.

1. Choose the right task for an assistant
2. Give context, constraints and an output shape
3. Summarise without losing important details
4. Build a repeatable review workflow

Your goal is to choose work where assistance is useful and mistakes can be caught. ChatGPT can help organise supplied notes, develop a first draft or offer alternative explanations. A fluent response is still something to review. It can omit a condition, invent a detail or misunderstand your purpose. Start with a small task whose quality you can judge yourself, rather than asking an unfamiliar tool to make a consequential decision. Use three questions to assess a task. Is the input suitable to share? What would an acceptable result contain? Can I verify that result before anybody relies on it? If one answer is unclear, narrow the task or do it manually. Editing the wording of a fictional meeting agenda is a useful practice exercise. Deciding whether a real customer has a legal entitlement is not an appropriate beginner shortcut. Separate preparation, transformation and approval. Preparation means choosing the facts and removing information you should not provide. Transformation is the requested activity, such as grouping agenda items by topic. Approval means checking the result against the facts and deciding whether to use it. The assistant does not take responsibility for the final message simply because it drafted the wording. Fictional worked example: Maya coordinates a community workshop. Her notes say: 12 seats, beginner level, bring a notebook, room opens at 17:45, session starts at 18:00. She wants a short reminder. This is manageable because the source is small and the output can be checked line by line. She writes down five acceptance criteria before prompting: correct capacity, correct audience, correct item to bring, both times preserved, and no new promises. If a draft invents free parking, she removes it and checks whether other unsupported details appeared. Keep practice data fictional. For real work, follow your organisation's approved tools and data-handling rules; removing a person's name alone may not remove identifying details. Do not assume that a particular plan or setting makes every upload appropriate. Features and availability can change, so this course teaches a review process rather than a specific subscription or button sequence. A common mistake is choosing an enormous task because generation looks fast. A long document can take longer to verify than to write. Your next step is a task card: source material, desired transformation, acceptance criteria and reviewer. Keep the first experiment short enough to compare with the original in a few minutes.