Civic Technology Product Specification Template

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.

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.

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.

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.

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. ---