Product Development Glossary

These are the professional vocabulary words you will encounter during the Product Studio (Weeks 3–10). Each entry gives you just enough to understand what you are looking at. For more depth, use the suggested prompt with any AI assistant.

See also: Tech Glossary for hardware and connectivity terms.

---

Project Planning

Project Brief A short document (2 pages for this module) that answers four questions: What is the problem? Who is affected? What are we building? How will we know if it works? In industry it is sometimes called a PRD (Product Requirements Document) or product spec. Writing it forces your team to agree on the basics before anyone starts building.

💡 Ask AI: “What is a Product Requirements Document (PRD)? What is the difference between a problem statement and a solution description in a product brief?”

Problem Statement A sentence or short paragraph that describes a problem clearly — without mentioning any solution. A good problem statement names who is affected, what situation they are in, and why the current state is not good enough. Writing the problem statement before the solution is a discipline: it prevents you from building a solution looking for a problem.

💡 Ask AI: “Give me 3 examples of a strong problem statement for a mobile app product. What makes each one effective?”

Success Metrics Specific, measurable outcomes that tell you whether your product is working. Not “users will like it” — but “users complete the sign-up in under 60 seconds” or “3 out of 5 users find the main feature without instructions.” Used in your Project Brief and Validation Report.

💡 Ask AI: “What is the difference between a vanity metric and an actionable metric in product development? Give examples of each for a university student app.”

User Persona A fictional but realistic description of your target user — their situation, goals, frustrations, and behaviour. Used to keep the team aligned on who they are building for. Not a demographic: not “18–25 year olds” but “Jun, a third-year engineering student who commutes 45 minutes and tracks expenses manually in WeChat…”

💡 Ask AI: “Write a user persona for a student living in shared accommodation who uses an expense-splitting app. Include their goals, frustrations, and current workaround.”

---

Agile & Sprints

Agile Development A way of working used in almost every software company. Instead of designing everything upfront and then building it all at once (which rarely works), Agile teams work in short cycles — plan a little, build a little, test with users, learn, adjust. The key idea is that you cannot know everything at the start, so you plan for change. You will apply Agile principles through your Development Log, sprint structure, and pathfinder checkpoints.

💡 Ask AI: “Explain Agile development using a non-technical analogy. What problem was it invented to solve? How is it different from traditional ‘waterfall’ planning?”

Sprint A short, focused period of work — usually 1–2 weeks — at the end of which you have something working to show. In each sprint you plan what you will build, build it, and then review what you learned. The word comes from software development but the concept applies to any iterative work. In ENT208TC, each week of the Product Studio is roughly one sprint.

💡 Ask AI: “What happens at the start, during, and end of a sprint in Agile development? What is a sprint review?”

Iteration One cycle of: build something → test it → learn from the test → improve. Iteration is the core habit of professional product development. It is different from simply making changes — it means making changes that are driven by evidence (user testing, data, feedback) rather than opinion.

💡 Ask AI: “What is the difference between iteration and just making changes to a product? Why do product teams iterate rather than trying to design the perfect product from the start?”

Backlog The full list of all features, tasks, and improvements your team is considering — everything that could go into the product. In each sprint, you pick items from the backlog and commit to completing them. Items stay in the backlog until you either build them or decide to cut them. Your Kanban board’s “To Do” column is your active backlog.

---

Prioritisation

MoSCoW A technique for deciding which features to build first. Each feature is labelled as:

• M — Must have: the product cannot work without this
• S — Should have: important, but you could launch without it
• C — Could have: nice if time allows
• W — Won’t have (this time): deliberately cut from this version

The name is an acronym from the first letters (with vowels added to make it pronounceable). Used in Week 4 to set your sprint scope.

💡 Ask AI: “Explain MoSCoW prioritisation with a food delivery app as the example. Categorise 10 possible features into Must / Should / Could / Won’t and explain the reasoning for each.”

MVP (Minimum Viable Product) The simplest version of your product that lets you test your core assumption with real users. Not a broken version — a deliberately minimal version that does the most important thing well. The point of an MVP is to learn quickly: does the core idea work? If yes, build more. If no, change direction before investing more time.

💡 Ask AI: “What is the difference between an MVP and a prototype? Give an example of each for the same product idea.”

Scope Creep What happens when a project keeps growing — new features get added, requirements expand, and the original timeline no longer fits. Almost every team experiences scope creep. MoSCoW and sprint planning are tools to control it. In ENT208TC, tutors recommend freezing scope by Week 6 and finishing what you started rather than adding more.

---

Team Workflow

Kanban Board A visual system for tracking team tasks. Tasks live in columns: To Do → Doing → Done. At a glance, anyone on the team can see what needs doing, who is working on what, and what is finished. Popular tools include GitHub Projects, Gitee Projects, and Trello. You set this up in Week 4.

💡 Ask AI: “Show me how to set up a Kanban board in [Trello / GitHub Projects] for a student software project. What columns should I create, and how should I write task cards?”

User Story A short description of a feature written from the user’s perspective: “As a [type of user], I want [an action], so that [a benefit].” User stories keep the team focused on what the user actually needs, not what is technically interesting to build.

Example: “As a shared household member, I want to add an expense in under 10 seconds, so that I actually do it instead of forgetting.”

💡 Ask AI: “Write 5 user stories for a simple expense-splitting app. Follow the ‘As a… I want… so that…’ format.”

Definition of Done A shared agreement within the team about what “finished” means for a task. Without it, “done” means different things to different people — one person says the feature is done, another says it still needs testing. A typical definition of done for a feature: it works on a real device, it has been tested by at least one person who did not build it, and the code is committed.

Development Log (Dev Log) Your team’s weekly record of progress, decisions, and individual contributions. Maintained from Week 3 to Week 10. Assessed as 20% of your module grade. Contains: what the team accomplished (with names), evidence links (commits, interview notes, Figma files), one key decision per week, and each person’s individual contribution in their own words.

---

User Research & Validation

User Testing Watching real users interact with your product to find out where they succeed, get stuck, or feel confused. Different from asking people what they think — user testing is about observation. You give users a task and observe without helping. The goal is to find the gaps between what you intended and what users actually experience.

Validation The process of checking whether your assumptions about the product — about the problem, the users, the solution, the features — are correct. Validation happens through interviews, concept testing, usability testing, and data analysis. An assumption that has been validated with evidence is much more reliable than one that comes from the team’s opinion.

💡 Ask AI: “In product development, what is the difference between assumption and validated learning? How do teams validate assumptions before building features?”

Usability Testing A specific type of user testing focused on whether users can accomplish tasks with your product. You prepare 2–3 tasks, watch users attempt them, and take notes on where they hesitate, fail, or succeed. Not a demo — you do not explain how it works. The user figures it out (or doesn’t), and you learn from that.

Think-Aloud Protocol A technique used in usability testing: you ask the user to say out loud what they are thinking as they use the product. “Please say whatever comes to mind as you go.” This reveals the user’s mental model — what they expected to happen — which is often different from what the designer assumed.

Iteration History A record of what you changed, why you changed it, and what the change was. Used in your Validation Report to show the connection between user findings and product decisions. Format: [Round of testing] → [Finding] → [Change made] → [Evidence that the change worked].

---

Documentation

Technical Documentation The document (6–9 pages) submitted in Week 11 that describes your product’s architecture, technology choices, deployment process, IP strategy, and known limitations. Its purpose is to enable another developer to understand, maintain, and deploy your product. Assessed as 15% of your module grade.

Validation Report The document (4–6 pages) submitted in Week 11 that records your user research methodology, key findings, and the iteration history of your product. Proves that you followed a scientific approach — evidence-based decisions, not opinion-based. Assessed as 10% of your module grade.

IP Strategy Your analysis of the intellectual property aspects of your product. Includes: what is novel about your solution, whether you should patent it (and why), examples of existing prior art (similar products or patents), and alternative protection strategies if you choose not to patent. A learning exercise in strategic thinking — not legal advice.

💡 Ask AI: “Explain the concept of intellectual property in software products. What is a patent, and when does it make sense for a startup to pursue one? What are alternatives to patenting?”

Prior Art Existing products, patents, or research that is similar to what you are building. Identifying prior art is part of the IP Strategy section of your Technical Documentation. It shows what already exists and how your product is different.

---

Professional Practice

Pathfinder Checkpoint A structured progress review meeting with your pathfinder. You have two: one in Weeks 3–6 (Sprint 1 review) and one in Weeks 7–9 (pre-Demo Day review). You submit a written agenda 24 hours in advance: what you did, where you are blocked, a link to your evidence, and one specific question. Format mirrors a professional status meeting.

Traffic Light Status (🟢 🟡 🔴) A simple system for communicating project health in your Development Log:

• 🟢 On track — you are doing what you planned
• 🟡 At risk — you are behind or facing a significant problem, but have a plan
• 🔴 In crisis — you are stuck with no clear path — flag to pathfinder immediately

Using 🟡 or 🔴 is not a failure. It is professional transparency. Teams that hide problems end up in worse situations.

Demo Day Week 10. A live 6-minute presentation + 4-minute Q&A where you present your working product to a panel. Assessed as 40% of your module grade. You demonstrate the product working, present user validation evidence, and answer technical questions.