All boards
Module 2: Plan, test, refine · 4 min

Plan, test, refine

Turn an idea into requirements, a working build, and a product worth using.

3 lessons · Use the arrows or scroll to move between boards.

Messy speech can become a useful product brief.

  • Jason starts with a long voice dump: the idea, desired outcome, constraints, and whatever else is in his head.

    share
  • He asks the AI to organize it and ask one question at a time. His “98% confident” prompt means keep probing; it is not a measured confidence level.

    share
  • He then considers each stakeholder’s needs, access, and integrations before treating the brief as complete.

    share

Voice dump → interview → PRD

  1. 1

    Speak the idea and its context without polishing it first.

    share
  2. 2

    Organize the material and answer one clarifying question at a time.

    share
  3. 3

    Check the brief against the needs of each stakeholder.

    share
ask one question at a time until you're 98% confident in building a product requirements doc or a PRD
Hello, my name isJason Akatiff
share
What is the interview meant to accomplish?

Passing tests is the start of product judgment.

  • If the domain is unfamiliar, interview the people who will use the product. Then translate their requirements into a technical specification.

    share
  • Jason asks for tests alongside implementation, followed by additional checks and user testing.

    share
  • A first build may function while still missing the intended experience. Refinement begins when he can use and judge it.

    share

Requirements → implementation → refinement

  1. 1

    Understand stakeholders and write the technical specification.

    share
  2. 2

    Implement with tests, then run further checks and user testing.

    share
  3. 3

    Review the usable result and improve the experience.

    share
then that's when the real work begins to make the product amazing
Hello, my name isJason Akatiff
share
A first build works but feels wrong. What follows in this process?

The first release can be small without being a dead end.

  • Jason wants the bigger vision written down early, including what the product may eventually need to support.

    share
  • He pairs that vision with a phased build: design for the destination, then choose the MVP to implement now.

    share
  • John’s example shows the integration problem: useful standalone tools become harder to maintain when their data and workflows must connect.

    share

Vision → architecture → MVP

  1. 1

    Describe the larger product you want to reach.

    share
  2. 2

    Consider a system and data architecture that can support it.

    share
  3. 3

    Choose a phased build, starting with the MVP.

    share
but we're going to do a phased build
Hello, my name isJason Akatiff
share
How does Jason reconcile a large vision with a small first release?
Recording