The form assumes PM vocabulary
Words like charter, deliverable, and workstream stop the person who actually understands the broken process.
Feature request intake
Software feature request intake template
A software feature request intake template collects the business problem, the people affected, and the outcome that would make the change worth doing. It does not ask a department manager to write a charter, a WBS, or a solution design. Use it as a prompt set—not as a substitute for the product that stores the request.
For department managers and the person closest to the problem—especially when nobody on staff is a full-time project manager.
A software feature request intake template asks for
- What is happening today, in everyday language
- Who is affected and what should be different
- An owner, timing, and known constraints—not a project plan
Most intake forms fail because they were written for project managers
A form that asks for scope, milestones, RAID logs, or a preferred architecture will sit unused—or get filled with a requested solution and a deadline. The organization then reconstructs the real problem in meetings. Teams without a PMO need a shorter template that a department manager can complete from what they already know.
The form asks for a solution too early
“What system do you want?” hides the problem. Reviewers cannot compare requests that start at different levels of invention.
Incomplete requests look like resistance
When people skip fields they do not understand, IT treats the request as low quality instead of poorly designed intake.
Feature Request Intake Method: Collect a Complete Story, Then Stop
The job of a software feature request intake template is not to plan the project. It is to make the request reviewable. Everything else—discovery questions, estimates, priority, and delivery planning—comes after someone can understand the problem without a meeting.
This page is the copy-ready prompt set. When the story needs to travel into review without a shared doc, use software project intake so the same record reaches the next step.
A complete template is not a plan. After the story is understandable, requirements gathering software turns it into reviewed answers instead of a kickoff that invents tasks.
If reviewers cannot see what is missing, a spreadsheet will stall. Run the prompts in software project intake so completeness is visible without a project manager rewriting the request.
- 1
Start with the current situation
Ask what happens today, including handoffs and tools, in the requestor’s own words.
A good answer names the process, not the hoped-for product. “We schedule volunteers in email and a shared spreadsheet” is intake. “We need an app” is a solution looking for a problem.
- 2
Name the people and the pain
Who is affected, what extra work or risk this causes, and what happens if nothing changes.
Include employees, customers, volunteers, partners, or reviewers. Pain can be time, errors, cost, compliance exposure, or people giving up. If the requestor cannot name who hurts, the request is not ready.
- 3
Describe the better result, not the build
Ask what should be different when the change works. Allow “I am not sure how” as a valid answer.
The desired future is an outcome: fewer days to run an event, fewer duplicate records, a supervisor who can see open requests. Implementation choices wait until requirements and estimates exist.
- 4
Attach an owner, timing, and constraints
Someone must be reachable, and any hard dates or limits should be visible.
Owner means a business person who can answer follow-up questions—not a project manager. Timing is a window or a reason, not a fake go-live. Constraints include policy, vendors, systems that cannot change, or busy seasons.
- 5
Review for completeness, not polish
A reviewer checks whether the story can be understood, not whether it sounds like a PMO document.
Ready enough means: problem, people, outcome, owner, and known limits are present. Missing solution design is expected. Missing who is affected is not.
Practical template
Copy-ready software feature request intake template
Copy these prompts into a form, a shared doc, or the first screen in a workflow. Leave any answer as “unknown” rather than inventing one. The examples are fictional.
| Prompt | Why it is here | What a complete answer looks like |
|---|---|---|
| What is happening today? | Gives reviewers the current process without requiring a process map. | Tournament staff plan events over three days and reserve facilities by email and a spreadsheet. |
| Who is affected? | Shows the real audience before anyone sizes a solution. | Tournament staff, volunteers, students, parents, and facility coordinators. |
| What problems does this cause? | Separates inconvenience from cost, risk, or lost capacity. | Facilities are hard to reserve, volunteers give up three days, and event costs stay high. |
| What should be different when this works? | Defines the outcome without locking a vendor or architecture. | Staff can run the same event in two days with less facility and volunteer time. |
| What change do you think is needed? | Captures a hunch without requiring a design. “Not sure yet” is acceptable. | Add a two-day tournament option while keeping the three-day option. Or: I am not sure yet. |
| How will you know it worked? | Gives later estimates and approval something to test against. | Average event setup drops from three days to two, with fewer last-minute facility changes. |
| Who owns this request? | Someone must answer follow-up questions. This is not a project-manager field. | Jordan Lee, operations manager, can speak for the department. |
| What timing or constraints matter? | Surfaces busy seasons, policies, vendors, and systems that cannot move. | Cannot launch during fall registration. Existing payment vendor must stay in place. |
Worked example
What “done enough” looks like without a project manager
A volunteer coordinator can complete this template in one sitting. A reviewer can decide whether the request is ready for discovery without translating it into PM artifacts.
| Check | What we recorded |
|---|---|
| Requestor | Volunteer coordinator who runs seasonal events |
| What they know | Today’s process, who struggles, and the outcome they need |
| What they do not write | Epics, milestones, RAID logs, or a recommended stack |
| Reviewer check | Problem, people, outcome, owner, and constraints are present |
| Next step if complete | Guided discovery questions—not a kickoff that invents tasks |
| Next step if incomplete | Return the two missing answers instead of scheduling another meeting |
The template succeeds when a reviewer can understand the request without the requestor in the room. That is the substitute for a project manager at intake—not a thinner charter.
What a PM form asks vs. what a non-PM template collects
| PM-style form | Non-PM intake template |
|---|---|
| Charter, milestones, WBS, and a RAID log | What is happening today, in everyday language |
| Preferred vendor, architecture, or workstreams | Who is affected and what should be different |
| A project plan the requestor cannot honestly write | A reachable owner, timing, and known constraints |
| A “complete” PMO packet before anyone understands the problem | A reviewable story—then stop. Planning comes after. |
What to leave off a non-PM intake form
Asking for a project plan
Dates, phases, and resource plans belong after discovery and estimates. Asking for them at intake produces fiction.
Requiring a preferred vendor or system
Capture constraints (“must keep the payment vendor”). Do not force a solution name when the problem is still being understood.
Making every field mandatory
Unknown is a valid answer. Forcing a guess creates false confidence and trains people to invent scope.
Using the form as a ticket dump
Broken-now issues and small fixes need a different path. A project intake template is for work that still needs a decision.
In Precision Foundry
How Precision Foundry runs this template for people who are not PMs
Precision Foundry is built for the person who knows the job, not the person who knows project-management language. The prompts on this page are the template. The product stores the same story so reviewers see whether the request is complete enough to continue.
- Requestors describe the problem in everyday words and can save a draft
- The story, owner, value, and constraints stay on one record
- Initial review checks completeness before anyone estimates
- Discovery, dual estimates, and approval come after the story is understandable
Common questions
Questions about feature request intake
What should a software feature request intake template include?+
Ask for the current situation, who is affected, the problems it causes, the desired outcome, any solution idea (including “not sure”), how success will be recognized, a business owner, and known timing or constraints. Do not ask a department manager for a charter, work breakdown, or technical design.
What should a project intake template include if we have no project managers?+
The same fields. A software feature request intake template for teams without project managers is a prompt set the person closest to the work can complete. It is not a thinner charter, and it is not a ticket dump.
Who should submit the intake if there is no PMO?+
The person closest to the business problem. They do not need project-management training. A reviewer or IT partner can add context later. The owner field exists so follow-up questions have a name.
How do we review intake without a project manager?+
Check whether a stranger to the request can understand the problem, the people, the outcome, the owner, and the hard limits. If those are present, the request can move to discovery. If they are not, send back the missing answers instead of holding a kickoff.
Is a shared document enough, or do we need intake software?+
A shared document can hold the prompts. Software helps when requests scatter across email, when reviewers cannot see what is missing, and when the story needs to travel into discovery, estimates, and approval without being rewritten.
Try Software feature request intake template on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Join the private alpha waitlist