Com escriure un resum de producte d'una pàgina que es faci servir de debò
← Tots els articles Construir el correcte

Com escriure un resum de producte d'una pàgina que es faci servir de debò

Per l'equip de FabricLoop  ·  maig de 2026  ·  4 min de lectura

La majoria de resums de producte comparteixen el mateix destí: s'escriuen amb cura abans que comenci un projecte, es revisen una vegada en una reunió d'arrencada i no tornen a obrir-se mai més. Quan l'equip és a mig desenvolupament, el resum ja és un artefacte històric: de tant en tant se'l cita en discussions sobre l'abast, però gairebé mai es tracta com una guia viva per prendre decisions.

És un fracàs de procés, no de format. El resum no s'utilitza perquè no es va escriure per ser utilitzat. Es va escriure per complir un tràmit (marcar la casella «hem definit els requisits»), no per ajudar de debò l'equip a prendre millors decisions enmig de la incertesa.

Un resum que s'utilitza és curt, té criteri propi i s'estructura al voltant de les preguntes que l'equip es farà de debò a mig desenvolupament: què estem resolent, per a qui i com sabrem si ha funcionat?

«Un resum no és un document de requisits. És una referència per prendre decisions: una sola pàgina a la qual l'equip pot tornar sempre que dubti de si una decisió de disseny o d'abast és la correcta.»

Les cinc seccions que importen

Tot el que hi ha en un resum de producte ha de respondre una de cinc preguntes. Si una secció no respon cap d'aquestes preguntes, probablement no pertany a un resum d'una pàgina: pertany a una especificació a part, més detallada.

Resum de producte: preferències de notificació v2 Responsable: Priya S.  ·  maig de 2026
Problema
Els usuaris es perden actualitzacions importants perquè no poden distingir entre les notificacions de senyal alt (algú els ha assignat una tasca) i les de senyal baix (un comentari en un fil que segueixen). El resultat: o bé ignoren totes les notificacions, o bé les desactiven del tot. Els tiquets de suport del tipus «no ho sabia» representen el 18% de totes les queixes sobre el producte aquest trimestre.
Usuaris
Primaris: líders d'equip i responsables de projectes que reben mencions amb freqüència i no poden seguir el volum. Secundaris: col·laboradors individuals que volen silenci per defecte però necessiten no perdre's les assignacions crítiques. No ens adrecem als usuaris administradors: les seves necessitats de notificació es cobreixen amb el panell d'administració.
Mètrica d'èxit
Primària Els tiquets de suport relacionats amb notificacions baixen un 40% en els 60 dies següents al llançament.
Secundària El percentatge d'usuaris actius setmanals que han personalitzat les preferències passa del 12% al 35%.
Indicador avançat La taxa de desactivació (usuaris que desactiven totes les notificacions) baixa del 23% a menys del 15%.
Fora d'abast
  • Preferències de notificació per correu electrònic (tasca independent; infraestructura diferent)
  • Configuració de notificacions per espai de treball (futur; aquesta versió és només per usuari)
  • Programació de notificacions / hores de no molestar (necessitat validada, full de ruta del tercer trimestre)
  • Granularitat de les notificacions push al mòbil (primer web; mòbil més endavant, si es valida)
Preguntes obertes
Bloquejant Agrupem les notificacions en 2 nivells (crítiques / la resta) o permetem un control granular per tipus? Les entrevistes amb usuaris apunten a 2 nivells, però enginyeria prefereix el granular per flexibilitat. Cal una decisió abans que comenci el disseny.

No bloquejant Els canvis de preferències s'han d'aplicar retroactivament a les notificacions existents? Es pot decidir durant el desenvolupament segons el cost tècnic.

Per què «fora d'abast» és la secció més important

Els equips dediquen molt de temps a escriure què construiran. En dediquen molt poc a escriure què no construiran, i aquesta asimetria causa la major part de les ampliacions descontrolades de l'abast. Quan el dissenyador afegeix un interruptor d'«hores de silenci» perquè sembla obvi, o l'enginyer afegeix la configuració per espai de treball perquè ja és a la zona, normalment és perquè ningú va decidir explícitament que quedava fora d'abast.

Escriure els elements fora d'abast obliga a parlar dels límits, una conversa que d'altra manera tindria lloc a mig desenvolupament, quan canviar de rumb costa molt més. També dona al PM una base clara i documentada per dir que no a les addicions: «Vam decidir al resum que això quedava fora d'abast; aquí tens el perquè.»

Com escriure bons elements fora d'abast No et limitis a llistar què no construiràs: anota breument per què. «Preferències de correu (infraestructura separada)» indica al lector que la decisió va ser deliberada i raonada, no un descuit. Això evita que la mateixa qüestió d'abast ressorgeixi tres vegades durant el sprint.

Preguntes obertes: la secció que la majoria de resums ometen

Tot projecte comença amb preguntes sense resoldre. La majoria de resums fan veure el contrari: s'escriuen com si ja s'haguessin pres totes les decisions, encara que l'autor sàpiga que no. El resultat és que els equips descobreixen les preguntes obertes a mig desenvolupament, quan són més pertorbadores.

Llistar explícitament les preguntes obertes serveix per a dues coses. Primer, fa aflorar les preguntes que cal resoldre abans de començar la feina (bloquejants) i les que es poden decidir durant el desenvolupament (no bloquejants). Segon, indica a l'equip que el resum és un document de treball, no una especificació acabada, cosa que fa més probable que hi tornin i l'actualitzin a mesura que es prenen decisions.

La trampa de l'extensió Un resum que creix més enllà d'una pàgina ja no és un resum: és un document d'especificació. Les especificacions tenen el seu lloc, però serveixen a una altra finalitat. Si et trobes que necessites més d'una pàgina, passa el detall a un annex enllaçat i limita el resum a les cinc seccions principals.
Com FabricLoop manté viu el resum Un resum només continua sent útil si l'equip el pot trobar i actualitzar. FabricLoop fixa el resum al fil del projecte perquè sempre sigui a un clic, i la conversa al seu voltant (decisions preses, preguntes obertes resoltes, canvis d'abast) queda allà, en context, en lloc de dispersa entre el correu i Slack.

10 idees per endur-se d'aquest article

  1. La majoria de resums de producte s'escriuen per complir un tràmit, no per ajudar els equips a prendre millors decisions. Per això no tornen a utilitzar-se mai.
  2. Un resum és una referència per prendre decisions, no un document de requisits. Ha de respondre les preguntes que sorgeixen a mig desenvolupament.
  3. Les cinc seccions que importen: problema, usuaris, mètrica d'èxit, fora d'abast i preguntes obertes. Tota la resta és especificació.
  4. La secció del problema ha de descriure concretament el dolor de l'usuari, amb dades sempre que sigui possible, i no limitar-se a nomenar l'àrea que s'aborda.
  5. Dir a qui no t'adreces és tan important com dir a qui t'adreces. L'ambigüitat sobre els usuaris provoca ampliacions descontrolades de l'abast en el disseny.
  6. Les mètriques d'èxit han de ser mesurables, acotades en el temps i acordades abans que comenci el desenvolupament, no deduïdes a posteriori a partir de dades d'ús.
  7. La secció fora d'abast és la més important. Els límits d'abast que no s'escriuen gairebé sempre s'amplien durant el desenvolupament.
  8. Etiqueta els elements fora d'abast amb una breu justificació per evitar que les mateixes preguntes ressorgeixin durant el sprint.
  9. Les preguntes obertes s'han d'etiquetar explícitament com a bloquejants (decidir abans del desenvolupament) o no bloquejants (decidir durant el desenvolupament).
  10. Un resum que supera la pàgina s'ha convertit en una especificació. Passa el detall a un annex i mantén el resum concís.