Product, engineering and leadership courses

These courses open after the prerequisites shown in Academy. Start with one topic, learn a small explanation, explain it in your own words, and answer a fresh scenario question. AI corrects gaps and saves a brief summary of demonstrated understanding. Practical exercises are optional. Never use real customer details, credentials or private company information as examples.

Product foundations

Understand the people behind a trip

A group leader coordinates the trip; a traveller needs to understand their own day. They may need different information at different times. NepWalk's itinerary is the baseline for this experience. Before suggesting a feature, name the person, the situation and the outcome they need. Read the current product vision and approved task for context; learning is not permission to expand the product.

Example: a group leader preparing tomorrow's departure needs an understandable meeting time and place. A decorative badge does not solve that problem.

Teach-back: explain one difference between a leader's and traveller's needs. Scenario: everyone can see the itinerary, but the leader still receives repeated questions about departure. What would you investigate before proposing a feature? Optional practice: write one fictional user situation and desired outcome.

Turn a user problem into acceptance checks

Separate the problem from the proposed solution. Describe who is affected, what happens now and the observable improvement. Acceptance checks describe behaviour a reviewer can verify, including an important failure or empty state.

Example: “Make the page nicer” is ambiguous. “On a narrow phone, the trip title and departure time remain readable without horizontal scrolling” can be checked.

Teach-back: distinguish an outcome, an implementation suggestion and a check. Scenario: a task says “make sharing easier.” What must be clarified before work? Optional practice: rewrite one vague request into two acceptance checks.

Prioritise with evidence and limits

A reported idea is a possibility, not an assignment. Compare the affected user, severity, evidence, effort and the current approved goal. State uncertainty. The founder assigns priorities; team members report findings and explain impact. A useful small change can matter more than an exciting unrelated feature.

Example: an inaccessible departure time can block a journey; a colour preference may be less urgent. Explain impact rather than declaring every report P0.

Teach-back: explain what makes a report urgent and what evidence is missing. Scenario: one person asks for a feature while several users cannot complete the current flow. What information would you bring to the founder? Optional practice: compare two fictional reports without inventing statistics.

Engineering essentials

Trace a change through frontend, backend and data

Start with the user action. Find its UI entry point, request, validation, business rule, stored data and displayed response. Inspect the actual sibling repositories and their instructions instead of assuming a framework convention. Make the smallest change at the layer that owns the rule.

Example: a disabled button can guide the user, but an ownership rule also needs enforcement where a write is accepted. Hiding the button alone cannot enforce it.

Teach-back: trace one fictional change and identify which layer owns its rule. Scenario: a user can bypass a disabled control with a direct request. Where should the rule be enforced, and what evidence would verify it? Optional practice: ask AI to locate an existing flow without editing files.

Design loading, empty, error and keyboard states

A UI includes more than its successful screenshot. A person should understand whether information is loading, absent, invalid or saved, and what to do next. Use existing components and visual tokens. Keep text readable on a phone, provide labels, and make actions reachable with a keyboard. Never use colour alone for status.

Example: an empty task list can explain who assigns work and where to learn next, rather than leaving a blank panel or inventing tasks.

Teach-back: describe the important states of one small interaction. Scenario: a save fails while a form contains a long description. What should remain available, and how can the user recover? Optional practice: inspect a current screen by resizing it and using Tab.

Keep validation and ownership at trusted boundaries

Treat browser input and AI output as untrusted. Check shape, allowed values, relationships and the acting person's access before accepting a change. Read the repository security rules. A hidden tab or local identity guard is not secure server authentication. Do not put secrets or private data into shared examples.

Example: changing a task ID must not allow someone to work as another member. A meaningful test checks the denied operation and verifies records stay unchanged.

Teach-back: distinguish validation, authentication and authorisation. Scenario: AI generates a plausible member ID in a payload. What needs checking before that payload can change records? Optional practice: explain one applicable security rule with fictional data.

Reliable delivery

Choose tests that can catch the actual regression

Reproduce the behaviour, identify the rule and write a check that would fail if the rule were broken. Test outcomes, not a duplicate of the implementation. Include a relevant edge or denied action. Automated checks and a person's manual test provide different evidence; neither should be claimed without running it.

Example: checking that a Start button exists does not prove that only the assignee can start a task. Also test a different actor and unchanged records.

Teach-back: explain what one regression test proves and what it does not. Scenario: all tests pass, but removing an ownership check also leaves them passing. What is missing? Optional practice: design a regression test before writing any code.

Hand over a change someone else can verify

Inspect the diff, run the relevant checks and state exactly what was verified. Include a short manual journey with expected results, known limits and the next reviewer. Preserve unrelated work. Follow repository rules for commits, branches, pushes and reviews; never treat a successful build as production acceptance.

Example: “Open Work, switch to Inbox, then open the linked task; your identity must remain unchanged” gives a reviewer an observable journey.

Teach-back: distinguish implementation, automated proof, manual test and acceptance. Scenario: a build passes but the reviewer cannot reproduce the expected flow. What evidence and instructions should the handoff include? Optional practice: write a handoff for a fictional one-screen change.

Quality and UX

Explore a user journey with a test charter

A charter names the person, goal, area to explore and important risks. Try ordinary, empty and interrupted journeys. Record observations separately from explanations. Reproduction steps, environment and expected versus actual results make findings useful. Exploration discovers questions; it does not silently expand scope.

Example: explore whether a traveller can understand tomorrow's departure on a phone, including a long title and missing optional information.

Teach-back: explain a charter and what evidence belongs in a finding. Scenario: a problem appears once and disappears after refresh. How would you record it without claiming a proven cause? Optional practice: draft a fifteen-minute charter; running it is optional.

Review accessibility beyond the screenshot

Check whether controls have understandable labels, keyboard access and visible focus. Read content at a narrow width and with larger text. Check how status, errors and next steps are communicated. Screenshots show appearance, not the complete interaction or assistive-technology experience.

Example: a green icon with no text can leave a person unsure whether work is saved, accepted or still waiting. A clear label makes that distinction visible.

Teach-back: explain three checks a visual screenshot cannot establish. Scenario: a dialog looks correct but Tab moves into the page behind it. What would you report and which expected behaviour needs verification? Optional practice: review one interaction with only a keyboard.

Write actionable reports and weigh UX tradeoffs

A useful report contains a concise title, context, reproduction steps, expected behaviour, actual behaviour and relevant evidence. Crop private information from screenshots. Separate a confirmed bug from a suggestion or hypothesis. Describe the user impact and let the founder decide priority and assignment.

Example: “Text overlaps the Start control at 390px width” is more actionable than “bad UI.” A preferred redesign can remain a suggestion in the same report.

Teach-back: explain how a bug, idea and assigned task differ. Scenario: a redesign would reduce clicks but hide important status information. What would you compare before recommending it? Optional practice: rewrite a vague fictional complaint into a report.

Team leadership

Plan outcomes and small reviewable work

Name the desired outcome, who owns the next action and how completion will be observed. Split large work into reviewable steps. Identify dependencies and ask for decisions before they block delivery. The founder assigns tasks; the manager can propose a clearer breakdown and provide testing or UX evidence.

Example: “Test the trip flow” can become a bounded journey with a device, entry point, expected outcome and a short evidence handoff.

Teach-back: explain the difference between activity and an achieved outcome. Scenario: someone has worked for two days but the reviewer cannot tell what is ready. What would you clarify without blaming the person? Optional practice: outline a small reviewable quality task.

Give specific feedback and communicate blockers

Describe an observed behaviour, its effect and a useful next action. Ask for the other person's explanation. Avoid labels about ability or effort. A blocker handoff states what was attempted, what is missing, who can decide and what can continue safely. Praise specific verified contributions, including learning.

Example: “The report lacks steps to reproduce; please add the entry point and expected result” gives a clearer next step than “be more careful.”

Teach-back: turn a judgement into an observation and a request. Scenario: a teammate repeatedly hands over work without manual evidence. How would you discuss it while keeping the required quality step intact? Optional practice: draft one constructive fictional feedback exchange.

Improve flow without measuring people by busyness

Look for where work waits, where requirements are unclear and where the same rework repeats. Use recorded evidence and ask the team what slowed them down. Propose one small improvement, observe its effect, and review it. Hours, commits and XP alone do not establish quality or a person's value.

Example: several tasks waiting for a decision may indicate a review bottleneck. Demanding more coding time does not resolve that wait.

Teach-back: distinguish a process bottleneck from an unsupported judgement. Scenario: the team logs more hours but accepted outcomes fall. What questions and evidence would help you understand the situation? Optional practice: suggest one measurable process experiment without quotas.