Turning a Feature Idea Into a PRD in Word With Copilot
A feature idea usually arrives as a rough paragraph, not a spec. Here's the actual note a support lead forwarded to product last Tuesday: "customers keep asking if two stylists can swap shifts without calling the manager every time. I think it's a bigger deal than it sounds, our biggest complaint this month was a stylist who lost a shift because her swap request got lost in a group text. Not sure if this is a quick toggle or a whole workflow, but people keep asking." Turning a paragraph like that into a PRD someone can actually build from is where most of a product manager's Tuesday goes, and it's also exactly the kind of structured, multi-section document Copilot's agent mode in Word can build directly, rather than handing you a generic draft you end up rewriting section by section. If you're new to Copilot generally, the Complete Beginner's Guide to Copilot is worth reading first.
The failure mode with AI-drafted PRDs isn't bad writing, it's a document that sounds complete but skips the decisions a real PRD forces you to make: what's explicitly out of scope, what happens in the edge cases, how you'll know if it worked. A prompt sequence that asks for those things directly, in order, produces something closer to a real spec than one giant "write me a PRD for this feature" request ever will.
The example: shift swaps for Rosterly
Rosterly is a scheduling tool for restaurant and retail shift work, and that support note above is the actual input this PRD gets built from. The feature request buried inside it: let an employee swap an assigned shift with a coworker without a manager doing it manually in the schedule each time. Here's how a paragraph like that becomes a PRD.
- 1
State the problem before the solution
Get Copilot to write the problem statement and background first, without describing the feature yet. This forces the "why" to exist independently of the "what," which matters later when engineering asks whether a simpler solution would solve the same problem.
- 2
Define scope and, just as important, non-scope
Ask explicitly for what the feature will not do in this version. This is the section people skip when writing a PRD by hand under time pressure, and it's the section that prevents the most scope creep during a build.
- 3
Write user stories from the actual roles involved
Not one generic "as a user" story, but one per role that actually touches this feature: the employee requesting the swap, the coworker accepting it, the manager who can still override it.
- 4
Get requirements and edge cases as a working list
Ask for functional requirements and edge cases together, since a well-written edge case often reveals a missing requirement.
- 5
End with success metrics and open questions
A PRD without a way to measure whether the feature worked isn't finished, and a PRD with no open questions almost always means the questions weren't asked out loud.
The opening prompt, giving agent mode enough to start building the document structure directly rather than one flat block of text:
I'm writing a PRD for a shift-swap feature in Rosterly, a scheduling app for restaurant and retail shift work. Start a new document with a PRD structure: title, problem statement, background, goals, non-goals, user stories, functional requirements, edge cases, success metrics, and open questions, as section headings. For now, only write the problem statement and background. The problem: employees currently have to call or text their manager to swap an assigned shift with a coworker, and the manager has to manually edit the schedule for both people. Managers report this is their most frequent interruption during work hours, and employees report shifts sometimes don't get updated correctly, leading to a no-show that looks like the employee's fault when it was actually a missed schedule edit.
”That's a real, specific problem statement input: a named frustration for the manager (interruption during work hours) and a named consequence for the employee (an unfair no-show). Once that section reads correctly, move to scope.
Now write the goals and non-goals sections. Goals: employees can request and confirm a shift swap with a coworker without manager involvement for same-role, same-location swaps. The schedule updates automatically for both people the moment the swap is confirmed. Non-goals for this version: no cross-location swaps, no swaps that change total scheduled hours in a way that affects overtime eligibility (route those to a manager approval instead), and no swap marketplace where any employee can post an open shift to anyone, only direct one-to-one requests to a specific coworker.
”Tip
Notice the non-goals aren't just "we won't build X." Each one names why: the overtime one exists because letting employees freely swap hours could create unplanned overtime costs nobody signed off on. A non-goal with a reason attached survives an engineering review much better than a bare exclusion, because it answers the "why not?" before someone asks it in a meeting.
Getting requirements and edge cases without a generic list
This is where a flat "write the requirements" prompt produces the least useful output, a list that could belong to almost any two-sided approval feature. Naming the actual roles and asking for edge cases in the same breath gets something closer to what engineering needs.
Write the user stories section with three stories: the employee requesting a swap, the coworker being asked to accept it, and the manager who can view or override any swap after the fact. Then write functional requirements and edge cases together as a single list, and for each edge case, name which requirement above needs to account for it. Specific edge cases to cover: what happens if the coworker doesn't respond within 24 hours, what happens if both employees are qualified for the shift's role but one is currently in overtime territory for the week, and what happens if a manager overrides a swap after it's already been confirmed by both employees.
”That last instruction, naming which requirement accounts for each edge case, is the part that turns a list of hypotheticals into something a spec actually needs: a forcing function that catches gaps. If Copilot can't tie an edge case back to an existing requirement, that's the signal a requirement is genuinely missing, not a prompting failure.
Where you still have to make the call
Copilot can draft a plausible answer to "what happens if the coworker doesn't respond within 24 hours." It can't decide whether 24 hours is the right window for your business, whether the swap should auto-expire or escalate to the manager, or whether that decision differs for a restaurant that schedules a week out versus one that schedules the same day. Those are product decisions. Draft the options, then make the call yourself and have Copilot write the resulting requirement in the document.
Closing it out
Finish the document with success metrics and open questions. Success metrics should be measurable within 60 days of launch, not vague statements like "improved employee satisfaction." Open questions should be genuine unresolved decisions, not restated requirements.
”A good result here names something like "percentage of swap requests resolved without manager involvement" and "average time from request to confirmation," both of which are things Rosterly's own usage data can actually answer 60 days after launch. A weak result says something like "increase in employee happiness," which nobody can measure and nobody will bother tracking.
Read the open questions section closely before sharing the document. It's the part most likely to contain something Copilot genuinely doesn't have enough information to resolve, like whether the 24-hour response window should be configurable per business or fixed platform-wide. Answer what you can, and leave the rest visibly open rather than letting the document quietly paper over an unresolved decision with confident-sounding prose.
From a forwarded complaint to a finished document
It's worth seeing the whole arc in one place: a rough support note in, a structured spec out. Here's a representative excerpt of what the finished Rosterly PRD looks like after all five prompts above have been answered and compiled.
Word
Excerpt of the finished PRD, illustrated, not a real screenshot
| Section | Content |
|---|---|
| Problem Statement | Managers lose work time to manual shift-swap edits and inconsistent tracking causes wrongful no-shows |
| Goals | Employees can request and confirm a same-role, same-location swap without manager involvement |
| Non-Goals | No cross-location swaps; overtime-affecting swaps route to manager approval; no open marketplace, direct requests only |
| User Stories | Employee requesting a swap, coworker accepting it, manager overriding after the fact |
| Requirements and Edge Cases | Swap auto-expires after 24 hours with no response, routed to the requirement covering pending-request timeouts |
| Success Metrics | Percentage of swap requests resolved without manager involvement, measured 60 days post-launch |
| Open Questions | Should the 24-hour response window be configurable per business or fixed platform-wide |
Why this worked: nothing in that table is a restatement of the original complaint, it's a set of decisions the complaint didn't contain on its own, like the overtime carve-out and the 24-hour default. Each one only exists because a prompt asked for it explicitly, in its own section, rather than trusting one broad request to surface it unprompted.
The natural next move isn't to ship this document as final. It's to send the requirements and edge cases table to an engineering lead for a rough sizing estimate before it goes into sprint planning, specifically because that's the section most likely to reveal a requirement that sounds simple in a PRD and isn't in the schedule's actual data model.
Write the problem statement before describing any solution
Give non-goals a reason each, not just a bare exclusion
Write user stories per actual role, not one generic user story
Tie every edge case back to a specific requirement
Make metrics measurable within a specific window, not a vague sentiment
Leave genuinely open questions open instead of smoothing over them
Official sources
Checked on September 21, 2026. Features, plans and names change often, so the vendor's own pages are the final word.