Pancyprian Product Dev III common mistakes
Pancyprian Product Dev III · Understand the traps and how to avoid them.
Presenting a linear waterfall sequence (idea → design → prototype → launch) as the answer to any 'describe the product development process' question, without distinguishing concept, development, and industrialization phases or their decision gates.
Candidates memorize one textbook flow and reuse it; the exam expects phase-gate or stage-gate logic with defined deliverables and go/kill criteria, and marks drop when the answer ignores iteration and feedback loops between phases.
What to do instead
Build a one-page phase-gate map: discovery/concept, feasibility, detailed design, validation, industrialization, launch. For each gate, write the deliverable, the decision owner, and the kill criterion. Practise redrawing it from memory and then adapting it to a specific product (e.g. a consumer electronics item vs a medical device) so you can argue why phases overlap.
Answering design-thinking questions by listing the five stages (empathize, define, ideate, prototype, test) as a checklist, without explaining divergent-then-convergent behaviour, reframing of the problem statement, or how insights from testing feed back into the define stage.
The stage names are easy to memorize and feel sufficient; candidates do not practise explaining the mindset and the iteration loops, so they cannot answer questions that ask why a team should return to an earlier stage or how to run a productive ideation session.
What to do instead
For each stage write two sentences on the activity, the artefact produced, and the failure symptom if it is skipped. Then write a worked example: a user observation, the reframed problem statement ('How might we...'), three divergent concepts, the cheapest prototype, and the specific test result that changed the direction. Rehearse the example aloud until the loop is natural.
Treating user research as a single interview and jumping straight to a solution, with no sampling rationale, no distinction between qualitative and quantitative methods, and no discussion of bias, consent, or how findings were synthesized into requirements.
Candidates conflate 'asking users what they want' with research; they lack practice in choosing methods (contextual inquiry, diary study, survey, usability test) and in converting raw data into prioritized, testable requirements.
What to do instead
Create a method-selection table: question type (exploratory, evaluative, validating) against method, sample size, cost, and output. Practise writing requirement statements in the form 'The system shall [behaviour] under [condition] to [measurable criterion]' and separating must-have from nice-to-have using a simple scoring matrix. Add one paragraph on consent, anonymity, and how you avoided leading questions.
Generating concepts that are variations of one idea (three colours of the same shape) and evaluating them with vague criteria such as 'looks modern' or 'user-friendly', with no structured selection method.
Under time pressure candidates default to safe, familiar solutions; they have not practised deliberate divergence techniques or weighted decision matrices, so the concept-generation answer lacks breadth and the selection answer lacks rigour.
What to do instead
Practise three divergence prompts: functional decomposition (list sub-functions and generate a principle for each), SCAMPER, and TRIZ-style contradiction resolution. Then build a weighted matrix with 5–7 criteria (e.g. cost, manufacturability, safety, user value, sustainability), explicit weights, and scores with a short justification per cell. Show at least one concept you rejected and why.
Describing prototyping as 'build a model and show it to users' without specifying the fidelity level, the learning objective, the test protocol, or the iteration decision that followed.
Candidates see prototyping as a single step rather than a sequence of questions of increasing cost; they do not connect prototype fidelity to the uncertainty being reduced, so answers stay generic.
What to do instead
For each prototype type (paper, foam/3D-printed form model, functional breadboard, looks-like/works-like, pre-production) write: the question it answers, its cost and lead time, and the decision it unlocks. Draft a test protocol with task, success metric, sample, and pass/fail threshold, and describe one concrete design change that resulted.
Choosing a material or process by naming a familiar one (ABS, injection moulding) without linking it to the functional requirements, production volume, tooling cost, tolerance, or surface finish.
Candidates memorize material names but not selection logic; they do not practise mapping requirements to properties (stiffness, thermal resistance, food contact, recyclability) and ignore volume-dependent economics.
What to do instead
Build a selection sheet: requirement → property → candidate materials → process compatibility → cost at 1k, 10k, 100k units. Learn the break-even logic between tooling-heavy processes (injection moulding) and tooling-light ones (CNC, vacuum forming, 3D printing), and be ready to state draft angles, wall-thickness rules, and tolerance implications when the process is named.
Mentioning sustainability only as 'use recyclable materials' with no treatment of lifecycle stages, energy and transport impacts, design for disassembly, material separation, end-of-life routes, or the trade-offs against cost and durability.
Sustainability is often treated as an add-on paragraph; candidates have not practised lifecycle thinking or quantified comparisons, so the answer stays at slogan level and cannot address rebound effects or greenwashing risk.
What to do instead
Run a simplified lifecycle assessment on a familiar product: list stages, the dominant impact per stage, and two design changes with their effect (e.g. mono-material housing improves recyclability but may reduce impact strength). Learn design-for-disassembly principles, material labelling, and the difference between recyclable, recycled content, and compostable claims. Practise stating a trade-off explicitly rather than claiming a free win.
Handling safety and regulatory questions by listing a standard's name without identifying the applicable market, the risk-assessment method, the conformity route, or the documentation required (technical file, declaration, traceability).
Candidates memorize a few standard numbers but not the framework; they cannot map a product category to its directive or regulation, and they confuse voluntary standards with legal obligations.
What to do instead
Build a market-entry table: product category → applicable regulation/directive → essential requirements → harmonized standards → conformity assessment route → documentation and marking. Practise a short failure-mode risk assessment (severity × probability, mitigation, residual risk) and know the difference between design controls, verification, and validation. Flag any standard you are unsure of rather than guessing a number.
Answering project-management scenarios by naming a tool (Gantt chart, Kanban) without addressing scope definition, dependency and critical-path logic, resource levelling, risk register, or how a change request is handled.
Candidates learn tool names rather than planning mechanics; they do not practise the reasoning behind schedule compression, buffer placement, or escalation, so scenario questions expose shallow understanding.
What to do instead
Work three short scenarios: a slipped supplier, a late requirement change, and a resource conflict. For each, write the trigger, the impact on scope/time/cost, two options with trade-offs, and the decision and communication plan. Learn critical path, float, and the difference between crashing and fast-tracking, and keep a five-item risk register with owner and mitigation.
Describing teamwork and communication as 'good collaboration and clear communication' without naming artefacts, cadence, decision rights, or how conflict and stakeholder alignment are actually handled.
These questions feel soft, so candidates answer with adjectives; they have not practised describing design reviews, RACI-style responsibility mapping, a communication plan, or how a disagreement between engineering and marketing was resolved with evidence.
What to do instead
Prepare concrete artefacts: a design-review agenda with entry and exit criteria, a responsibility matrix for a cross-functional team, a stakeholder communication plan by audience and cadence, and one conflict story resolved by test data rather than seniority. State the decision, who owned it, and how it was recorded so the answer sounds operational rather than aspirational.