SideNote Pro workflows for product managers

Find ambiguity before engineering does

The most valuable prompt in product work is not *improve this*, it is *where could this be read two ways*. You are close enough to your own requirements that you cannot see the gaps; a model reading them cold can.

Select a requirement and use a custom action: *Review these acceptance criteria. Identify ambiguity, unstated assumptions, and the questions engineering is likely to ask: {{selection}}*.

The output to act on is the questions list. Every question a model asks is a question a developer would have asked in a fortnight, when it costs more to answer. Answer them in the document now.

• *Rewrite this requirement as acceptance criteria in Given/When/Then form. Flag anything too vague to test.*
• *What edge cases does this not address?*
• *Which of these requirements could conflict with each other?*
• *What would a developer need to decide themselves because this does not say?*

Compare proposals and specifications

Attach up to five documents at once. Comparison is where this earns its keep, because reading three vendor responses against a requirements list is exactly the work that gets deferred.

• *Compare these two proposals on scope, timeline, cost and assumptions. Table first, then note anything present in one and absent from the other.*
• *Which requirements in this document are not addressed by this proposal?*
• *Extract every commitment as a table: what, who, and the stated date. Mark any where the owner or date is missing.*
• *Read this specification as the engineer who has to build it. Where could two developers implement different things?*

Name the documents in the prompt rather than saying *these*. It keeps follow-up questions unambiguous once the conversation has scrolled.

Query your product documentation

Index the folder holding your specifications, research and decision records. Then ask the questions that are tedious precisely because the answer is spread across a dozen documents.

• *Which requirements mention offline behaviour?*
• *What did we decide about data retention, and where is that written down?*
• *Find every reference to the pricing assumptions and summarize the differences.*
• *Has anyone documented why we rejected the alternative approach?*

The Sources list matters here more than most places: it tells you which document said it, which is usually the thing you needed so you can go and check whether it is still true.

Screenshots for UX review

Capture a screen and ask for a specific lens rather than a general opinion. *Review this screen for usability problems, focusing on whether a first-time user could work out what to do next* gets you a review. *What do you think of this design* gets you an inventory of the elements.

• *What is this screen asking the user to decide, and does it give them enough to decide it?*
• *Where would a user most likely get stuck here?*
• *What is the visual hierarchy telling the user to look at first, and is that right?*
• *Which of these labels could be misread?*

Writing for different audiences

The same update goes to engineering, to leadership and to customers, and it should not be the same text. Selected-text actions make the translation a keystroke.

• *Rewrite this for an executive audience. Lead with the decision needed, under 100 words: {{selection}}*
• *Rewrite this for the engineering team. Keep the technical constraints, drop the business framing: {{selection}}*
• *Rewrite this for a customer-facing release note. No internal terminology: {{selection}}*

Save these as custom actions once they are refined. That is where the time saving compounds. See AI actions on selected text.