I modi migliori e peggiori per creare una specifica di prodotto

Una delle più grandi sfide che i team di sviluppo prodotto devono affrontare è semplicemente come decidere quale prodotto costruire. Nel caso di team che lavorano da una specifica di prodotto, in particolare nello sviluppo dell’hardware, gli ingegneri non sono tipicamente autorizzati a iniziare a lavorare fino a quando non è completata e approvata. E dato che la maggior parte dei tempi di sviluppo sono incredibilmente brevi, spesso non c’è abbastanza tempo per considerare soluzioni alternative una volta che nuove informazioni vengono alla luce.

Un modo di guardare a questa sfida è mostrato qui. Potete immaginare che il cerchio sia ogni possibile modo in cui il team potrebbe costruire il prodotto. E quel piccolo punto blu è la specifica di un particolare prodotto. Questa specifica di prodotto definisce esattamente su quale prodotto gli sviluppatori dovrebbero concentrarsi e costruire.

In questo post, descriverò prima alcuni dei metodi comuni usati per concordare una specifica di prodotto. Poi esplorerò i problemi con questi metodi e come possono portare a costruire prodotti da una specifica che in realtà non risolve i problemi del cliente.

Devo dire che la mia prospettiva deriva da 10 anni di esperienza di lavoro nell’industria dei semiconduttori analogici e a segnale misto, prima come ingegnere di applicazioni e poi come definitore di prodotti. Ora, sono un consulente qui a Jama.

I peggiori modi per creare una specifica di prodotto:

Chiedete al vostro cliente cosa vogliono che voi costruiate

Un modo per iniziare è chiedere ai vostri clienti di cosa hanno bisogno. Questo potrebbe essere fatto aspettando una richiesta di preventivo (RFQ) emessa dal cliente, o meno formalmente, attraverso incontri e discussioni. Di solito quello che imparerete con questo approccio è quale soluzione o prodotto stanno usando oggi e cosa vorrebbero vedere cambiato nel prossimo futuro. In un certo senso, state agendo come un appaltatore e il vostro cliente è responsabile di tutti i dettagli della specifica.

Dato che questo scenario richiede di iterare su un prodotto esistente, c’è un’alta probabilità che finirete con un’idea molto specifica che potete sicuramente implementare.

Tuttavia, ci sono diversi problemi con questo approccio:

• Quello che il tuo cliente ti sta dicendo sulla sua strategia di prodotto lo sta probabilmente dicendo anche alla tua concorrenza, e un obiettivo chiave del progetto è probabilmente fare qualcosa di più economico della soluzione esistente. Vi troverete in una guerra dei prezzi.
• Il tuo cliente è già impostato su un tipo di soluzione, basato su ciò che aveva comprato prima, il che rende difficile suggerire qualcosa che possa soddisfare meglio le sue esigenze.
• Il programma è probabilmente estremamente aggressivo, lasciando poche opportunità di costruire qualcosa di nuovo, o permettendo una vera innovazione.
• Il tuo cliente potrebbe non essere consapevole delle nuove tecnologie, o semplicemente potrebbe non sapere di cosa ha bisogno.

In questo caso, vi state affidando al vostro cliente per tradurre i suoi requisiti interni in una specifica per voi, piuttosto che scrivere i requisiti per un prodotto che il mercato più ampio ha bisogno e comprerà.

Mentre sviluppate il prodotto, il vostro team dovrà inevitabilmente fare dei compromessi per varie ragioni. L’unico modo per essere sicuri che sia stata fatta la scelta migliore è di rivedere le modifiche alle specifiche del prodotto risultante con il vostro cliente. Se non lo fate, correte il rischio di costruire un prodotto che non accetteranno. Ma poiché il team di progettazione sarà sotto pressione estrema per eseguire un programma aggressivo, c’è una forte possibilità che faccia dei compromessi sul prodotto senza tutte le migliori informazioni. Questo aumenta ulteriormente il rischio di costruire il prodotto sbagliato.

Questo approccio funziona in quanto un prodotto viene consegnato. Se siete nel business della fornitura di componenti di base, allora questo va bene. Se state cercando una soluzione unica che difenda il margine lordo, allora questo non è l’approccio migliore.

POST CORRELATI: Come eseguire una migliore analisi dell’impatto sulle relazioni a monte e a valle

2. Far scrivere ad un ingegnere l’intera specifica

Un altro scenario comune è quello in cui un ingegnere, o qualche altro membro del team rivolto al cliente, immagina una soluzione basata sulle conversazioni che ha avuto con uno o pochi clienti. Il team si riunisce intorno a questa idea, e con un impeto di slancio interno i requisiti sono rapidamente documentati e gli sforzi del team si rivolgono rapidamente alla scrittura delle specifiche del prodotto e allo sviluppo della soluzione.

Una volta che una soluzione è completa e pronta per andare sul mercato, alcuni team convalideranno la loro idea con i clienti, ma poiché il team sta presentando una soluzione, non esplorando un bisogno, la discussione tende ad essere intorno ai dettagli nelle specifiche del prodotto. Questi team non avranno l’opportunità di scoprire se la soluzione sta risolvendo un problema.

Tipicamente, in questo scenario, i requisiti del prodotto provengono direttamente dalla testa di un individuo e sono poi catturati in un lungo foglio di specifiche, e il resto del team si comporta utilizzando le specifiche documentate. Ogni volta che il team si imbatte in un conflitto in cui deve essere fatto un compromesso, l’individuo che ha scritto i requisiti deve decidere i giusti compromessi in modo indipendente, con poche o nessuna nuova informazione. Inoltre, se quella persona non ha fatto ricerche né ha convalidato i requisiti, allora il team costruirà il prodotto sbagliato.

Perché questi approcci non portano al successo

Quello che entrambi gli approcci precedenti hanno in comune è che l’obiettivo è arrivare ad una specifica di prodotto finito il più velocemente possibile. I team hanno così tanta fretta di iniziare a costruire qualcosa e rispettare la scadenza del cliente, che non si assicurano prima che quel qualcosa sia il giusto qualcosa.

Inoltre, la conoscenza dei requisiti esiste con un solo individuo nel team. Quell’individuo è la persona che si interfaccia con il cliente sponsor, o è la persona che ha avuto l’idea del prodotto. In entrambi i casi, il resto del team è privo di qualsiasi contesto per la soluzione, il perché stanno costruendo questo prodotto, e quindi non possono fare raccomandazioni.

Il risultato è che spesso i prodotti vengono uccisi più tardi di quanto avrebbero dovuto, dopo che molto tempo e denaro è stato sprecato, o i team creano prodotti che non hanno successo o prodotti me-too che competono in gran parte sul prezzo. Nessuno di questi è buono per il business.

POST CORRELATI: 8 Do’s and Don’ts for Writing Requirements

I modi migliori per creare una specifica di prodotto:

Il modo migliore per costruire prodotti che i vostri clienti compreranno è quello di uscire e parlare con il vostro mercato target molto prima di iniziare a scrivere le specifiche. Per prima cosa, avete bisogno di articolare la vostra dichiarazione del problema.

Una dichiarazione del problema del prodotto è un paio di frasi o paragrafi che descrivono un bisogno del mercato. Sono scritti dalla prospettiva della persona che ha il problema e – questo è critico – non dicono nulla su come risolvere effettivamente il problema. L’obiettivo di questa fase dell’esplorazione è di trasmettere una comprensione del problema e un senso del valore associato alla sua soluzione.

Una dichiarazione del problema è generalmente composta da tre parti:

1. La prima è la persona, o una descrizione di chi ha il problema. È utile descrivere la persona in grande dettaglio separatamente e poi fare riferimento ad una particolare persona nella dichiarazione del problema per evitare di ripetere la stessa descrizione della persona.
2. Poi c’è una descrizione del problema. Più dettagli ci sono, meglio è. Volete assicurarvi che il bisogno sia cristallino. Inoltre, date un nome al problema. Questo rende più facile per le squadre fare riferimento ad esso durante il progetto.
3. Infine, scrivi una descrizione di quanto spesso il problema si verifica. Se il problema si verifica raramente e ha un basso impatto, allora risolverlo è di basso valore. Se il problema si verifica frequentemente e ha un alto impatto, allora il valore della sua soluzione sarà alto.

Puoi iniziare chiedendo ai clienti quali problemi hanno che pensano tu possa risolvere, ma devi scavare più a fondo per arrivare alle dichiarazioni di problemi veramente preziosi o pepite d’oro. Queste pepite d’oro generalmente provengono dallo sviluppo di una profonda comprensione del mercato e dal mettere insieme informazioni da una vasta gamma di fonti.

Se lo fate con successo, finirete per identificare un problema che potete risolvere e per il quale il vostro cliente pagherà.

Durante il processo, state attenti a non incorrere in falsi positivi o negativi. Ascoltare troppo le persone all’interno della tua azienda o solo un piccolo numero di clienti può portarti a convalidare o abbandonare falsamente un problema. Parlate con quanti più clienti potete e raccogliete più dati possibili.

Torniamo al nostro diagramma di tutti i possibili prodotti che possiamo costruire.

Questa volta abbiamo aggiunto linee intersecanti che rappresentano i vincoli. Se pensiamo alle dichiarazioni del problema come linee che attraversano il cerchio, allora una buona dichiarazione del problema basata sulla comprensione del mercato delimiterà un’area nel cerchio che rappresenta tutte le soluzioni accettabili. Qualsiasi cosa in quest’area risolve il problema e sarebbe accettabile per il cliente.

Si noterà che la dimensione di quest’area è molto più grande dei precedenti cerchi RFQ e idee di prodotto. Questo perché queste dichiarazioni del problema e il contesto vincolano intenzionalmente la soluzione nel modo più sciolto possibile per permettere a nuove idee di farsi avanti.

L’idea è di dare al team di progettazione la massima flessibilità nel creare la soluzione più innovativa possibile all’interno dei vincoli.

POST CORRELATI: Lista di controllo: Selezionare uno strumento di gestione dei requisiti

Come si arriva a una dichiarazione finale del problema?

Queste sono le mie raccomandazioni:

1. Inizia assegnando a qualcuno per ogni progetto la responsabilità di essere la voce del cliente.
2. Poi, incarica quella persona di identificare i problemi di mercato esclusivamente sulla base delle informazioni raccolte dal mercato.
3. Assicurati che quei problemi di mercato siano documentati e condivisi in un posto a cui tutta la squadra ha accesso.
4. Scrivi una giustificazione per ogni dichiarazione del problema di mercato che spiega perché è un problema e quanto è importante da risolvere
5. Aggiungi una pietra miliare nel piano del progetto dove le dichiarazioni del problema devono essere riviste e approvate dalla squadra insieme a un business case.
6. Quando la squadra inizia a sviluppare una soluzione, ritorna periodicamente all’elenco delle dichiarazioni del problema per ricordare a tutti qual è l’obiettivo.
7. Per ogni problema, cattura un elenco delle caratteristiche del prodotto che risolverà il problema.
8. Se un problema non può essere risolto completamente, riesaminare il business case per assicurarsi che il prodotto sia ancora fattibile.

Dalla dichiarazione del problema alla specifica

Ora che hai le tue dichiarazioni del problema e il team ha preso familiarità con esse, inizia a sviluppare in modo collaborativo una specifica del prodotto. Poiché tutti nel team capiscono il problema da risolvere, tutti possono contribuire alla specifica.

Perché hai fatto il lavoro iniziale di identificazione del problema che stai risolvendo, all’interno dei vincoli identificati, e il tuo team ha considerato diversi modi di fornire la soluzione, hai abbastanza informazioni per scrivere la specifica del prodotto.

Rilascia la specifica del prodotto in piccoli lotti

L’approccio migliore qui è di rilasciare piccoli pezzi della specifica al team il più presto possibile per ottenere un feedback veloce. Questo aiuterà ad evitare di perdere tempo andando sulla strada sbagliata e renderà molto più facile per il team fornire un feedback di alta qualità.

Non sei convinto? Considerate questo: Cosa succede se ricevete un foglio di specifiche di 200 pagine da revisionare? Probabilmente guardate le prime pagine e poi scremate il resto.

Ora, cosa succede se ricevete un documento di una pagina? Probabilmente lo esaminate tutto. Duecento documenti di una pagina produrranno un feedback molto migliore di un singolo documento di 200 pagine.

Riferimento alla dichiarazione del problema per assicurarsi di essere sulla strada giusta

Inoltre, mentre sviluppate la specifica, controllate di nuovo per assicurarvi che il prodotto sia ancora una soluzione valida al problema. È facile farsi prendere dal compromesso inerente allo sviluppo di un prodotto e dimenticare di controllare se si è ancora sull’obiettivo.

Questo approccio gestisce anche le aspettative delle parti interessate. Poiché il processo è controllato, c’è una struttura e una trasparenza che impedisce a chiunque di sovrascrivere le decisioni. In qualsiasi punto del progetto, sarete in grado di spiegare esattamente quale valore offre il vostro prodotto e perché deve avere le caratteristiche che il team ha specificato.

Progettare prodotti per le esigenze del mercato è fondamentale per il successo

Riconosco che in alcuni settori questo è un grande cambiamento rispetto a come i prodotti sono stati progettati e costruiti. Ma mentre i mercati diventano più competitivi e i prodotti diventano sempre più complessi, consegnare semplicemente un’altra iterazione di qualcosa che hai già costruito non ti terrà in affari a lungo.

Per saperne di più su come scrivere i requisiti in modo che tutte le parti interessate abbiano una chiara comprensione delle esigenze di sviluppo, scarica il nostro eBook, Best Practices for Writing Requirements.

Leggi l’EBOOK