Nel software, il vantaggio non sarà più la tecnologia. Sarà la comprensione del contesto.

Per lungo tempo, la tecnologia è stata un vero elemento differenziante.

Chi poteva permettersi una grande base Oracle, server potenti, un'infrastruttura seria e i team per farla funzionare aveva un vantaggio competitivo reale. La barriera d'ingresso era alta. La tecnologia stessa costruiva parte del moat.

Poi è arrivato il cloud.

Con AWS, Google Cloud, Azure e gli altri, gli stessi blocchi tecnologici sono diventati accessibili a tutti. Non è più necessario investire massicciamente in anticipo: si può noleggiare su richiesta. Non è più necessario essere già grandi per attrezzarsi come i grandi.

Risultato: la tecnologia si è largamente banalizzata.

Certo, esistono ancora differenze nell'esecuzione. Alcuni costruiscono meglio di altri. Alcuni gestiscono meglio, proteggono meglio, progettano architetture migliori. Ma il semplice fatto di «avere la tecnologia» non è più, da solo, un elemento differenziante duraturo.

E con l'IA, faremo un ulteriore passo avanti.

Potremo produrre più velocemente:

• più funzionalità,
• più schermi,
• più varianti,
• più contenuti,
• più codice.

Il costo di produzione del software continuerà a scendere. E quindi il numero di attori in grado di attaccare un mercato continuerà a crescere.

Ma se tutti possono produrre veloce e bene, allora produrre veloce e bene non basta più.

Sfornare feature in serie non sarà più un vantaggio. Sarà semplicemente il livello base.

È per questo che sono sempre più convinto che, per gli editori di software, il vero elemento differenziante si sposterà altrove: verso la comprensione del contesto.

Ciò che conterà è capire prima di costruire

Quando la tecnologia diventa una commodity, e quando la capacità produttiva diventa abbondante, la scarsità cambia posto.

Non è più nel «fare». È nel «capire».

Capire il contesto non significa solo ascoltare due clienti, fare tre interviste e scrivere una nota di inquadramento. Significa comprendere in profondità tutto ciò che circonda un'opportunità di prodotto.

Per esempio:

• il settore,
• gli utenti,
• i clienti,
• i vincoli tecnici,
• le norme,
• la cultura del campo,
• la concorrenza.

Detto altrimenti: i migliori editori non vinceranno perché producono di più. Vinceranno perché capiscono meglio.

Capire il business, davvero

Molti team software continuano a costruire funzionalità senza capire:

• il modello di business del cliente,
• i suoi arbitraggi,
• i suoi margini,
• i suoi vincoli operativi,
• le sue priorità reali,
• e la sua cultura.

E questa dimensione culturale è tutt'altro che secondaria. È spesso decisiva, in particolare nei:

• grandi gruppi,
• aziende internazionali,
• certi settori verticali molto codificati.

Due aziende possono avere la stessa necessità apparente sulla carta e aspettarsi in realtà due cose molto diverse, semplicemente perché non hanno:

• la stessa cultura di decisione,
• lo stesso rapporto con il rischio,
• lo stesso livello di centralizzazione,
• lo stesso rapporto tra sede e campo,
• la stessa attesa di standardizzazione.

Quando non si capisce questo, si può costruire qualcosa di corretto… ma fuori bersaglio.

In un mondo dove tutti potranno costruire, la vera domanda non sarà più: «possiamo sviluppare questa feature?» ma piuttosto: «capiamo abbastanza bene la situazione per costruire la cosa giusta?»

Capire gli utenti, non gli utenti immaginari

Spesso c'è un mondo di differenza tra l'utente che ci si immagina in un workshop e quello che lavora realmente sul campo.

Ciò che bisogna capire sono:

• i suoi vincoli,
• le sue abitudini,
• le sue scorciatoie,
• le sue resistenze,
• il suo carico mentale,
• i suoi workaround.

Con l'IA, potremo generare interfacce molto velocemente. Ma generare velocemente una risposta sbagliata a un problema reale rimane… una risposta sbagliata.

La differenza si farà sulla qualità della comprensione:

• sappiamo come lavorano davvero le persone?
• capiamo cosa tollerano, cosa rifiutano, cosa non osano dire?
• cogliamo le differenze secondo i ruoli, i settori, la maturità digitale o la dimensione dell'azienda?

Capire il cliente, non solo l'utente

In B2B, il cliente non è solo «l'utente».

Il cliente è spesso anche:

• chi paga,
• chi arbitra,
• chi porta avanti il progetto,
• chi deve rassicurare la propria gerarchia,
• chi teme il rischio,
• chi si chiede se il deployment sarà sostenibile.

Un prodotto può:

• essere apprezzato dagli utenti eppure non vendersi,
• risolvere un problema reale e bloccarsi comunque al momento dell'acquisto,
• essere buono, ma incompatibile con i criteri di decisione dell'organizzazione.

Anche qui, la comprensione del contesto diventa centrale.

Capire la tecnica, ma in modo diverso

Dire che la tecnologia non è più il principale elemento differenziante non significa che non conti più.

Conta ancora, ma in modo diverso.

Ciò che farà la differenza non è solo avere accesso allo stack giusto. È capire cosa è ragionevole, robusto e sostenibile costruire in un dato contesto.

Con l'IA, potremo produrre più codice. Ma non avremo automaticamente:

• più coerenza architetturale,
• più affidabilità,
• più sicurezza,
• né migliori integrazioni.

La domanda diventa quindi meno «possiamo codificare questo?» che:

• possiamo integrarlo in modo pulito?
• possiamo mantenerlo?
• possiamo proteggerlo?
• possiamo farlo funzionare nella realtà?

Capire la concorrenza, i segnali deboli, i punti ciechi

L'altra trappola è pensare il proprio prodotto in isolamento.

Il mercato si muove mentre si costruisce. I concorrenti cambiano, le aspettative si spostano, certi utilizzi diventano standard, altri scompaiono, nuovi attori arrivano più velocemente di prima.

Con l'IA, questa pressione aumenterà ancora. Ci saranno più attori in grado di lanciare qualcosa di credibile.

Quindi bisognerà capire:

• cosa fanno i concorrenti,
• cosa promettono,
• cosa non sanno fare,
• dove il mercato si standardizza,
• dove restano ancora veri punti ciechi.

Norme, regolamentazione, tracciabilità: un tema sempre più centrale

Credo anche che sottovalutiamo ancora quanto il contesto regolatorio e normativo acquisterà valore negli anni che vengono.

Si pensa spesso a:

• le norme ISO,
• i riferimenti di settore,
• i requisiti di audit,
• la cybersicurezza,
• la protezione dei dati,
• la conformità settoriale.

Ma c'è anche tutto uno strato molto concreto, molto di campo, che sta guadagnando sempre più importanza:

• la tracciabilità,
• l'archiviazione,
• la normalizzazione,
• la comparabilità dei dati,
• la giustificazione degli scostamenti,
• la leggibilità per la finanza o il controllo.

Molto spesso, questo si traduce in frasi molto semplici:

• «il controller mi chiede questo»,
• «dobbiamo poter giustificare quel numero»,
• «bisogna ritrovare chi ha fatto cosa, quando e perché»,
• «deve essere comparabile tra siti»,
• «serve un dato sfruttabile per l'audit».

In altre parole, non si tratta più solo di costruire uno strumento utile. Bisogna anche costruire uno strumento che:

• lasci tracce,
• strutturi le informazioni,
• renda leggibili le decisioni,
• regga di fronte a una logica di audit,
• regga di fronte a una logica di pilotaggio,
• regga di fronte a una logica di standardizzazione.

E questo non è solo tecnica. È una comprensione fine del contesto del cliente.

Ciò che guadagnerà valore: il documento di contesto

Concretamente, credo che uno dei deliverable che guadagnerà più valore nei prossimi anni non sia solo la spec, né la roadmap.

Sarà un vero documento di contesto per una data opportunità.

Un documento che obbliga a esplicitare, nero su bianco:

• il contesto di business,
• il contesto di prodotto,
• il contesto del cliente,
• il contesto dell'utente,
• il contesto tecnico,
• le regole di settore,
• le norme e la regolamentazione,
• la cultura e le pratiche di campo,
• la concorrenza e le alternative,
• la storia e le decisioni già prese.

E un buon documento di contesto non serve solo ad accumulare fatti. Serve anche a distinguere:

• ciò che so,
• ciò che credo,
• ciò che mi fa dubitare,
• ciò che non si dice.

Perché domani, quando produrre sarà più facile per tutti, ciò che avrà valore non sarà solo la capacità di sfornare una soluzione.

Sarà la capacità di:

• inquadrare correttamente il problema,
• documentare il contesto,
• rendere visibili le zone di rischio,
• allineare il team su una comprensione più profonda dell'opportunità.

In realtà, questo documento di contesto diventa quasi un asset strategico.

In fondo, il vantaggio competitivo si sposta

Credo che stiamo entrando in un periodo in cui il vantaggio competitivo degli editori di software si sposterà in modo molto netto.

Ieri era molto nell'accesso alla tecnologia. Oggi è già meno lì. Domani, con l'IA, sarà ancora meno nella produzione stessa.

Il vero vantaggio sarà nella qualità della comprensione.

Capire meglio degli altri:

• il settore,
• gli utenti,
• i clienti,
• i vincoli tecnici,
• le norme,
• la cultura del campo,
• la concorrenza,
• e tutti i segnali deboli che cambiano la natura di un'opportunità.

Quando tutti possono costruire, chi vince non è chi produce di più.

È chi capisce meglio cosa costruire, per chi, in quale ambiente, con quali vincoli, e per creare quale valore.

Esempio concreto

• 00-context.md

**Stato** : Bozza / In revisione / Validato
**Responsabile** : PM
**Ultimo aggiornamento** : YYYY-MM-DD

# Contesto

## Contesto di business
_Quali sono le sfide di business dietro questo tema? Perché esiste? Quali vincoli di business noti? Questa opportunità funziona per il nostro modello economico, il nostro go-to-market, la nostra strategia?_
_(→ rischio di sostenibilità del business)_



## Contesto di prodotto
_Come funziona oggi? Quali sono i limiti attuali? Cosa è già stato tentato o considerato?_



## Contesto del cliente
_Chi è il cliente (chi paga, chi decide l'acquisto)? Quali sono le sue sfide, i suoi criteri di decisione, i suoi vincoli? Cosa motiva o blocca l'acquisto? Questo tema risponde a un bisogno che il cliente è disposto a pagare?_
_(→ rischio di valore lato acquirente)_



## Contesto dell'utente
_Chi usa il prodotto quotidianamente? Quali utilizzi oggi? Quali pain point noti? L'utente capirà e adotterà la soluzione? Differenze secondo i segmenti o i ruoli?_
_(→ rischio di valore + rischio di usabilità)_



## Contesto tecnico
_Quali elementi tecnici è utile conoscere? Possiamo costruire ciò che prevediamo con le nostre competenze, il nostro stack e i nostri tempi? Vincoli sui dati o sul tracking? Dipendenze importanti?_
_(→ rischio di fattibilità)_



## Regole di settore
_Quali regole di settore esistono già nel nostro CMMS su questo tema? Come gestiscono questo i nostri clienti nei loro processi? Logiche di validazione, calcolo, diritti, workflow già in atto?_



## Norme e regolamentazione
_Quali norme (ISO, EN, NF…) o obblighi regolatori si applicano? Quali impatti su ciò che possiamo o dobbiamo costruire? Requisiti di tracciabilità, conformità, audit?_



## Cultura e pratiche di campo
_Come lavorano davvero i team di campo? Quali abitudini secondo il settore (industria, terziario, sanità…) o la dimensione dell'azienda? Quali percezioni, resistenze o aspettative specifiche da considerare?_



## Concorrenza e alternative attuali
_Come risolvono oggi i clienti questo problema? Quale concorrente, quale strumento interno, quale processo manuale (Excel, carta…)? Cosa funziona o non funziona in queste alternative?_



## Storia e decisioni
_Decisioni già prese su questo tema? Arbitraggi storici utili? Elementi da non riaprire senza motivo?_

Per saperne di più

Il PM come architetto del Contesto Monitoraggio della concorrenza: copiare i competitor non è una strategia Wiki IA: perché ho costruito una base di conoscenza mantenuta da un'IA