Original workflow diagram; suggested practice, not measured results.
Quick answer: Use AI to organize evidence and prepare options. Keep the founder or product manager responsible for the problem, priorities, customer commitments, and decision to continue or change direction.
A founder can spend the week generating ideas, polishing requirements, and building features without learning whether a customer needs the result. AI can accelerate all three activities. The product management task is to connect that activity to a decision worth making.
This suggested weekly rhythm works as a lightweight planning aid. It is not a required Scrum schedule, and it does not assume you have a complete product team. Adjust it to your customer access, release process, and the kind of evidence your decision needs.
Begin with a question you can act on
Write the customer, the situation, the difficulty, and the decision you face. For example: do first-time customers understand what information they must provide before a setup session? That question is more useful than a broad instruction to improve onboarding with AI.
Define what you will do differently depending on the answer. If every possible result leads to the same feature, the exercise may be documenting a decision you have already made rather than investigating uncertainty.
Monday: review the evidence
Collect a bounded set of approved interview notes, support requests, product events, and sales observations. Ask AI to organize them by customer task and attach source references. Keep different customer segments distinguishable and record counterexamples.
Do not count repeated mentions as a representative market estimate unless the collection method supports that claim. A few recent conversations can reveal useful problems without telling you how common each problem is across the market.
Tuesday: choose the smallest useful test
Compare possible explanations and choose the assumption that most affects your next decision. Ask the assistant to suggest ways to investigate it, including a conversation, a prototype, a manual service, or a small product change.
Prefer the option that can answer the question with proportionate effort. Building a feature is only one way to learn. Write the expected signal and the limitations before starting so you do not redefine success after seeing the result.
Copy this experiment brief
- Customer and context: Who is affected and when does the problem occur?
- Evidence so far: Which observations support the problem, and which disagree?
- Assumption: What must be true for the proposed change to help?
- Small test: What will we do, with whom, and for how long?
- Outcome signal: What behavior or experience will we examine?
- Quality constraints: What must remain acceptable while we test?
- Decision rule: What evidence would make us continue, revise, or stop?
- Owner and review date: Who gathers the result and makes the next decision?
Avoid arbitrary pass thresholds chosen only to make the brief look precise. Use a target that fits the decision, and explain when a small sample supports learning rather than a confident numerical conclusion.
Midweek: run the test and inspect surprises
Use AI to prepare discussion guides, prototype copy, or a checklist for reviewing the result. Have a person inspect those materials before customers encounter them. When something unexpected happens, record the context rather than forcing it into the original categories.
In a hypothetical onboarding test, the team may discover that customers understand the instructions but cannot obtain a required file. Rewriting the page would not solve that dependency. The next product decision might concern an alternative input or a different service sequence.
Friday: update the decision record
Ask the assistant to compare the original assumption with the observed evidence. Separate what happened, what you infer, and what remains unknown. Review the sources yourself and decide what changes in the backlog.
Record a short rationale for continuing, revising, or stopping. Link the evidence so a future teammate can understand why an attractive idea was deferred. If the decision needs another week, name the missing information instead of calling the experiment a success by default.
Keep the human accountabilities clear
The Scrum Guide assigns the Product Owner accountability for maximizing product value; using AI does not move that responsibility to a tool. For a founder, the practical habit is to own the tradeoff and explain it. AI can help you arrive prepared, but customer commitments and product direction still need a responsible person.
Build on the earlier guides
- Build your first AI team as a founder
- Does your startup need a forward-deployed product manager?
- What does a small engineering team look like with AI?
Questions you might be asking
Can I do this without a full engineering team?
Yes. Customer conversations, manual prototypes, and small service tests can answer many early questions. Match the test to the uncertainty.
Should AI score every feature request?
It can organize requests and surface missing evidence. Do not treat an automatically generated ranking as a substitute for customer context, constraints, and product judgment.
Sources and further reading
Sources checked October 16, 2026. Templates and hypothetical examples are original teaching exercises.
AI workflow scorecard
Get the worksheet now, plus the occasional practical next step by email. No spam, unsubscribe any time.
Need a little help applying this? Explore coaching and implementation.