When technology stinks

How to transform something that required one step into a 12-steps procedure that also requires an expensive device, good skills, time and patience.

This afternoon I was doing some market research. I run into a website with the following functionality on their homepage:


The goal of the designer was to get your email address to send you newsletters. Something that is there since, probably, 15 years or more. Something that required one and one only thing: typing an email address.

But look what technology and trends bring to you today.

To achieve the same result you now need to:

  1. Have a smartphone, most likely a very smart one and expensive one like an iphone
  2. Have an application that performs scans
  3. If you don’t have one you have to search for it, buy it, download, install etc
  4. Launch the app
  5. Choose “Scan”
  6. Try to get the image well focused
  7. When the image gets scanned, if everything works right, you will get a popup in your smartphone with an URL, with the question: “go to this URL” Yes or No
  8. Hit “Yes” (Oh, I didn’t BTW, I was tired of it already at this point)
  9. A webpage opens …
  10. Great!! You now can finally type in your email address!
  11. Except that you need to zoom and pan to do it, on a micro keyboard
  12. You now have to prove that you are not a robot by zooming, panning and typing in a micro keyboard some senseless combination of illegible characters.

I gave up even if I was interested in the newsletter, I work with technology since I started working and I am a proud owner of an iphone 4s.

Nothing stinks like technology used to make life more complicated for people.

“Request” and “Requirement” – the difference

Sometimes a customer requests a functionality. As an example, because she runs into a problem while interacting with the product. This is more serious when it happens often, when it prevents to accomplish critical or important tasks or when it forces time-consuming and error-prone workarounds.

In this case we are talking about a CRM-Like software, that is a software that every sales people and customer support org uses every day. It could be any enterprise software.

The customer says:

¨I want to sort alerts by sender.  I need to sort by attributes.  Sender must be the first column. How is it possible you cannot sort alerts?
We understand what she says because we know well our product. What we don’t understand however, is WHY that is such a big deal for her. WHAT is the problem she wants to solve in its essence.
Then we interview the customer and we get a totally different perspective
¨Tina gets many alerts but she only needs to know about the ones requiring action on her part so that she does not miss important ones by browsing among hundreds of them, every time”
Can you see the difference?
So, what does this example tell us?
  1. Customer was telling us the solution – We are the experts of the solution, not them.
  2. There could be many possible solutions , some much better than others for both us and the customer.
  3. Customer is the expert of what’s the problem he needs to solve. We need to capture that.
  4. Customer often has a narrow perspective, focused on his problem in a specific day on a specific scenario. It’s normal. We should *never* expect they write requirements for us. They are simply not good at that.
  5. We need to elicit the root cause of the problem. This may require meaningful interviewing skills/methods.

If we don’t do so, let’s not be surprised if we hear things like “The customer said that the feature does not resolve his problem. But we did what he asked for!”

User Personas for… sales ??

The power of User Personas in modeling requirements and building products is well-known (never enough I’d say, but it is known).

I extensively use the incredible power of buyer and user personas (ala Alan Cooper) in the entire product life cycle with consistently excellent results.

The other day I was writing a positioning document, a functional overview for a new product and, while I was at it,  a product datasheet.  I asked myself: “why shouldn’t we  use  the same user personas we developed for designing the product to illustrate product benefits and functionalities?”

And so we did.

I mean, content for customer facing documents. I have used personas several times for design and building products with great success, but never for actually customer-facing documents.

Not only it worked like a charm. I realized then that even our demo guys used the personas we developed for their product demos. Salespeople were also referring to personas when explaining our new solution to customers.

Personas are the most powerful tool you may use in designing, building, marketing and selling products. Period.

Il CEO e i suoi Diamanti

Un giorno il CEO entra in ufficio tutto spedito e trafelato e dice:

Bisogna sviluppare questo nuovo set di  funzionalita’

altrimenti si continua a soccombere alla concorrenza.

Ora, senza entrare nel merito di tale decisione (che sembra reattiva, guidata dallo stress dei venditori,  che forse ha poco a che fare con la differenziazione, e questi sono tutti cattivi indicatori) supponiamo che sia la cosa giusta da fare. Del resto il CEO e’ il CEO. Vede cose che non tutti vedono, e’ pagato per quello, ci mette la sua reputazione ogni giorno, quindi tanto di cappello, si fa come dice il CEO.

(In questo esempio potrebbe anche essere un COO, CTO, CMO, VP of Marketing, VP of engineering, VP of sales etc.  Beh se e’ il VP of sales e’ un altro brutto segno)

L’input che viene dall’alto e’:

il prodotto deve far questo e quest’altro.

Basta guardare cosa fa la concorrenza”

Il tutto viene messo un una paginetta o in una breve email. Cosa ci aspettiamo che il CEO ci scriva i requisiti?

Vengono chieste spiegazioni, ma le risposte sono poco utili a comprendere meglio il contesto, o, meglio, il problema da risolvere e per chi. Chi deve sviluppare soluzioni, cioe’ il “come”  si trova spesso a dover indovinare la soluzione giusta. Talvolta ci sorprendiamo a dire  “senti, questo e’ quello che il capo ha chesto, facciamolo cosi’ come e’ scritto, se poi non va peggio per lui!” (se io fossi il CEO diventerei viola a sentire tali pensieri malsani).

Che cosa possiamo fare?

Soluzione (1) Essere persistenti, uscire dall’ufficio e (2) Cristallizzare requisiti a prova di bomba

Il metodo che adotto io in questi casi per (2) e che io chiamo col nome di Diamond Requirements e’ un modo di risolvere il problema in modo completo e finale. Non solo, ma se ci sono errori di visione o di interpretazione, questi tendono a venir fuori in un ambito meno “politico” e piu’ “costruttivo”.

Definizione di Diamond Requirements: uno strato di requisiti ad alto livello, indipendenti dall’implementazione (soluzione, tecnologia, prodotti esistenti) che collega il business ai requisiti funzionali.

Caratteristiche:

  • Solution-free. Esprimono il cosa ed il perche’, non il come
  • Legano il business case con le specifiche funzionali
  • Forzano a chiarire il business case e il perche’ il progetto e’ importante, critico, urgente
  • Forniscono contesto a chi li deve utilizzare (dal posizionamento al test)
  • Dicono cosa fare in modo chiaro ed incontrovertibile
  • Forniscono a tutti un linguaggio comune – dal cliente al venditore
  • Sono piu’ semplici da comunicare, prioritizzare, rendendo ogni decisione piu’ semplice
  • Sono semplici da analizzare per creare soluzioni
  • Sono in grado di fornire stime ragionevolmente accurate (dipende dal progetto)
  • E’ piu facile compararli ad altri requisiti diamanti (magari di un progetto parallelo)
  • Riducono enormememnte il rischio di dover rifare tutto o parti del prodotto

Come si “cristallizzano”? Certo non con la magia o “col tempo”. Gli ingredienti principali sono:

(1) Avere un business case decente

(2) Interviste, Interviste, Interviste (non lunghi meetings interni per dibattere cose che gia’ sappiamo)

  • Intervistare potenziali clienti dell’applicazione (Funzionalita).
  • Chiedere a chi l’ha gia’ se e’ soddisfatto di come e’ fatta (perche’ noi vogliamo farlo 5X meglio della concorrenza!!! Anche se il CEO non ce l’ha detto! Sempre!)
  • Ciiedere che problema risolve e quanto pesa
  • Perche’ e’ importante averla. Che succede se manca.
  • Chiedere alle vendite quanto sono disposte a mettere in piu’ sul forecast se tale funzionalita’ viene messa sul mercato in data X. Se la risposta e’ vaga parlatene col CEO (e’ lui che la chiede per aumentare le vendite).

(2) Sintetizzare in una forma tale che:

  • I requisiti siano descritti dal punto di vista dello “User Persona” (archetipo di utente) e Buyer Persona ove necessario (business case)
  • Includano il beneficio per il business
  • Enfatizzino Intento e Beneficio invece di postulati senza contesto
  • Includono criteri di accettazione, dai cui si capisce facilmente quando il requisito e’ stato soddisfatto

Non e’ facile, anzi, richiede esperienza e “manico” ma risolve tanti problemi in una volta e porta al successo commerciale dell’iniziativa.

Non e’ quello che il CEO voleva?Anzi, se lo facciamo siamo andati anche oltre!!

P.S. Questo e’ esattamente uno dei compiti chiave di un buon Product Manager.

Articoli correlati:   Good Requirements Relate to Business, What is a Requirement?

Market-Driven? Cosa Significa?

Una Storiella* …

Un giorno un brillante ingegnere ed architetto del software, Paolo, lascio’ il suo lavoro per lavorare a tempo pieno sulla sua idea innovativa. Paolo creo’ un prodotto di cui ha profonda certezza che a molti interessasse.
Paolo aveva ragione.
L’azienda cresce, assume ex colleghi come VP di questo e di quello. L’azienda cresce ancora
Un giorno Luigi, VP of Sales disse: “ma noi siano Technology-Driven. Dovremmo essere Customer-Driven!”
La cosa suono’ bene,  e cosi’ si fece.
Eccetto che… per ogni nuovo cliente bisognava fare un progetto speciale e sviluppare/mettere in roadmap 10 nuove funzionalita’ richieste dallo stesso. La voce del’ultimo cliente dominava sempre il piano del prodotto. In altre parole: Customer-Driven = latest-customer-driven
“Ma no, cosi’ non va! urlarono in molti.
Un membro illuminato della proprieta’, Enrico,  tuono’: “Siamo diventati una Sales-Led company. Basta. Dobbiamo essere Marketing-Driven!”
Venne quindi deciso di assumere un Top Marketing Executive. Fu presa Amelie come VP of marketing. Ed ecco un nuovo scintillante logo, tradeshows con un booth impressionante,  eventi spettacolari con gran folla ed awards, brand impeccabile, grande raccolta di collateral, brochures, logo su ogni t-shirt etc.
Un anno e 3 mesi dopo…zero incremento nelle vendite. “Eh, il brand! Te lo do io il Brand” era la battuta ricorrente. [Niente da dire su Amelie ed il Brand. Le e’ stato chiesto l’impossibile. Lo vedrermo in un altro post, ndr]
Allora il CFO, che fino a quel momento era stato zitto, sussurro’ nell’orecchio del CEO: “non e’ ora che controlliamo un po’ i costi?”
Quindi l’azienda divento’ Cost-Driven
Vennero tagliati viaggi, cene premio, supporto, bonus etc.
E il marketing? Cosa fanno esattamente?” Chiese il CFO al CEO
Nessuno ebbe una buona risposta e quindi tagliarono tutto il team.
Alla fine il presidente e Paolo il fondatore dissero:
Siamo partiti engineering-driven
 Poi Customer-driven
  Poi Sales-Led
   Poi Marketing-Driven
    Poi Cost-Driven
Le abbiamo provate tutte!
… E’ ora di tornare Engineering-driven!
E cosi’ fecero …

Finche’ un giorno qualcuno disse:

Ma perche’ non diventiamo Market-Driven?

Cioe’ perche’ non ascoltiamo il mercato invece che solo noi stessi?

Questo e’ quello che Market-Driven significa:
  1. Definire soluzioni basate su quello che il mercato vuole acquistare perche’ tali soluzioni rispondono ad esigenze urgenti, pervasive e critiche. Sintonizzatevi sul mercato!
  2. Per Buyers (che hanno tali esigenze e potere di budget). Sintonizzatevi sui buyers.
  3. Non e’ essere guidati da cio’ che gia’ abbiamo in casa. Spegnete Radio Prodotto (almeno per un po’). Spegnete “Radio Meetings”
Le aziende di successo sanno che il marketing non e’ solo promozione e pubblicita’. I leaders di settore prima si focalizano su problemi irrisolti del mercato che possono essere risolti tramita la loro tecnologia (non partono dalla tecnologia!)
Questi leaders sono orgarizzati secondo un flusso entrante (inbound marketing) cioe’ capire problemi che il mercato ha e chi sono i buyers, e anche uscente (outboud marketing) che e’ la parte piu’ tradizionalmente vista come “marketing”che include sia su strategie di “go to market” e di comunicazione ma che verte su un modo di comunicare e vendere che risuona col buyer.
3 Errori classicissimi:
  1. Supporre che dipendenti e collaboratori interni conoscano meglio  dei buyers quello che i buyers stessi vogliono.
  2. Basare prodotti e servizi solo su quello che chiedono gli attuali clienti invece di andare fuori dall’ufficio a capire quali sono i problemi irrisolti che altre persone reali sono disposte a pagare per vedere risolti.
  3. Cercare di creare un bisogno nel mercato attraverso il reclutamento di un esercito di spietati venditori e di costose campagne pubblicitarie.

Uscite dall’ufficio e imparate a conoscere i vostri buyers ed i loro problemi e modellate il tutto tramite la chiave di tutto: Le Buyer Personas – ok questo richiede competenza e abilita’ particolari, ma ve lo posso insegnare io 🙂“…Ma non e’ facile staccarsi dal prodotto ed andare fuori ad ascoltare, intervistare, filtrare, sintetizzare, iterare. E poi chi lo fa?”

Market-Driven e’ la scelta piu’ pratica e funzionale per il successo di qualsiasi iniziativa che ha a che fare con un mercato
Modellare business, prodotti e soluzioni tramite Buyer and User Personas rende le cose semplici ed immediate.

Non c’e’ mica scelta! I ruoli che tipicamente hanno tale responsabilita’ sono Product Marketing e Product Management. Almeno nelle aziende ben organizzate.

Ma se non li avete non temete. Qualcuno sta gia’ facendo quello che avrebbero dovuto fare loro. La domanda e’: “Come?” oppure “Con che risultati?”.

*  Storia liberamente tratta da un articolo di Steve Johnson, Pragmaticmarketing.com