Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Boris's checklist is just a slightly modified version of your classic mathematics or engineering problem solving steps.

    1. Write down your problem statement.

    2. State your knowns, unknowns, and assumptions.

    3. Solve.

    (Step 2 is also further enhanced by performing first principles reasoning, collecting data for evidence, and using reasonable estimates where data is absent.)

    I think Boris's list is pretty solid, but I personally would unmix the problem solving methodology from the planning/goal setting SMART principles as two separate things. One addresses problem solving, while the other addresses human cognitive shortcomings for getting things done.

  • I find myself slightly more hypothesis-driven, so I tend to be more effective putting much of the focus of 2. Gather missing information after 3. Define the problem ... or at least inside the iteration loop.

    As others here have noted, it’s very easy to get lost gathering information that isn’t actually helpful in assessing whether the problem is well formed or whether potential solutions are applicable.

    The more you force yourself to specify the problem clearly, but treat your initial problem definition as somewhat suspect - potentially missing key dimensions - the more you will be comfortable finding the information to validate / challenge it (or it's implied solutions) and re-shaping both the problem and it's solutions efficiently.

  • Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”
  • I am confused by step 5.

    A. Why define the goal after identifying the solution? Or does define the goal mean identify a stopping point for step 4, in which case you must first define the solution?

    B. Isn't the goal explicit in a clear problem definition?

    1) Ambiguous problem definition with no implied goal: We need more money.

    2) Clearer problem definition with implied goal: We need $500K by Monday.

  • It’s often struck me how many “leaders” basically jump to step 6, and come up with an urgent set of superficial actions without even clarifying what they’re trying to do. There’s probably some value in “bias for action” as you might call it. But it’s been one of the difficult adjustments for me, how little people want to think.
  • > 3. Define the problem

    If you do this step well, in my experience, the next steps fall into place quickly.

    My version: accurately naming the problem is the essence of problem solving. There are things you usually need to do before you can accurately name the problem, because most problems aren’t presented to you in textbook form.

    Once properly defined and framed, it’s obvious how to solve most problems, most of the time.

    If you’ve ever worked with someone amazingly good at accurately naming the problem, it’s hard to unsee it. This is one of the hidden talents of the most effective people I’ve met.

  • This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.

    Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

    The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.

  • I have worked in GTM/PM consultancy for some time now. This is the patterns I often observe:

      - Have a vague understanding of the problem
      - Architect an overcomplicated solution thinking of all possible contingencies
      - Pitching the overcomplicated solution to someone else
      - Ask them to come up with a simple solution. Ask questions to "birth" to the solution.
      - Not providing any feedback as that would mean need you to be accountable for the work
      - Trying to convince them they should work out the solution because they are the expert and much smarter then you
      - Taking credit for solving the problem
    by wqtz

Explore Birbla archives