CRM Feature Spec Template for Product Managers

Use a JSON column for simple implementations or an EAV (Entity-Attribute-Value) pattern for more complex needs. JSON is simpler to query with modern databases (PostgreSQL JSONB, for example) and works well up to ~50 custom fields per object. EAV scales better for hundreds of custom fields but is harder to query and report on. Whichever approach you choose, support text, number, date, boolean, single-select, multi-select, and lookup (reference to another object) field types.

Most effective pipelines have 5-7 stages. Fewer than 4 stages lack the granularity to identify where deals stall. More than 8 stages create friction for reps and reduce adoption. Each stage should represent a meaningful buyer commitment. If two stages have the same win probability and the same required actions, merge them.

Build data quality into the workflow, not after the fact. Required fields at stage transitions force data entry at the moment it matters. Duplicate detection on contact creation prevents the database from degrading. Automated enrichment (Clearbit, ZoomInfo) fills firmographic data so reps do not have to. Run a weekly data quality report that flags contacts without email, deals without close dates, and companies without industry classification.

Make it required but allow estimates. A pipeline without deal amounts is useless for forecasting. Set the field as required when a deal enters the "Qualified" stage with a label like "Estimated value" and allow updates as the deal progresses. Track the accuracy of initial estimates vs. closed amounts to improve forecasting over time.

Start with "own + team" visibility as the default. Reps can see their own records and their team's records. Managers see their team's records plus rollup reports. Only give cross-team visibility to Rev Ops and Admin roles. Avoid overly restrictive permissions that prevent collaboration. The biggest adoption killer is a rep who cannot find a contact because it is "owned" by someone on another team.