Draft an Issue-to-Requirement Note with AI at the Cursor

A product manager can turn a verified issue into a reviewable requirement note by speaking an AI request that contains four inputs (user problem, evidence, expected behavior, and open question) and asks for a structured note, using the supported AI Task workflow at the cursor of a compatible Windows text field. The result is a draft. You check each line against your sources, remove anything that was not in your inputs, and decide when the note is ready to share.

This article covers that workflow with a worked example, a reusable template, a role-specific review checklist, and a method for measuring how long it takes to reach reviewed text.

Product issues usually arrive as fragments: a support ticket, a comment from a sales call, a chart pasted into chat, a half-formed idea from a planning discussion. Your job is to connect them into a statement that engineering, design, and stakeholders can act on. That involves two kinds of effort:

1. Reasoning. What is the problem, who has it, what do we know, and what do we not know?
2. Structuring. Turning that reasoning into headings, short paragraphs, and a clear separation between facts and assumptions.

Only you can do the reasoning. The structuring is mechanical, and it is where notes often wait. You know what you think, but opening a blank document and shaping it takes effort. Notes written in a hurry tend to mix evidence with opinion, which makes review harder.

Speaking your inputs and requesting a structured draft at the place where you will edit it may reduce some of that mechanical effort. It may also spare you a separate AI window and a copy-and-paste step, where the supported cursor workflow fits your tools. It does nothing for the reasoning, and the quality of the draft depends on the quality of the inputs you supply.

SpeakLingo uses the term Syping for a workflow in which spoken words become text where your cursor already is. The Syping page explains the idea. Three capabilities matter for this task:

• Online transcription converts speech to text and supports 99+ languages, so you can speak in a supported language that suits you.
• AI contextual formatting shapes transcribed text to fit its context, for example turning a spoken run of thoughts into a structured note.
• Spoken AI requests let you say a task instruction and receive text at a compatible, focused Windows text field.

Several boundaries affect how you plan the work:

• SpeakLingo is not compatible with every application or field. Check that your tracker, document editor, or wiki field accepts it before you depend on it.
• Its role is to deliver text at the cursor. You decide what happens to that text next, and you should review it before anything is sent or saved for others.
• AI requests need an internet connection, an enabled service, your consent, and the necessary access.
• Audio and text, and optional screen context if you opt in, may be sent to remote services to process a request. Consider what you say aloud and what is visible on screen, and follow your organization's rules.
• AI output needs review. It can misstate, omit, or embellish.

If your connection is interrupted, English transcription can serve as a fallback where a local runtime is set up. It captures your words. The AI formatting and AI requests described here do not work offline, so the structuring step waits for connectivity or is done by hand.

A few minutes of preparation prevent most of the problems in this workflow.

1. Pick the destination field. Choose where the note will live: a tracker description, a document, a wiki page. Click into that field so it has focus, and confirm it is a compatible Windows text field by trying a short test phrase.
2. Turn off automatic Enter or send behavior. If SpeakLingo offers an option to press Enter after delivering text, switch it off for this task. In some apps, Enter submits a comment or posts a message, and you want the draft to sit unsent until you have read it.
3. Check consent and access. Make sure the online service is enabled and you have agreed to its use. Decide whether optional screen context stays off. If the screen shows anything confidential, leave it off.
4. Gather your sources. Have the ticket IDs, analytics you have pulled, and your own notes open so you can verify the draft afterward.
5. Review before sending. Read the draft in the field, compare it with your sources, and only then save, post, or share it.

One boundary matters before you start: to get an AI-structured draft, use the supported AI Task workflow and put the instruction and the facts the AI needs in the same spoken request. Dictating on its own does not turn AI on. Earlier dictations, text already in the field, and whatever is on your screen are not automatically available to the AI. Screen context is a separate opt-in, and it may be sent to remote services. If you leave a fact out of the request, the draft cannot reliably contain it, so say the problem, evidence, expected behavior and open question as part of the request. Transcription has its own mode, setup and access requirements. If AI is unavailable, that does not show transcription is available, and the reverse also holds.

The field set for this note is small: user problem, evidence, expected behavior, open question. Each has a job.

User problem. One or two sentences on who is affected and what they cannot do or understand. Keep solutions out of this field. If you catch yourself saying "we should add a button," step back and ask what the user is trying to accomplish.

Evidence. The facts you can point to: ticket references, quotes on record, analytics you have pulled, observations you made yourself. If you have no evidence for a claim, say so aloud. "I have no usage data on this" is a useful input because it gives the AI an explicit gap to flag.

Expected behavior. What should be true once the issue is resolved, stated from the user's or the system's point of view, and observable. "The manager can duplicate a week's pattern while excluding an employee on leave" is observable. "The experience feels smoother" is not.

Open question. What you do not yet know, and who might know it. Open questions are part of a requirement note's value because they show reviewers where to push.

Notice what is absent: release dates, priority rankings, effort estimates, and customer research you have not conducted. The review boundary for this workflow is that the draft contains no invented user research and no release commitments. If those matter, add them yourself afterward from real sources.

The following example is fictional and only shows the shape of the workflow. The product, tickets, and details are invented, and the draft shown is illustrative, not observed output from a real session. Actual output will vary and always needs review.

Scenario: A product manager at a fictional shift-scheduling tool called "Rotawise" wants to turn a recurring complaint into a note for the engineering lead.

Before: the spoken inputs

The product manager speaks the inputs as a loose stream:

"Managers keep running into trouble when they copy last week's schedule and somebody's on leave, because the copy brings the person's shifts across anyway and then they have to delete them by hand. Tickets ST-101, ST-107 and ST-112 mention it, all from the last few weeks. I haven't talked to any of the managers directly. What I'd want is that when you copy a week, you can pick people to leave out, or it skips anyone with approved leave. I don't know if approved leave data is available to the copy function or if it lives somewhere else. Also not sure if this affects all customers or just ones using the leave module."

Transcribed as it stands, this is usable but loose. Evidence and opinion are tangled, and nothing is labeled.

The request

The product manager speaks this stream together with the task instruction (see "The spoken request to use" below) as one AI Task request, because the AI can only work from the facts the request supplies. The instruction asks the AI to structure the four inputs and to flag missing facts rather than fill them.

After: the illustrative draft at the cursor, before review

Issue-to-requirement note: Copying a schedule week when staff are on leave

User problem Managers who copy a previous week's schedule must manually delete shifts for employees who are on leave, because the copy carries those shifts across.

Evidence - Support tickets ST-101, ST-107 and ST-112 reference this behavior (described by the author as from the last few weeks). - The author has not spoken to managers directly.

Expected behavior When copying a week, the manager can either (a) choose employees to exclude, or (b) have the system skip employees with approved leave. The preferred option is not yet decided.

Open questions 1. Is approved-leave data accessible to the copy function, or stored elsewhere? 2. Does the issue affect all customers or only those using the leave module?

Missing facts flagged - Number of affected customers: not provided. - Frequency and impact of the manual deletion: not provided. - Priority and release timing: not provided. No commitment is made in this note.

The review pass

The product manager reads the draft against the spoken inputs and the tickets themselves. Suppose the review turns up two things.

First, the timing of the tickets came from memory ("last few weeks") and is unverified. The PM opens the tickets, confirms the dates, and writes them into the evidence line.

Second, "The preferred option is not yet decided" is accurate but leaves the decision with no owner. The PM adds "Owner for question 1: engineering lead, to confirm" and a line saying who will choose between options (a) and (b).

Only then does the PM save the note in the tracker. The structure came from the request, and the accuracy came from the human check.

Use this skeleton as the shape you ask for. Adjust the headings to match your team's own conventions.

Title: [Short description of the issue]

User problem [Who is affected, what they cannot do or understand.]

Evidence - [Source reference: what it shows] - [Source reference: what it shows] - Evidence gaps: [what you have not checked or gathered]

Expected behavior [Observable outcome once resolved. Note alternatives if undecided.]

Open questions 1. [Question] (owner: [name or role], needed by: [if known]) 2. [Question]

Missing facts flagged - [Fact the draft could not state because it was not supplied]

Out of scope for this note - Priority, release timing, and effort estimates unless supplied and verified.

The "Evidence gaps" and "Missing facts flagged" lines are the safeguards. They give gaps a visible place, which keeps the draft honest.

Using the supported AI Task workflow, speak a single request along these lines, replacing the bracketed part with your actual inputs so the instruction and the facts travel together:

"Using only these verified inputs, draft an issue-to-requirement note. Inputs: [user problem, evidence, expected behavior, open question]. Use a clear professional structure. Flag missing facts; do not invent them."

Add your team's heading names if you want them matched. If you speak a language other than English, choose a supported language you are comfortable reviewing in. Online transcription covers 99+ languages, but that statement concerns transcription only. It does not mean the tool translates, and it does not guarantee AI output in every language. Check that the draft arrives in the language you expect before relying on it.

Run these checks before the note leaves your hands. They are illustrative writing practices, not a standard or professional advice, so adapt them to your team's own conventions.

Fidelity to inputs - Every statement traces to something you said or a source you can open. - No quotes, user names, or "customers say" statements appear that you did not supply. - Numbers, ticket IDs, and dates match the sources exactly. - Hedges survive. If you said "I think," the draft does not say "we know."

Boundaries - No user research is implied that you have not done. "Managers report" appears only if managers reported it to a source you can cite. - No release timing, commitments, or priority statements appear unless you deliberately added them. - Options are not presented as decisions.

Quality of the requirement - The user problem describes the problem and leaves the preferred solution out. - Expected behavior is observable and testable. - Each open question has a plausible owner. - The scope is clear enough that someone could disagree with it.

Sensitivity - Nothing confidential was spoken or visible on screen that your organization would not want processed by a remote service. - The note is going to the right audience and place.

Final decision - You would be comfortable defending every line when colleagues question it.

Whether this workflow helps is a question for your own work. A useful measure is time to reviewed output: the time from starting to assemble inputs until you hold a note you have checked and consider ready to share.

To track it fairly:

1. Define start and end. Start when you begin gathering or speaking inputs. End when the reviewed note is in its destination and the checklist is cleared. Do not stop the clock at first draft, because an unreviewed draft is unfinished work.
2. Include the full path. Count corrections, source-checking, and gap-filling. Drafts that need heavy rework should show up as such.
3. Compare like with like. Record several notes written your usual way and several written with this workflow, for issues of similar complexity. A one-line bug and a cross-team requirement are not comparable.
4. Record context. Note whether the issue was familiar, how many sources it had, and whether connectivity or compatibility caused delays.
5. Log your edits. A short list of what you changed in review (facts corrected, invented lines removed, structure adjusted) shows where you need better inputs or a better request.
6. Allow a fair trial. A handful of notes will tell you more than one attempt.

Your own measurements are the only ones that describe your situation, so treat any figure from elsewhere with caution.

Compatibility. Test the workflow in the exact field where you want the text, well before a deadline. A note you cannot place in your tracker costs you the effort of moving it elsewhere.

Missing prerequisites. If connectivity, the enabled service, consent, or access is missing, write the note by hand using the template above.

Confidentiality. Because audio, text, and optional screen context may be processed remotely, keep sensitive customer details out of what you say, and leave screen context off when the screen shows material you would not share.

Spoken habits. Speak ticket IDs slowly. State negatives explicitly ("I have not spoken to any managers"). Say "unknown" when you do not know. These habits hand the AI explicit gaps to flag, which makes missing facts easier to see in review.