Skip to main content

    CraftingProduct — Field manual for AI transformation · Amsterdam

    Your AI transformation doesn't need another presentation. It needs a workshop.

    Two minutes — then fit and next steps

    The Record — selected figures

    Snapshot · 2026

    Community

    2,000+ people

    Across Luma, Meetup, workshops and build sessions.

    50+
    Events hostedLuma · lifetime
    4.6/ 5
    Community ratingMeetup · 2026

    The problem

    Thesis

    Your team is not short on AI information. It is short on hands-on practice with the machines.

    Reading

    The deck gets applauded. The pilot stalls. Six months later the model has moved and your team is back at the slides. Running an agent against a real problem in your own stack is a different skill entirely.

    You learn this by building, under time pressure, next to someone who has already done it. That is the workshop.

    Workshop territories

    Four territories. One way of working: hands on the machine.

    Every territory follows the same procedure: situation, objective, build, review. Pick the field your team needs to operate in.

    1. T.01

      AI Builder

      Your team ships a working AI feature in the room. Real prompts, real code, your real problem.

    2. T.02

      Agents

      Design and run an agent against a task your team actually owns. You leave with a working system, not a diagram of one.

    3. T.03

      Claude

      Claude in daily operation: projects, tools, and workflows tuned to how your team works, practiced until they stick.

    4. T.04

      Codex

      AI-assisted engineering for real codebases. Your developers pair with Codex on your repository, under review.

    Field record

    A room under time pressure teaches more than a quarter of alignment meetings.

    I run build sessions the same way I run workshops: one defined problem, a clock, and working software as the only acceptable output. The format moves straight into a team setting.

    Audience and panel at the Amplitude and Lovable Future of Product Building event in Amsterdam.
    Future of Product Building — Amplitude x Lovable, Amsterdam.

    Method

    The procedure does not change. The problem does.

    One method. Four actions. A real problem enters unresolved and leaves as something the team can operate.

    1. P.01ScanUnresolved

      Situation

      You bring a real problem from your own work. If there is no real problem, there is no workshop.

      Problem brief

      Intake

      Problem
      Stated three different ways
      Owner
      Not named yet
      Constraint
      Assumed, not written

      Working means

      Not defined yet.

      Loop

      • Build
      • Run
      • Review

      Close the loop

      • Keep
      • Change
      • Next
      P.01ScanUnresolvedPhase snapshot
    2. P.02FrameDefined

      Objective

      We define what "working" means before anyone touches a keyboard. One objective, stated plainly.

      Problem brief

      Framed

      Problem
      One sentence, agreed
      Owner
      One person in the room
      Constraint
      Written down and accepted

      Working means

      One observable result the team can check in the room.

      Loop

      • Build
      • Run
      • Review

      Close the loop

      • Keep
      • Change
      • Next
      P.02FrameDefinedPhase snapshot
    3. P.03BuildIn transformation

      Procedure

      Your team builds against the clock. The machines are on the table — agents, Claude, Codex — and so is the instructor.

      Problem brief

      In transformation

      Problem
      One sentence, agreed
      Owner
      One person in the room
      Constraint
      Written down and accepted

      Working means

      One observable result the team can check in the room.

      Loop

      • Build
      • Run
      • Review

      Close the loop

      • Keep
      • Change
      • Next
      P.03BuildIn transformationPhase snapshot
    4. P.04ReleaseOperational

      Review

      The output is checked against the objective. What worked stays. What failed is named, not smoothed over.

      Problem brief

      Operational

      Problem
      One sentence, agreed
      Owner
      One person in the room
      Constraint
      Written down and accepted

      Working means

      One observable result the team can check in the room.

      Loop

      • Build
      • Run
      • Review

      Close the loop

      • Keep
      • Change
      • Next
      P.04ReleaseOperationalPhase snapshot

    Input — UnresolvedOutput — Operational

    Field Notes

    Notes from the field, filed after the work.

    Dima Abramov, founder of CraftingProduct, at an Amsterdam product community event.
    Dima Abramov — founder, CraftingProduct

    Founder dossier

    CraftingProduct is led by Dima Abramov.

    Practice
    Senior product leader. Builder of AI products and communities in Amsterdam.
    Delivery
    Driving AI adoption and enabling operational processes with AI at Foundever / Qelp.
    Community
    Founder, Amsterdam Vibe-Coding Meetup. Lovable ambassador.
    Field work
    Runs workshops and build sessions for teams adopting AI and agents.

    Studio principle

    Teach the way the work is done: on real problems, with the machines running, in front of the people who have to live with the result.

    Community

    The workshop format was shaped in public, in rooms like these.

    Amsterdam Vibe-Coding Meetup — rated 4.6 out of 5 by its members.

    Community

    Luma + Meetup · 2026

    2,000+ people

    Across Luma, Meetup, workshops and build sessions.

    Community Meetup
    Community Meetup — Building Together
    Prototyping Session
    Prototyping Session — From Idea to Demo
    Makers Night
    Makers' Night — Focused Building Session
    Meetup record

    Qualification

    Bring a real problem. Leave with a working build.

    A workshop, hackathon or custom build. Two minutes to describe the problem.