Finish one small task that a team can review
For a product manager starting with Codex, the first obstacle is often an unclear brief rather than a missing prompt trick. This practice project redesigns booking for a fictional shared art studio. Visitors want to see available seats, duty staff handle cancellations, and the owner wants fewer coordination calls. Produce an environment check, a competitor evidence matrix, an interview-needs table and a reviewable PRD. Installation does not automatically provide access to company documents or business systems.
Start with a familiar service and one decision: should releasing seats after cancellation be the next priority? That question is easier to assess than researching an entire booking market. Products, interviews and numbers used in this example are synthetic practice material, not market evidence or measured release results.
Day zero: prepare the environment and first capabilities
Use the official Codex CLI quickstart to choose an installation method for your system, sign in and work from a dedicated practice directory. Check account access, project location and the permitted read/write scope. First ask the agent to list three practice files and summarize each in one sentence without changing files or using the network. It should distinguish the product brief, interview excerpts and booking rules. Resolve authentication, path, format or permission failures before adding more skills.
Prepare a short brief stating whom the service supports, how booking works today, what is going wrong, which materials may be cited and what to deliver. Keep originals read-only and place reports in a separate output directory. Do not begin with identifiable interviews containing names, phone numbers and booking habits. De-identify materials and establish authorization. When a file cannot be read, the agent should explain the missing prerequisite rather than reconstruct its contents from guesses.
For extensions, check whether SkillPI Skill Finder is already installed. If missing, follow its official repository instructions, then search for a specific task. Inspect full instructions, pinned source, license, dependencies and permissions before a small trial. Codex supports explicit skill selection and task-based matching, as described in the official skills documentation; mentioning a keyword does not guarantee a particular skill will be selected.
The current SkillPI search for product requirements returned no results, so this article does not turn the original topic's competitor or PRD skill names into invented catalog links. The open-source PM Skills project has staged documentation and examples that can inform artifact design. It is a methodological reference here, not a verified SkillPI association or software downloaded and executed for the reader.
Task one: make competitor research support a decision
A useful task card says: compare booking tools Alpha and Beta with our manual process; answer only when a cancelled seat becomes available, whether a waiting visitor is notified and who may cancel; list evidence gaps before producing a matrix; do not recommend a purchase. Label fictional source packets as simulated. For real research, record an official help page, observation date, applicable version or region, a factual summary and uncertainty for each relevant cell.
Use one decision question per row and one option per column. A page describing a waiting list does not establish that notifications are automatic by default. Missing documentation does not prove a feature is absent. Distinguish documented behavior, observations from an authorized trial and unresolved questions. If network access is unavailable, organize supplied evidence and its dates instead of calling an old screenshot current research.
Ask the owner to review two things before expanding the first report: do the comparison questions affect the immediate decision, and do sources support the conclusions? Then fill important gaps and reconcile conflicting evidence. Finish with conditions for choosing an approach. In this example, the recommendation is to test whether seat release reduces manual coordination, not to imitate every competitor feature. A SWOT can organize discussion, but filling its boxes does not establish that its claims are true.
Task two: turn interview excerpts into traceable needs
Provide three de-identified practice excerpts: a visitor does not know whether a cancelled place is available, duty staff miss phone calls while updating a spreadsheet, and the owner cannot add staff this month. Ask the agent to separate the original statement, observed behavior, inferred cause and unconfirmed need. Give findings source identifiers. Three participants do not represent the entire audience and do not support a population-wide demand percentage.
Convert a request such as send me a reminder into questions: who receives it, which state change triggers it, which channel is permitted, when it becomes disruptive and what happens if delivery fails? Ask for a needs list and conflicts before a proposed solution. The owner confirms that this iteration covers seat release and visible page status; SMS, payments and a full waiting-list queue remain out of scope. Preserve exclusions and reasons so later ideas do not silently become commitments.
The output is a source-linked needs table with unresolved questions and owners. Treat fewer coordination calls as a hypothesis requiring a baseline and pilot observation. Do not let an agent invent interview quotations or research participants merely to make a report feel complete.
Task three: align before drafting the first PRD
Supply product context, target users, confirmed needs, the existing process, constraints and evidence identifiers. Request an outline and questions first. After alignment, draft the problem and goal, included and excluded scope, roles and permissions, normal and failure flows, acceptance conditions, metric definitions and open decisions. A PRD records team agreement; a generated document is not automatic implementation approval.
Requirement R1 can state: after a confirmed booking is successfully cancelled, release one seat and show the updated availability. A test fixture has capacity eight and seven occupied seats. Cancelling one confirmed booking leaves six occupied seats; cancelling the same booking again does not subtract another seat; a failed cancellation retains the original count and explains the failure. These numbers are synthetic acceptance data. Engineering still needs to confirm concurrency behavior and update timing rather than inherit an unsupported promise of instant consistency.
Define a candidate metric as cancellations requiring manual coordination divided by successful cancellations over the same pilot period. Establish whether the necessary records exist and who interprets them before setting a target. When there is no baseline, measure first instead of inventing an improvement percentage. Strategic context matters: this iteration supports less manual coordination after cancellation, not automation for its own sake. A different business goal requires reconsidering the problem and measurement.
Put a matching skill at the prose-review step
After factual and scope alignment, use Writing Guidelines to inspect the technical explanation's structure, phrasing and examples, producing actionable findings with file locations. It requires the target documentation and network access to its linked writing handbook. Identify the audience as a joint product, design and engineering review and adapt the house style and language appropriately.
This is a technical-writing skill. It does not discover customer needs, validate competitor capabilities or establish strategic correctness. Recheck evidence identifiers and requirement meaning after edits, especially if an editor turns a possibility into a certainty or removes exceptions that engineering needs. If Word documents or interactive prototypes are required, select separately verified tools suitable for those formats. A Markdown file does not demonstrate that every requested artifact was exported.
Troubleshooting and acceptance
Can a PM begin without coding? The research and requirements exercises can start with natural language and files, but the PM still needs to recognize evidence, unresolved decisions and permissions. Engineering feasibility belongs with the relevant owner. The first deliverable is reviewable analysis and requirements, not a claim that a feature shipped.
If the PRD still feels generic, check for concrete constraints, counterexamples, prior decisions and source material. Have the agent ask focused questions and preserve answers before rewriting. More headings do not compensate for missing context.
For time and cost, bound the number of options, sources, iterations and output formats. Record actual model usage and external-service charges rather than promise a universal completion time or that every skill is free. Accept the exercise when files open, matrix claims have sources, requirements are traceable, important failures are explained and unknowns remain clearly labeled. Then expand into data analysis, reporting and collaboration, using this task card as a starting point for improvement.