How do we handle users who do not have internet access?

Design the digital product as one channel, not the only channel. Maintain paper and in-person application paths. Use the [product discovery process](/discovery-guide) to understand what percentage of your population is online vs. offline, and design the digital channel to reduce load on in-person staff so they can spend more time with residents who need face-to-face help.

What Authority to Operate (ATO) do we need, and how long does it take?

ATO requirements depend on the agency and data classification. Federal systems follow FedRAMP; state systems vary. Plan for 3-6 months for a new ATO. Start the security documentation (System Security Plan, risk assessment) in parallel with development, not after. Your agency's CISO office can provide the specific framework and timeline.

How do we test with actual residents without violating privacy rules?

Use synthetic test data for integration and load testing. For usability testing with real residents, work with your agency's legal and IRB teams to establish consent protocols. Many agencies have community advisory boards that can provide feedback. Test with community-based organizations that serve your target population. Use the [RICE Calculator](/tools/rice-calculator) to prioritize which user flows need the most testing investment.

How do we manage the tension between government procurement timelines and agile delivery?

Structure contracts around outcomes and user metrics, not feature lists. Use modular contracting (smaller, shorter contracts for different components) where procurement rules allow. Deliver working software every 2-4 weeks internally, even if formal deliverable reviews happen quarterly. Track delivery velocity so you can show the contracting officer concrete progress at each checkpoint.

What happens when policy changes mid-development?

Policy changes are inevitable in government work. Build configuration-driven eligibility rules rather than hardcoding business logic. Maintain a policy change log in the spec and assess each change for scope, timeline, and budget impact before agreeing to absorb it. Use a [prioritization framework](/frameworks/rice-framework) to evaluate policy-driven feature requests against existing commitments. ---

Civic Technology Product Specification Template

What This Template Is For

Civic technology products serve the public, which means the stakes are different from commercial software. A bug in a benefits portal is not a retention metric problem. It is a person who cannot feed their family this week. Civic tech PMs must balance government procurement rules, accessibility mandates, multilingual requirements, and the reality that their users often have no alternative.

This template provides a structured specification format for products that serve government agencies or the public directly. It is designed for teams at civic tech organizations (Code for America, Nava PBC, USDS alumni, state digital services), government IT departments, and contractors building public-facing systems. Pair this with a product roadmap to sequence delivery across procurement cycles.

How to Use This Template

Start with the Public Service Context section. Identify the specific government program, policy mandate, or public need your product addresses.
Define your user segments carefully. Civic tech users span residents, caseworkers, administrators, and oversight bodies. Each has different access patterns, literacy levels, and device constraints.
Fill in the compliance and accessibility requirements early. These are not optional features. They are launch blockers.
Map integration requirements to existing government systems (legacy databases, identity providers, payment systems).
Review with both technical and program stakeholders. In civic tech, the policy team is as important as the engineering team.
Update the spec as policy or regulatory context changes. Government programs evolve, and your spec should track those changes.

The Template

Product Overview

Field	Details
Product Name	[Name]
Sponsoring Agency/Organization	[Agency or civic tech org]
Program/Policy Context	[Government program this product supports]
Product Owner	[Name and role]
Technical Lead	[Name]
Policy/Program Lead	[Name]
Target Launch	[Date or procurement cycle]

Mission statement. [One sentence: who this product serves and what public outcome it enables.]

Public Service Context

☐ Identify the government program, statute, or policy mandate this product supports
☐ Describe the current process (paper forms, legacy systems, in-person visits)
☐ Quantify the population affected (applicants per year, residents served, cases processed)
☐ List the pain points in the current process for both residents and staff
☐ Note any legislative deadlines or policy changes driving the timeline

User Segments

Segment	Description	Access Patterns	Key Needs
Residents/Applicants	[Who they are]	[Mobile-first, low bandwidth, shared devices]	[Simple forms, status tracking, multilingual]
Caseworkers/Staff	[Who they are]	[Desktop, government network, VPN]	[Bulk processing, search, case notes]
Administrators	[Who they are]	[Desktop, limited tech literacy]	[Reports, dashboards, configuration]
Oversight/Auditors	[Who they are]	[Periodic access, read-only]	[Audit trails, compliance reports]

Equity and Accessibility Requirements

☐ Define language support requirements (top languages by population served)
☐ Specify WCAG 2.1 AA compliance as minimum (AAA for critical flows)
☐ Plan for screen reader compatibility (JAWS, NVDA, VoiceOver)
☐ Design for low-bandwidth connections (target <500KB initial page load)
☐ Support older devices and browsers (define minimum supported versions)
☐ Address digital literacy gaps (plain language, progressive disclosure, help text)
☐ Plan for offline or intermittent connectivity scenarios
☐ Consider assistive technology for cognitive disabilities

Functional Requirements

ID	Requirement	Priority	User Segment	Compliance Link
FR-1	[System shall...]	P0	[Residents]	[508/WCAG/Policy]
FR-2	[System shall...]	P0	[Caseworkers]
FR-3	[System shall...]	P1	[Administrators]
FR-4	[System shall...]	P1	[Residents]	[Language access]
FR-5	[System shall...]	P2	[Auditors]	[Audit requirement]

Government System Integrations

System	Type	Direction	Protocol	Owner
[Identity provider (Login.gov, state SSO)]	Authentication	Inbound	[SAML/OIDC]	[Team]
[Legacy database]	Data source	Bi-directional	[API/batch file]	[Team]
[Payment system]	Transaction	Outbound	[API]	[Team]
[Notification service (GovDelivery)]	Communication	Outbound	[API]	[Team]

Security and Privacy

☐ Classify data sensitivity level (PII, PHI, tax data, law enforcement)
☐ Define data retention and deletion policies per records management schedule
☐ Specify encryption requirements (at rest, in transit, field-level for sensitive data)
☐ Document Authority to Operate (ATO) requirements and timeline
☐ Plan for penetration testing and security assessment schedule
☐ Define incident response procedures for data breaches

Performance Requirements

Metric	Target	Rationale
Page load (3G connection)	< 3 seconds	Many users on mobile with limited data plans
Form submission response	< 2 seconds	Reduce abandonment in multi-step applications
Concurrent users	[Number]	Based on peak filing/enrollment periods
Uptime	99.9%	Public services cannot have extended downtime
Planned maintenance windows	[Schedule]	Must avoid peak usage periods

Testing and Launch Plan

☐ Define user acceptance testing (UAT) plan with actual caseworkers and residents
☐ Schedule accessibility audit with external assessors
☐ Plan for load testing at 2x expected peak volume
☐ Define rollback procedures
☐ Create communication plan for agency staff, partner organizations, and the public
☐ Plan phased rollout (pilot county/region before statewide launch)

Open Questions

#	Question	Owner	Status
1	[Unresolved question]	[Name]	Open
2	[Unresolved question]	[Name]	Open
3	[Unresolved question]	[Name]	Open

Filled Example: Benefits Application Portal

Product Overview

Field	Details
Product Name	CalBenefits Online Application
Sponsoring Agency	California Department of Social Services
Program Context	CalFresh (SNAP) and Medi-Cal enrollment
Product Owner	Lisa Tran, Digital Services PM
Technical Lead	Carlos Rivera
Policy Lead	Priya Mehta, CalFresh Program Analyst
Target Launch	Pilot in Alameda County, Q3 2026

Mission statement. Enable California residents to apply for CalFresh and Medi-Cal benefits through a single, mobile-friendly online application that reduces processing time from 30 days to under 10.

Equity and Accessibility

Support English, Spanish, Chinese (Simplified), Vietnamese, Korean, Tagalog (top 6 languages by CalFresh applicant population)
WCAG 2.1 AA compliance for all pages; AAA for the application form flow
Target initial page load under 400KB for 3G compatibility
Support Chrome 90+, Safari 14+, Samsung Internet 15+ (based on analytics from existing CalFresh portal)
All form fields include plain-language help text at a 6th-grade reading level

Government System Integrations

System	Type	Direction	Protocol
Login.gov	Authentication	Inbound	OIDC
CalSAWS (legacy eligibility)	Eligibility check	Bi-directional	HL7 FHIR + batch fallback
EBT payment system	Benefit issuance	Outbound	SFTP batch (nightly)
GovDelivery	Application status notifications	Outbound	REST API

Key Takeaways

Civic tech users often have no alternative. Reliability, accessibility, and language support are launch blockers, not nice-to-haves
Map every feature to a specific government program requirement or resident need
Start security and ATO documentation in parallel with development
Design for the lowest-resource user: slow connections, old devices, limited digital literacy
Build for policy change by keeping business rules configurable, not hardcoded

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Civic Technology Product Specification Template