FR GitHub
Documentation · Learn by doing

The modules, one by one

In the order of the descent into the mine, from the test tunnel (DEMO) to the diamonds. For each module: why it exists, the need it covers, the steps, what you do there from MVP 0 to MVP x, and its references from the most to the least relevant. The same documentation is inside the tool: Help → « Documentation des modules », in the DEMO Space (in French), with a complete example where every module is filled: the Rover.

Standards and books are paid: the link leads to their public page (summary, contents or preview). The free sources are enough to learn the method.

DEMO & Training 0 m down the mine

Learn the tool and the method without breaking anything.

Why this module

Engineering rigour is not learned from a document: it is learned by practising it. DEMO is a sandbox Space where every tool has its exercise, with a complete example (the Rover); Training follows what each team member must know.

The need it covers

A new team must be productive within a week, without fear of damaging the real project, and the instructor or team lead must see who can do what.

Step by step

  1. Join DEMOHelp → « Rejoindre DEMO »: you become an editor of the sandbox.
  2. Follow the tourHelp shows the steps in the order of a project; every step has its exercise ticket.
  3. Read the documentationThis library: one page per module, with its references.
  4. Plan the trainingTraining: one plan per person, the topics to cover and their due date.
  5. Test yourselfTraining tests are graded by the server; the instructor follows the results.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?Everyone does the DEMO guided tour and reads the Exploration, Goldmine and Dynamite pages.
MVP 1 · Concept — do people want this concept?The Tools and Diamond (function tree) pages before choosing a concept.
MVP 2 · Design — does it work?The Agile, Diamond (DFMEA) and Testing pages before designing the subsystems.
MVP 3 · Validation — ready for the market?The Testing and Timesheet pages before validation and the funding claim.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. 15.783J Product Design and Development — MIT OpenCourseWare (S. Eppinger), 2006 · EN · free.
  2. Product Design and Development (7e éd.) — K. Ulrich, S. Eppinger, M. Yang, McGraw-Hill, 2019 · EN · paid.
  3. The Lean Startup — Principles — Eric Ries · EN · free.
  4. Why the Lean Start-Up Changes Everything — Steve Blank, Harvard Business Review (réimpression gratuite), 2013 · EN · free.

Exploration 60 m down the mine

The product plan: PDP phases, MVPs, milestones and Gantt.

Why this module

A product project is a series of bets: you cannot design everything at once. The PDP cuts the work into phases that end on a review; the Lean Startup adds one MVP per phase to test the riskiest hypotheses first.

The need it covers

Knowing what to do this week, what blocks what (critical path) and when the next review decides to persevere or pivot.

Step by step

  1. Start from the reference plan« Commencer » creates a PDP plan from the length of the project and the team.
  2. Adjust the tasksOne line per deliverable: code, phase, duration, predecessors, owner.
  3. Place the milestonesLean Canvas, Concept Review, PDR, CDR and Validation Report close each phase.
  4. Read the GanttThe critical path shows the tasks without slack: those are the ones to protect.
  5. Round-trip with ExcelExport, rework offline, import again: the codes are the key.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?Plan the customer interviews, the Lean Canvas and the landing page; milestone: hypotheses confirmed or not.
MVP 1 · Concept — do people want this concept?Plan ideation, the Pugh Matrix and the Concept Review; milestone: one concept chosen.
MVP 2 · Design — does it work?Plan the subsystems, the calculations and the PDR and CDR; milestone: design frozen.
MVP 3 · Validation — ready for the market?Plan manufacturing, tests and the Validation Report; milestone: ready for the market.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. Product Design and Development (7e éd.) — K. Ulrich, S. Eppinger, M. Yang, McGraw-Hill, 2019 · EN · paid.
  2. The Stage-Gate Model: An Overview — R. G. Cooper, Stage-Gate International, 2025 · EN · free.
  3. Agile–Stage-Gate for Manufacturers — R. G. Cooper, A. F. Sommer, Research-Technology Management 61(2), 2018 · EN · free.
  4. The Lean Startup — Principles — Eric Ries · EN · free.
  5. Lean Canvas — A. Maurya, LEANSTACK / LEANSpark · EN · free.
  6. Project Management (2e éd.), chap. 9 (WBS) et 10 (Schedule) — A. Watt, BCcampus (CC BY 4.0), 2014 · EN · free.
  7. NASA Work Breakdown Structure Handbook — NASA (SP-2010-3404), 2010 · EN · free.
  8. Project Scheduling Techniques (CPM) — Seneca Polytechnic · EN · free.
  9. Why the Lean Start-Up Changes Everything — Steve Blank, Harvard Business Review (réimpression gratuite), 2013 · EN · free.
  10. Running Lean (3e éd.) — A. Maurya, O'Reilly, 2022 · EN · paid.
  11. The Business Model Canvas — Strategyzer · EN · free.

Dynamite 140 m down the mine

The product's wiki: notes, minutes, decisions, procedures.

Why this module

What is not written does not exist: a forgotten decision gets made three times. The engineering notebook and the industry's Design History File keep the trace of the why; Dynamite is its living, shared version.

The need it covers

Finding in ten seconds why a solution was chosen, who decided, and which procedure to follow.

Step by step

  1. Create the page« + Page » in the product's Space, or « ✨ Avec l'IA » to import a Markdown draft.
  2. Structure itHeadings, tables, panels, coloured status; the table of contents builds itself.
  3. Link itA Ticket block shows the live status of an Agile ticket; a link leads to the requirement.
  4. Decide in writingA « Decisions » page: context, decision, consequences, date (like an ADR).
  5. Keep the historyEvery save is a version; the history shows who changed what.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?The Lean Canvas, the customer interview notes and the list of hypotheses.
MVP 1 · Concept — do people want this concept?The ideation minutes and the decision page of the chosen concept.
MVP 2 · Design — does it work?Calculation notes, PDR and CDR minutes, assembly procedures.
MVP 3 · Validation — ready for the market?Test procedures, the validation report and lessons learned.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. Engineering Design Notebook Guidelines — University of Georgia (BCHE 4920) · EN · free.
  2. Design Control Guidance for Medical Device Manufacturers — FDA, 1997 · EN · free.
  3. Architecture decisions (ADR) — GDS Way, gouvernement du Royaume-Uni · EN · free.
  4. Engineering Notebook (EGR 217) — UAB Libraries · EN · free.
  5. Documentation guide — Write the Docs · EN · free.

Goldmine 230 m down the mine

Customer needs and requirements, traced to the test that proves them.

Why this module

A successful product answers a real need. The functional specification (CdCF) turns that need into measurable requirements; traceability need → requirement → test proves you delivered what was asked.

The need it covers

Knowing at any time what the customer wants, what the product must do, with which criterion, and whether it is proven.

Step by step

  1. Write down the needsOne Need per need, with the stakeholder who expresses it and its importance.
  2. Ask the questionsThe Q&A register keeps every question to the customer and its answer, tied to the need.
  3. Write the requirementsA verifiable sentence, its rationale, its source (customer, standard), its acceptance criterion.
  4. Confirm the standardsA requirement taken from a standard arrives « À vérifier »: confirm the edition and clause.
  5. TraceEvery requirement points to its test (Testing); « Verified » once the result is attached.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?The needs from customer interviews and the open questions; a few starting requirements.
MVP 1 · Concept — do people want this concept?The CdCF: service functions, criteria, levels and flexibility; the applicable standards.
MVP 2 · Design — does it work?Requirements derived for the subsystems, each tied to its test.
MVP 3 · Validation — ready for the market?The full traceability matrix: every requirement « Verified » or justified.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. NF EN 16271 — Expression fonctionnelle du besoin et cahier des charges fonctionnel — AFNOR, 2013 · FR · paid, free preview.
  2. Analyse fonctionnelle (cours, avec CdCF) — Bordeaux INP / ENSEIRB-MATMECA, 2024 · FR · free.
  3. The Voice of the Customer — A. Griffin, J. R. Hauser, MIT Sloan / Marketing Science, 1993 · EN · free.
  4. Guide to Writing Requirements v4 — INCOSE Requirements Working Group, 2023 · EN · free.
  5. Stakeholder Needs and Requirements — SEBoK (BKCASE / INCOSE / IEEE) · EN · free.
  6. Volere Requirements Specification Template — Robertson & Robertson (copie Univ. of Edinburgh) · EN · free.
  7. INCOSE Requirements Writing Guide (résumé) — Jama Software · EN · free.

Tools & Generator 330 m down the mine

Design methods (ideation, Pugh, Kepner-Tregoe) and the name of every deliverable.

Why this module

The first concept is rarely the right one. Creativity methods widen the choice; the Pugh Matrix and Kepner-Tregoe narrow it with written criteria, not preferences. The Generator gives every PDP deliverable a unique reference.

The need it covers

Producing many ideas, choosing in a way you can defend before a jury or an investor, and finding every document.

Step by step

  1. IdeateBrainwriting: everyone writes ideas, then builds on the others'; SCAMPER and the morphological chart help.
  2. ComparePugh Matrix: one reference concept, each criterion as +, 0 or −, then the weighted version.
  3. DecideKepner-Tregoe: MUST criteria (eliminating) and WANT criteria (weighted), then the risks of the choice.
  4. Name the deliverablesGenerator: type (LCV, CRV, CDCF, PDR, CDR, VVR…), PDP step, revision.
  5. ArchiveThe deliverable carries its reference; the decision page in Dynamite cites it.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?Lean Canvas (LCV) and hypotheses; brainstorm on the problem, not yet on the solution.
MVP 1 · Concept — do people want this concept?Brainwriting, morphological chart, Pugh then Kepner-Tregoe; Concept Review (CRV).
MVP 2 · Design — does it work?Pugh on the solutions of each subsystem; PDR and CDR references.
MVP 3 · Validation — ready for the market?Kepner-Tregoe on manufacturing choices; Validation Report (VVR).

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. Concept Selection (ME 170) — University of Illinois, 2019 · EN · free.
  2. Kepner-Tregoe Decision Analysis — Prework — Kepner-Tregoe, 2021 · EN · free.
  3. Brainstorm Rules — IDEO.org Design Kit · EN · free.
  4. Morphological Analysis (Fritz Zwicky) — Toolshero · EN · free.
  5. SCAMPER Technique — Toolshero · EN · free.
  6. TRIZ — Wikipédia · EN · free.
  7. The New Rational Manager — C. Kepner, B. Tregoe · EN · free.
  8. Lean Canvas — A. Maurya, LEANSTACK / LEANSpark · EN · free.
  9. The Business Model Canvas — Strategyzer · EN · free.

Agile 450 m down the mine

Backlog, Sprints and Board from one MVP to the next; Change Management when the design changes.

Why this module

A six-month plan is always somewhat wrong. Scrum cuts the work into short Sprints that deliver something visible; Kanban shows the flow and what is blocked. When an approved design must change, Change Management keeps the request, its impact and its approval.

The need it covers

Everyone knows what to do today, the team sees what moves and what is stuck, and no design change goes through without a decision.

Step by step

  1. Fill the backlogEpics, stories, tasks and bugs; every MVP is a Version, every ticket points to its own.
  2. Plan the SprintPick the tickets of the next one or two weeks, with their points and owners.
  3. Follow the BoardTo Do → In Progress → Done; an @mention calls a teammate.
  4. LinkA ticket « implements » a requirement; « Suivre dans Agile » turns a DFMEA action into a ticket.
  5. Change cleanlyChange Management: the request (PR, bug, ECN), its impact, the CCB approval.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?One Sprint of interviews and paper mock-ups; the MVP 0 backlog fits on one page.
MVP 1 · Concept — do people want this concept?Ideation Sprints and concept prototypes; MVP 1 closes with the Concept Review.
MVP 2 · Design — does it work?Hardware and software Sprints per subsystem; the first ECNs after the PDR.
MVP 3 · Validation — ready for the market?Manufacturing and test Sprints; every test bug becomes a ticket, every fix an ECN.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. Le guide de référence de Scrum (2020) — K. Schwaber, J. Sutherland, 2020 · FR · free.
  2. The Scrum in Hardware Guide — J. Justice et al., Scrum Inc., 2017 · EN · free.
  3. Le guide Kanban — Kanban Guides, 2020 · FR/EN · free.
  4. Guidance on Application of Agile in Combined Hardware and Software Development Projects — Design Society, Proc. DESIGN 2022, 2022 · EN · free.
  5. Manifeste pour le développement Agile de logiciels — agilemanifesto.org, 2001 · FR · free.
  6. Engineering Change Requests: Process — Arena (PTC) · EN · free.
  7. Engineering change management: the complete guide — Kaizen Institute · EN · free.
  8. The 2020 Scrum Guide — scrumguides.org, 2020 · EN · free.

Testing 580 m down the mine

The product's Test Base, its procedures and plans that prove each requirement.

Why this module

A requirement without a test is a promise. Verification proves the product was built right (to the requirements); validation, that the right product was built (for the customer). In Canada and the United States, a consumer electrical product must also pass safety (CSA, UL) and EMC (ICES-003, FCC Part 15).

The need it covers

Knowing which test proves what, with which criterion and which means, and reaching the certification lab without surprises.

Step by step

  1. Build the Test BaseThe Space's tests: subject, category, standard and clause, method (T, A, I, D), objective.
  2. Write the procedureThe test means, the steps and the acceptance criterion, in Testing or a Dynamite page.
  3. Generate the Test PlanPick the tests of a milestone: the plan lists requirements, samples and criteria.
  4. Attach the resultThe report and the measurements; the linked requirement becomes « Verified ».
  5. Prepare certificationSafety and EMC tests in pre-compliance before the recognised lab.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?No product test yet: you measure the hypotheses (interviews, landing page).
MVP 1 · Concept — do people want this concept?Quick concept tests (mock-up, bench) and the list of applicable standards.
MVP 2 · Design — does it work?The full Test Base, one procedure per test, the first subsystem tests and pre-compliance.
MVP 3 · Validation — ready for the market?The validation Test Plan, tests on production prototypes, the report for certification.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. System Verification — SEBoK · EN · free.
  2. DVP&R — Design Verification Plan and Report — Quality-One · EN · free.
  3. NASA Systems Engineering Handbook (Rev. 2) — NASA, 2016 · EN · free.
  4. V-model for System Development — MathWorks · EN · free.
  5. Canada Consumer Product Safety Act — For Industry — Santé Canada · EN/FR · free.
  6. Recognized Canadian Electrical Product Approval Marks — Conseil canadien des normes · EN/FR · free.
  7. ICES-003 — Interference-Causing Equipment Standards — ISDE Canada · EN/FR · free.
  8. Equipment Authorization — Approval Guide — FCC · EN · free.
  9. Nationally Recognized Testing Laboratory Program — OSHA · EN · free.
  10. IEC 62368-1:2023 Audio/video, ICT equipment — Safety — IEC Webstore, 2023 · EN · paid, free preview.
  11. IEC 60335-1:2020 Household appliances — Safety — IEC Webstore, 2020 · EN · paid, free preview.
  12. RoHS Directive — Commission européenne · EN · free.

Timesheet 720 m down the mine

Hours per PDP step, vacation and funding claims.

Why this module

Time is a project's most expensive resource. Logging it per PDP step shows where it really goes; for SR&ED, NRC IRAP or a Revenu Québec credit, every claimed hour must be justified by a description.

The need it covers

Knowing what each phase costs, preparing a claim without retyping anything, and respecting everyone's leave.

Step by step

  1. Fill in the weekOne slot per piece of work, on the PDP step code, with a short description.
  2. SubmitOn Friday; the approver (instructor, team lead) approves or comments.
  3. Declare leaveThe Space's vacation and sick-leave codes are never claimed.
  4. Attach to fundingA Funding Space and its Budget Lines (claimable or not) for the programme.
  5. ClaimExcel export or Word report to the recipient, with every slot and its justification.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?Hours on A-01 to A-06: the real cost of customer discovery shows.
MVP 1 · Concept — do people want this concept?Hours of the Concept phase (B-07 to B-12); a first reading of the cost per deliverable.
MVP 2 · Design — does it work?Design hours per subsystem; the descriptions prepare the proof of technological uncertainty (SR&ED).
MVP 3 · Validation — ready for the market?Manufacturing and test hours; the end-of-project claim comes out in one export.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

References, from the most to the least relevant

  1. Politique sur les traitements ou salaires RS&DE — Agence du revenu du Canada · FR/EN · free.
  2. Guidelines on the eligibility of work for SR&ED — Agence du revenu du Canada · EN/FR · free.
  3. Financial support for technology innovation (PARI-CNRC) — Conseil national de recherches Canada · EN/FR · free.
  4. Crédit d'impôt relatif aux salaires – R-D — Revenu Québec · FR · free.
  5. SR&ED Self-Assessment and Learning Tool (SALT) — Agence du revenu du Canada · EN/FR · free.

Diamond 1 000 m down the mine

The functional analysis: function tree, structure, parts, risks and DFMEA, with their owners.

Why this module

You design functions before you design parts. Functional analysis forces you to say what the product must do, in which order and with which flows; the DFMEA then asks how each function can fail and which test will detect it. It is the deepest part of the mine: where the diamonds are.

The need it covers

Forgetting nothing: every function has its solution, every part serves a function, every risk has its action and owner, every severe failure mode has its test.

Step by step

  1. Function treeThe primary function, then secondary and tertiary ones (how ↓, why ↑).
  2. Functional structureThe boundary diagram: inputs, functions and outputs linked by flows.
  3. PartsThe parts × functions matrix: a part that serves no function should go.
  4. Project risksThe R-n register, probability × impact, strategy, owner, due date.
  5. DFMEAOne row per function: failure, effect, cause, S / O / D, AP, prevention, key test, action.

From MVP 0 to MVP x

PDP loopWhat you do here
MVP 0 · Discovery — does the problem exist?The primary function and the service functions seen by the customer; the first project risks.
MVP 1 · Concept — do people want this concept?The full tree and the general structure; it drives the morphological chart and the CdCF.
MVP 2 · Design — does it work?The detailed structure, parts on functions, the DFMEA with its actions followed in Agile.
MVP 3 · Validation — ready for the market?The DFMEA updated with test results; residual risks for the launch decision.

MVP x · After launch, every new version of the product runs the same Build-Measure-Learn loop, in the same Space.

The facets

Arbre fonctionnel

Primary, secondary, tertiary and technical functions; how · why · when; critical path; F numbers kept for ever.

  1. Analyse fonctionnelle (cours, avec CdCF) — Bordeaux INP / ENSEIRB-MATMECA, 2024 · FR · free.
  2. Analyse fonctionnelle d'un aérogénérateur — éduscol STI, ministère de l'Éducation nationale · FR · free.
  3. Function Analysis Guide — SAVE International · EN · free.
  4. Analyse fonctionnelle et de la valeur — INP Toulouse – ENSIACET, 2025 · FR · free.
  5. NF EN 16271 — Expression fonctionnelle du besoin et cahier des charges fonctionnel — AFNOR, 2013 · FR · paid, free preview.
  6. FIPS PUB 183 — IDEF0 (SADT) — NIST, via EverySpec, 1993 · EN · free.
  7. EN 17952 Value Management — Function Analysis (aperçu) — CEN, via iTeh, 2024 · EN · paid, free preview.
  8. EN 12973 Value Management (aperçu) — CEN, via iTeh, 2020 · EN · paid, free preview.
  9. EN 1325 Value Management — Vocabulary (aperçu) — CEN, via iTeh, 2014 · EN · paid, free preview.

Structure fonctionnelle

Boundary diagram: inputs on the left, functions in the middle, outputs on the right; energy, material and information flows.

  1. Engineering Design: A Systematic Approach (3e éd.) — G. Pahl, W. Beitz, J. Feldhusen, K.-H. Grote, Springer, 2007 · EN · paid.
  2. A Functional Basis for Engineering Design — Hirtz, Stone, McAdams, Szykman, Wood, NIST, 2002 · EN · free.
  3. Boundary Diagram Template for DFMEA — Systems2win · EN · free.
  4. Product Design and Development (7e éd.) — K. Ulrich, S. Eppinger, M. Yang, McGraw-Hill, 2019 · EN · paid.
  5. Boundary Diagrams — PTC Windchill Risk & Reliability · EN · free.
  6. P-Diagram Overview — PTC Windchill · EN · free.

Risques projet

R-n register, P × I on 5 × 5, now / residual map, strategy, owner, link to the DFMEA.

  1. Project Management (2e éd.), chap. 16 « Risk Management Planning » — A. Watt, BCcampus (CC BY 4.0), 2014 · EN · free.
  2. ISO 31000 — Risk management — ISO, 2018 · EN · paid, free preview.
  3. Project Management 2nd ed., chap. 10 « Project Risks » — Cleveland State University Pressbooks · EN · free.
  4. The Standard for Risk Management in Portfolios, Programs, and Projects — PMI · EN · paid.

DFMEA

Per AIAG-VDA: S / O / D, Action Priority rather than RPN, prevention, key test of the Test Base as detection.

  1. AIAG & VDA FMEA Handbook — AIAG / VDA, 2019 · EN · paid.
  2. Reviewing AIAG / VDA FMEA Handbook — Carl S. Carlson, Accendo Reliability, 2022 · EN · free.
  3. The AIAG-VDA FMEA Process and Approach — Omnex (livre blanc) · EN · free.
  4. AIAG/VDA's FMEA Manual Is a Major Advance — W. A. Levinson, Quality Digest, 2020 · EN · free.
  5. FMEA — Failure Mode and Effects Analysis — Quality-One · EN · free.
  6. FMEA — ASQ · EN · free.

Golden Nuggets

First principles and the 5-step algorithm: question every requirement, delete, simplify, accelerate, automate.

  1. First Principles: The Building Blocks of True Knowledge — Farnam Street · EN · free.
  2. Musk's 5 Step Algorithm — J. Minnaar, Corporate Rebels, 2023 · EN · free.
  3. DFMA — Design for Manufacturing and Assembly Explained — Wevolver · EN · free.
  4. Elon Musk's Framework for Thinking — Farnam Street · EN · free.
  5. Elon Musk — Walter Isaacson, Simon & Schuster, 2023 · EN · paid.

References, from the most to the least relevant

  1. Analyse fonctionnelle (cours, avec CdCF) — Bordeaux INP / ENSEIRB-MATMECA, 2024 · FR · free.
  2. AIAG & VDA FMEA Handbook — AIAG / VDA, 2019 · EN · paid.
  3. Engineering Design: A Systematic Approach (3e éd.) — G. Pahl, W. Beitz, J. Feldhusen, K.-H. Grote, Springer, 2007 · EN · paid.
  4. Project Management (2e éd.), chap. 16 « Risk Management Planning » — A. Watt, BCcampus (CC BY 4.0), 2014 · EN · free.
  5. First Principles: The Building Blocks of True Knowledge — Farnam Street · EN · free.