Solve Hard Problems Systematically

Proof required

Submit your 2-week problem log (at least 8 entries with four fields per entry: initial framing / first move / reframe — yes/no + how / time spent) plus a 200-word signature analysis naming one specific recurring weakness with evidence from at least 2 log entries.

What gets checked

• 8 real problems documented with all four fields — invented or hypothetical examples do not count; the log must be drawn from actual situations you encountered
• Signature analysis names one specific weakness and cites at least 2 log entries as evidence, not a general observation disconnected from the data
• At least 3 of the 8 problems are open-ended or ambiguous (no single correct answer) — a log of 8 well-defined procedural tasks does not reveal the signature that matters

Common mistakes

• Selecting only simple, well-defined problems where the first framing is always correct — the log should include problems where the initial framing proved wrong
• Writing all 8 entries retrospectively in one sitting at the end of 2 weeks — the instinctive first move can only be captured in the moment
• Signature analysis that is too broad to be actionable ('I sometimes rush') rather than specific and evidenced from the log

Resources

What a verifier looks for

• Confirm entries have dates spread across the 2 weeks — all 8 entries filed on the same day indicate retrospective writing
• Check that at least 3 problems are genuinely open-ended — if all 8 are procedural tasks, the log does not reveal problem-solving skill
• Ask the submitter to explain their signature weakness using a specific log entry — can they articulate what they missed in the moment?
• The reframe field should show genuine pattern — if all 8 say 'no reframe needed', ask the submitter why — it is very rare to face 8 significant problems without any needing reframing

Proof required

Submit your 3 structured problem-solving case studies (minimum 300 words each): problem statement / every step of the chosen method with specific outputs at each step / solution implemented / outcome or outcome-pending with reason. One case study must involve an open-ended problem. The same method must appear across all 3.

What gets checked

• Every step of the chosen method is documented with actual outputs — not a high-level summary of what the method involves but what you produced at each step
• At least one case study involves an open-ended problem where the 'right answer' was genuinely unknown in advance
• Outcome section present for all 3 cases — what happened when the solution was tried, not just what the solution was; if outcome is pending, explain why and what you expect

Common mistakes

• All 3 problems are narrow technical problems with single correct answers — applying a structured method to a problem that has an obvious answer does not demonstrate problem-solving growth
• Skipping steps in the method without explanation — if a step 'didn't apply', state why specifically; blanket skipping signals the method was not genuinely applied
• Outcome section omitted because the solution is 'still being implemented' — a real outcome (even partial) or a documented prediction with a timeline is required

Resources

What a verifier looks for

• Check that the same method appears across all 3 case studies — switching between 5 Whys and SCAMPER is not applying one method rigorously
• For the open-ended case, confirm there was genuinely no single correct answer in advance — the 'open-ended' criterion should not be met by relabelling a diagnostic problem
• Ask the submitter to walk through one step of the method that surprised them — this tests genuine engagement vs. mechanical compliance
• If any step is missing from the documentation, ask why — 'it didn't apply' needs a specific reason, not just omission

Proof required

Submit your M2 portfolio (3 case studies) plus the reviewer's written assessment from the M3 session: the problem they presented (verbatim or close paraphrase), their notes on how you approached it covering framing / assumption-testing / option generation / ambiguity handling, one thing you did well and one specific gap, and their sign-off confirming a live session with a novel problem they brought.

What gets checked

• Reviewer assessment is behaviorally specific — names actual moves observed during the 30-minute session, not generic praise or criticism
• Reviewer confirms in writing that the problem was novel and that the submitter had no prior exposure to it
• Reviewer minimum qualification: 5+ years solving open-ended professional problems (senior engineer, consultant, entrepreneur, researcher, or equivalent) — a peer without this background does not qualify

Common mistakes

• The session becomes a presentation of M2 work rather than live solving of a novel problem — the reviewer must bring a fresh problem and the session must be observational
• Reviewer assessment is generic ('did well overall', 'good thinker') without noting specific behaviours — this cannot be verified
• The submitter prepares extensively for what kind of problem the reviewer might bring, coaching themselves in advance — the novel problem must be genuinely novel in content, not just unfamiliar in form

Resources

What a verifier looks for

• Confirm the problem you brought was genuinely novel to the submitter — ask them to describe their first 30 seconds of encountering it, which should reveal surprise or uncertainty
• Look for evidence of framing before solving: did the submitter restate or challenge the problem before attempting a solution? This is the most important single behaviour to assess
• Note whether multiple approaches were generated before committing to one — a solver who commits to the first approach without considering alternatives has not yet developed the skill
• Reviewer minimum qualification: 5+ years solving open-ended professional problems (senior engineer, experienced consultant, entrepreneur with real problem-solving track record) — peers without this background do not qualify