AIWorkDex
Product Practice

Run a product feasibility walkthrough before commitment

Resolve, isolate, or stop for the dependencies most likely to invalidate the shaped solution.

Preparation
A cross-functional walkthrough plus bounded specialist checks.
Difficulty
Advanced
Task
Check feasibility before commitment
Back to the Task: Check feasibility before commitment

Before you start

Get what you need before you start

  • Bring the shaped solution, complete user path, product boundary, and evidence already collected.
  • Invite qualified reviewers for the technical, design, operational, contractual, legal, or regulatory risks that apply.

Steps

Work through the method

Use the listed inputs and tools. Check the evidence when you need to verify a step.

  1. Walk through the product path

    Move through the path from start to finish. At each step, ask what must be true for the user, system, organisation, supplier, and governing rules.

    Why it matters: A use-case walkthrough exposes assumptions hidden by a static feature list.

    Input
    The shaped solution, user path, and known constraints.
    Output
    A dependency list linked to each point in the product path.
    Tools in this stepGitHub

    Evidence for this step

  2. Isolate the critical dependencies

    Mark dependencies that could invalidate the concept or break its boundary. Ask a qualified reviewer to define the evidence or bounded spike needed for each one.

    Why it matters: Critical uncertainty needs an owner and decision path before commitment.

    Input
    The dependency list and specialist review.
    Output
    A short set of critical risks with owners and evidence needs.
    Tools in this stepGitHub

    Evidence for this step

  3. Record resolve, isolate, or stop decisions

    Create an issue for each approved check and record known blocked-by relationships. Resolve the risk, isolate it within the boundary, or stop the product decision.

    Why it matters: A recorded dependency can prevent a known risk from disappearing inside committed work.

    Input
    The critical risk set and approved checks.
    Output
    A feasibility decision with evidence, bounded spikes, dependencies, and stop reasons.
    Tools in this stepGitHub

    Evidence for this step

Success checks

Check the result before you finish

  • Every critical dependency has evidence, a bounded check, or a stop decision.
  • Qualified reviewers own risks outside the core team’s competence.
  • Known blocking relationships are visible before commitment.

Failure modes

Watch for these problems

  • Do not treat the checklist as complete risk discovery.
  • Stop when a legal, safety, or contractual dependency lacks qualified review.
  • Re-shape the solution when a required check exceeds the investment boundary.

Tools

Choose the tools you need

Sources

Read the sources behind this practice

Check what each source supports and where the advice has limits.