Department Contributor Guide

Department Contributor Guide

As a department contributor, your role is to represent your team's requirements in a project's specification. You do this through a survey — a structured form that shows you the project's current plan and asks for your input.

This guide covers everything from receiving the survey invitation to participating in conflict resolution.

Receiving a Survey

When a project lead opens surveys for a project, you'll be notified in one of two ways:

• In-app notification — if you have a SpecGraph account, a notification appears in the Notifications panel.
• Survey link by email — the project lead may share your survey link directly. Public surveys don't require a SpecGraph account to complete.

Your survey link is unique to your department for this project. Only share it with colleagues in your department who should contribute input.

Completing Your Survey

Step 1: Read the PRD

Open your survey link. Before you answer anything, read the Product Requirements Document shown at the top. This is the AI-generated draft of what's being built. Take time to understand:

• What problem is this project solving?
• Who are the users?
• What features are planned?
• What's explicitly out of scope?

Reading the PRD is not optional — your wishes need to be grounded in the context of what's being built. The PRD will not be perfect, and that's expected. Your job is to tell the team what's missing, what's wrong, and what your department needs.

Step 2: Answer Guided Questions

For each section of the PRD, you'll see guided questions designed to surface requirements specific to your department's perspective. For example:

• "Are there any regulatory or compliance requirements your department needs to satisfy in this area?"
• "What performance expectations does your team have for this feature?"
• "Are there any existing systems or data sources this must integrate with?"

Answer each question as specifically as you can. These answers are automatically converted into wishes when you submit the survey. Specific, detailed answers produce actionable wishes. Vague answers produce vague wishes that are hard to act on.

Step 3: Add Free-Form Wishes

If you have requirements that the guided questions didn't cover, add them as free-form wishes using the Add Wish button. Each wish needs:

Title — a short, action-oriented summary. Good: "Require MFA for admin users." Bad: "Security stuff."

Description — explain the requirement fully. Why does your department need this? What happens if it's not included? What would a good implementation look like?

Type — choose the one that best describes this wish:

• Feature Request — a new capability you want.
• Enhancement — an improvement to something already in the PRD.
• Concern — a risk, constraint, or objection your team has.
• Question — a clarification you need before you can finalize your requirements.

Priority — be honest about this:

• Critical — your department cannot accept the product without this.
• High — strongly desired; you'd push back hard if it's excluded.
• Medium — beneficial but negotiable.
• Low — nice to have; wouldn't block your sign-off.

Effort (optional) — your team's estimate of how hard this is to build. Small / Medium / Large / Extra Large.

Step 4: Review and Submit

Before submitting, review all the wishes you've created. Ask yourself:

• Have I covered all the requirements my department actually cares about?
• Are my descriptions clear enough for someone outside my team to act on?
• Are my priorities accurate — or have I marked everything Critical?

When you're satisfied, click Submit Survey. After submission, your survey is locked. Contact the project lead if you need to make changes after submitting.

Best Practices for Writing Wishes

Be specific. "We need GDPR compliance" is a starting point, not a requirement. "User data must be deletable on request within 30 days, with deletion confirmable via audit log, to satisfy GDPR Article 17" is an actionable wish.

One requirement per wish. If your department has five distinct requirements, submit five separate wishes. Bundling multiple requirements into one wish makes them impossible to discuss, vote on, or resolve individually.

Explain the why. A wish with a clear rationale is far more likely to be incorporated. "We need SSO support because our IT policy prohibits standalone passwords for SaaS tools" is more compelling than "We need SSO."

Don't under-prioritize to avoid conflict. If something is genuinely Critical for your department, mark it Critical. The conflict detection step exists precisely to surface and resolve these tensions — not to have them buried as Medium priority.

Participating in Conflict Resolution

After all surveys are submitted, the project lead runs AI conflict detection. If one of your wishes is involved in a conflict, you'll be notified.

Visit the Conflicts page of the project to see:

• Which of your wishes are involved in conflicts.
• What the conflict is and why it's a tension.
• The impact analysis — what each resolution path means for the PRD.

Your role in conflict resolution:

• Read the conflict description and impact analysis carefully.
• Post in the discussion thread to provide context your department didn't capture in the wish itself.
• Vote on resolution options to indicate which path your team supports.
• Be open to compromise — conflict resolution requires trade-offs.

You don't need to "win" every conflict. Your goal is to make sure your department's real concerns are heard, understood, and documented — even if a different resolution is ultimately chosen. The discussion thread and impact analysis ensure that decisions are made with full awareness of the trade-offs.

Voting on Other Departments' Wishes

From the Wishes page, you can vote on wishes submitted by other departments. Votes signal cross-department support for a requirement. If another department's wish aligns with your team's interests, vote for it — this strengthens its case during unification.

After Your Survey Is Submitted

Your primary involvement ends when you submit the survey and participate in relevant conflict discussions. You may also be asked to:

• Clarify a wish if the project lead needs more information.
• Re-review the unified PRD if your department is a required approver.
• Provide post-build feedback once the project is in production.