What A Prova Sprint Actually Looks Like: A Week-One Walkthrough

Here is what week one of a Prova sprint actually looks like. Not the marketing version — the real version.

You pick one piece of work. You create an artifact. You test it against a real or realistic situation. You submit the output. Someone reviews it against defined criteria and tells you whether it passes or needs revision.

No recorded lectures. No quizzes. One sprint, one proof point.

Day 1: Choosing the work

The first thing you do is not build anything. You make the work specific.

For an Operator, that usually means naming one recurring workflow. For a Leader, it means naming one AI pilot or operating decision that needs evidence. For a Builder, it means naming one slice a real user could try.

This sounds simple. It is not. Most people arrive with a vague idea — "I want to automate my content process" or "we need an AI pilot" — and the first exercise forces them to get specific.

The specificity requirement filters out work that is not ready. If you cannot name the user, moment, input, and decision, the sprint has nothing concrete to review.

Days 2–3: Making the artifact

Once the work is scoped, you make the artifact.

That artifact differs by path. The Operator may produce a workflow audit or brief. The Leader may produce a pilot decision package, stakeholder test, or measurement ladder. The Builder may produce a build brief, working slice, or launch checklist.

The common pattern is the same:

1. Define the scope. What is included, and what is intentionally out?
2. Name the evidence. What would prove this worked well enough to continue?
3. Expose the failure mode. Where could the work mislead the team, waste time, or create risk?
4. Write the next decision. What should change if the artifact passes?

Most people revise the Day 1 definition during this phase. That is expected. Making the artifact exposes what the idea was hiding.

Day 4: Testing it against reality

This is the most important day, and the one people skip when they build alone.

You test the artifact against a real or realistic case from your work — not a hypothetical scenario designed to make the answer look good.

The purpose is not to confirm that the artifact works. It is to find where it fails. Every workflow, pilot, and product slice has edge cases. The sprint finds them before you ask the organization to trust the work.

Common failures at this stage: the workflow is too broad, the metric cannot prove the decision, the stakeholder risk is not named, the slice depends on data no one can access, or the AI output sounds plausible but misses the business context. These are fixable. Submitting without discovering them wastes the review cycle.

Day 5: Preparing the submission

Submissions are not polished decks. They are structured documents with three required sections:

1. The artifact. The actual workflow map, brief, decision package, build slice, or launch gate.
2. The evidence. What happened when you tested it against real or realistic work.
3. Self-assessment. One paragraph: where does this work hold up, and where does it still need judgment?

The self-assessment section is deliberate. It is harder to write than it sounds, and the quality of that paragraph tells the reviewer a lot about whether you understand what you built.

After submission: what the review process looks like

Reviews are returned against the standard for that sprint. The reviewer checks whether the work is concrete, whether the evidence is strong enough for the next decision, and whether the failure modes are honestly named.

Each criterion gets one of three ratings: meets standard, needs revision, or not yet addressed.

Passed means the artifact meets the standard for its stated scope. It does not mean it is perfect. It means it is solid enough to build on.

Revise means one or more criteria need work before the sprint can progress. The review includes specific feedback — not "make it better" but "the chosen pilot does not name the stakeholder decision this evidence is supposed to support."

A revise result is not a failure. It is the review doing its job. Several of the strongest tools I have seen come through Prova went through one revision cycle.

How this differs from a course

In a course, you complete the module and move to the next one regardless of whether you understood it. In a Prova sprint, you cannot move forward until the artifact meets the standard. That is the structural difference.

The review is not a grade. It is a quality gate. The artifact either passes or it does not.

You leave with a real piece of work — something you can use, defend, test, or build on — and a clear record of where it holds up and where it falls short. That record becomes the starting point for the next sprint.