User-friendly tools for authors to build rich-media publications?

User-friendly tools for authors to build rich-media publications?

Does anyone know a way for authors (bloggers, content marketers, even magazine editors) to build rich-media digital publications without programming expertise?

Is there any tool that does cool digital publications like what WordPress does for me as a blogging marketing consultant?  I have no knowkedge of CSS, nor HTML5 and Javascript. Online reputation and awareneness are everything in my job. I find ebooks hard to read, especially the media rich ones. And I need infografics, interactive items (such as maps). Everybody does the free ebook stuff today. Ebooks are offline and disconnected from the social web. No social interaction with readers. No facebook likes.

I know I can go with a 3rd party building an app for me but I don’t have that budget.  And I can’t just committ to new app to be developed everytime I want to create my (wannabe super-cool) digital publications.

Besides, I hate to be “prisoner” of formats or app builders, and  I hate the fees I would owe the app stores like Apple & Android.

Am I asking too  much?
Does anobody share the same need?

A Market-Driven Manifesto for Product Teams

Indipendentemente dalla metodologia utilizzata per sviluppare prodotti, in particolare hi-tech ma non solo, vi sono dei fattori che non possono essere trascurati per un successo ripetibile del prodotto sul mercato.

Senza entrare nel merito di aree chiave come il management (vedi Management 3.0 di Jurgen Appelo @management30), ecco un manifesto che propongo per l’adesione ai principi di Market-Driven Business – approccio largamente trattato in altri articoli di questo blog.

Perchè scomodare la parola “manifesto”? Perche’ ricorda la nascita di “Agile”, con le dovute proporzioni e differenze. L’intento di questo manifesto e’ creare un esempio di dichiarazione comune di principi, approcci ed intenti ai quali un team intende aderire perche’ ne conosce l’importanza e l’efficacia. Ovviamente deriva dall’ esperienza reale maturata lavorando con teams di prodotto. Qui viene proposto come elemento di discussione, più che di “pubblicazione di un vero manifesto”

A Market-Driven Manifesto for Product Development

Abbiamo valutato e condiviso un approccio e delle metodologie a cui intendiamo aderire in ogni nostra attivita’.
Ascoltare il mercato ed il cliente è una condizione necessaria per il successo di qualsiasi progetto.
Ogni nostra azione è volta alla creazione di valore per il cliente.
Per cui:

  • Non produciamo software senza Requisiti.
  • Non produciamo Requisiti senza Contesto di Business.
  • I Requisiti sono sempre descritti dal punto di vista della “User Persona” e includono sempre il Valore, il Beneficio per il Business:

===

As a (Persona) …I need to ….so that…..(why important, Value)
Acceptance criteria
Priority

===

  • Abbiamo deciso di adottare il metodo dei Requisiti “Diamante” perchè ci permettono di legare il Business con le Specifiche Funzionali:
  • Includono criteri di accettazione, da cui inferire se il requisito è stato soddisfatto.
  • I criteri di accettazione sono sempre nella forma dei Requisiti sopracitata
  • La “User Persona” e le Priorita’ sono derivate dall’interazione costante col cliente, diretta e indiretta.
  • Sappiamo che alcuni requisiti possono cambiare ed è nostro dovere adattarsi.
  • La condivisione di mockups e prototipi  col cliente è il nostro metodo preferito di progettazione e validazione.
  • I dettagli emergono da frequenti interazioni col cliente e dalla profilazione dello User Persona
  • Risolvono un problema end-to-end

===

  • Ascoltiamo sempre il cliente, ma riconosciamo che spesso non sa cosa vuole o che problema ha.
  • È nostro dovere capire il problema che vuole risolvere per poter creare la migliore soluzione ad esso (per cui chiediamo 5 volte “perchè”).
  • Conosciamo la differenza tra “requisiti” e “richieste del cliente” e conosciamo il valore, per un prodotto,  di trovare la soluzione ad un problema pervasivo, invece quello di fare esattamente quello che ci chiede il cliente.

===

  • Ogni meeting inizia con una lista di obiettivi e si conclude con risposte e/o tasks specifici.
  • Anteponiamo sempre meetings in presenza o via voce a discussioni via email.
  • Conduciamo uno standup meeting giornaliero per allinearci e vedere se ci sono elementi bloccanti

Proponenti: (lista)

===

Ora, molti si chiederanno il significato o la definizione di vari termini come “User Persona”, “Diamanti”, tipo di “Requisiti”, etc, e varie domande come “ma chi ce li da ‘sti requisiti? Noi dobbiamo andare avanto col prodotto, non possiamo perdere tempo” oppure “ma chi ci da il contesto di business” etc., etc.

Ma prima di porvi queste domande, provate a vedere se la vostra organizzazione segue questi principi generali. E se avete domande, sono qui per rispondere!

Articoli correlati:

What I hear often in product companies

Here is what I often hear in product companies. Guess which is the most common one?

  1. I want the confidence that my product goes where we want it to go. I don’have it today.
  2. The product does not sell! What’s wrong? How to fix that?
  3. The product sells but not enough in this segment
  4. Going up (or down)market: what the product should be like? How much it will cost me?
  5. Going global: what the product should be like? How much it will cost me?
  6. Need guidance for the next generation of products. We have a new vision to achieve. We need help
  7. How do I make sure that what we are building is right? We have invested a lot!
  8. Is there a way to tell whether my requirements will deliver against the expected product?
  9. Is there a solid, simple way that is able to tell my company “you are following the right direction” (or  at least the one you have decided to set)
  10. How to build roadmaps that serve business goals? (vs. good-looking, time-consuming slideware with unrealistic, wishful milestones ?)
  11. Marketing people produce tons of sales tools, brochures and presentations. But my sales people say “they are useless” and don’t use them. What’s wrong?
  12. I want that my sales people sell what we must sell, not what it is easiest for them to sell, and I need marketing to support that.
  13. There are a lot of ideas, inputs from sales and pressures from individuals about “top, critical priorities”. Or… “we won’t sell without this or that”. I want to make sure we do the right product for the business. I want clarity.
  14. We spend a lot of time debating features with development. Often it sounds like a war between opinions and I am not able to help much. I want to make sure we have someone driving our offering for measurable benefits for my business. I do not want fights!
  15. We spend way too much energy toward several directions without getting the expected results, our competition is killing us. Time for change. but.. change what? Where do I start from?
  16. Every decision we make is an ordeal. Not to mention fights, politics and internal wars.  I want my line managers to be more aligned, efficient, with clear, shared goals in mind (the same ones).  A sort of “autofocus” mechanism that points to my business’ priorities
  17. I need a methodology that allows me to make informed, intelligent decisions that do not take into account personal agendas and internal politics

What are the ones that are more familiar to YOU?

Improving customer experience – RIGHT!

Today I was chatting over Skype with my wife Sabrina. I don’t chat often on IM but – hey –  it was my birthday after all.

All of a sudden a large, almost full-screen menu opens interrupting my chat. It’s skype telling me that it’s going to shat down the chat to perform a software upgrade.

I hit “NOT NOW” or so.

I restart the conversation (which at that point involved discussions over my desired presents, like fishing tackle, gizmos etc).

After a few seconds the monster menu opens again with a scary countdown bar

I hit the “NO” button again

I chat for a few secs

The menu appears again with a countdown

I hit “NO”

The menu appears again with a countdown

I hit “NO”

Skype closes and starts upgrading.

And it says ” we are improving your customer experience, it will take only a few minutes”

RIGHT!

 

Lean, Agile, Nimble and ready to rock. Or to fail? Part1

READY TO ROCK

Our business is creating software products. We know that “Value” means “providing Benefits to the customers”.

By Product we simply intend “any source of value for customers”.

Now, we are at a time where everybody here at tecnotec13897 is extremely excited for the following reasons

  • We got a new, great idea, a vision for a new product that we believe it will be a groundbreaking innovation
  • We are proud of what we plan to release to the world. It will improve many things
  • We have got a solid strategy in place
  • Our team is composed of very smart people who work very well together in a self-directed manner
  • We are thankful for being able to count on an inspiring, principle-centered, strong management team
  • We know that success depends on the ability to learn how to make repeatable what we have done so far
  • We have put great infrastructure in place to open the road for scaling up when it’s time
  • We have a robust yet very feasible and crystal-clear business plan that has been happily signed off by all stakeholders
  • We have a very well working and well-managed Agile methodology in place, since 2003 and we are now using Lean Agile

We have built our product.

We have tweaked it, fixed some issues, added a few features and shipped again

The conclusion we have to draw is always the same

Our intended customers don’t like our product

They simply won’t buy it

– o –

Using Eric Ries’ words,

we have

successfully

faithfully

rigorously

executed a plan to achieve failure

WHY?

Because we did not know what our customers wanted

Or, worse, what they actually needed

We did not know who our customers were supposed to be

How are they rewarded in their job, what’s their environment like. What are their top-of-mind issues.

What problem they have. How critical that is. How urgent is for them to solve it. How pervasive is that problem in the market of customers we intended to sell our product into

How are they rewarded in their job, what’s their environment like. What are their top of mind issues. What problem they have. How critical that is. How urgent is for them to solve it. How pervasive is that problem in the market of customers we intended to sell our product into

We did not know about them. What they love, what they hate, what is a perfect day for them, what they are afraid of.

We did not know how they buy, when they research what, how do they get the information they seek about the problems they want to solve

Instead of focusing to the landing field, we were piloting a plane focusing to ourselves or to other non-landing related targets.

Have you ever been there? Please share your story

This will be the topic of my talk at Better Software 2012

http://www.bettersoftware.it/2012/programma

 

Changing things for the Better

Despite what our leaders say [….] studies show that our organizationsd are much less productive that they once were ang going out of business faster and faster

  • Jurgen Appelo, How to change the World
  • Stephen Denning, author of “The Leader’s guide to Radical Management”

The same authors say that what was working 20 years ago no longer works today, including the way you changing things. I see two areas in today’s business where a big change is needed. Why is needed? For better results and happier workers.

1. The way we build solutions to problems (e.g. Products, Services)

  • As an example, the Agile Manifesto/Movement has made a huge impact in the world of software development in just a few years. Jurgen Appelo is changing the way managers influence their organizations.

2. The way we build and market solutions to problems  (e.g. Telling our Buyers how good our products are)

  • As an example, the “world’s most popular product management and marketing training company”, pragmaticmarketing.com and virtually every single marketing leader say that it is the market, the buyers that drive winning products, not a bunch of smart people in a meeting room, regardless of how smart they are (if you think of Steve Jobs here, that allegedly “did not do market research” remember that he knew his buyers like nobody one else including the buyers themselves)

These two areas need change. As for the first one, I recommend reading the small book mentioned above, “how to change the world”. It’s 1.5 Euros on Lulu.  It is only a starter of course. Nobody things any book can do any change. People do. Inspired and motivated people do. So this book helps you to start the right tway.

As for the second one, no secret recipe here either. It’s hard. It’s complicate. The shift from telling/pushing products  to listening to buyer’s problems, adapting to their purchase habits, and modeling a complex reality with a few but very helpful models and methodologies (along the lines of the market-driven approach, the Buyer Personas profiling) is a hard and complex task.

Of course they are complex. It is the way you deal with complexity that makes a difference!

See http://www.slideshare.net/jurgenappelo/complexity-thinking

If you don’t aknowledge complexity (and the ways to deal with it) and  use shortcuts instead (such as solely listening to what your salespeople or vocal customers say) then the risk of failures increases. It is under your control really. Why shouldn’t you build a repeatable way to do business that brings the results you want? Stop for a moment and think about it.

 

Related articles:

Vision, Strategy and Bad Strategy: 5 tips

Too many organizational leaders say they have a strategy when they do not. Instead, they espouse what I call “bad strategy.” Bad strategy ignores the power of choice and focus, trying instead to accommodate a multitude of conflicting demands and interests. Like a quarterback whose only advice to his teammates is “let’s win,” bad strategy covers up its failure to guide by embracing the language of broad goals, ambition, vision, and values. Each of these elements is, of course, an important part of human life. But, by themselves, they are not substitutes for the hard work of strategy.

Richard Rumel, McKinsey Quarterly, The perils of bad strategy

Common Dilemmas around Vision and Strategy

Carla the CEO says: “I know I need a vision but I can’t seem to understand what a vision actually is.”

“I have read a lot of terms like mission, purpose, values, strategic intent, but no one has never given me a satisfactory, clear explanation of what a vision is and what actionable directions it gives me” adds Josh the VP od Sales

On the other hand, Gina, the marketing communication specialist, knows very well what her company vision is. “It’s on my cubicle wall. But how does it actually guide my work?” she says puzzled.

The very assertive Frank the CEO complains: “I do have a Great Vision, but they don’t get it. I’ve given them a memo with all the details. What’s wrong with them?”

Alvin, the sales engineer who travels all week-long, goes: “What? Vision? Again with that BS? You had another of those fancy marketing books for breakfast this morning, didn’t you?  Leave me alone, please. I’ve got work to do, at least I do!”

Vision and Strategy at work

What is a “vision” then?

It is a destination. A desirable business end-state for an organization. It’s about knowing where you want to go. And, where you don’t want to go.

It’s NOT what you want to “do”.

It’s not the “how

It’s the “where

And,  what’s a Strategy then?

It’s the path to get to that destination. How you will get there.

In other words:

  • Strategy: Sounds great! But… to go where? …“I have a map but I don’t know where to go”
  • Vision: We have one! But… how do we get there?   …”I know my destination, now I need a map!”

“If a company does not have a vision of where it wants to go, then any product strategy is likely to take it somewhere. But will they be happy with somewhere when it gets there?”

Michael McGrath

“I can always plan to operate in full market-driven mode, tuning my offering for an army of buyers that want my product or service, using the latest social media and content marketing strategies. But, how can I do that without a Company Vision and a Strategy that oversees the business and guides me there?”

Donato Mangialardo, Director of Product Strategy

5 Tips – Using Vision and Strategy for guiding everything you do

Tip#1 – You need to have both. They need to be fully aligned to provide guidance and focus. As a Top Manager, you want to make sure they are always, consistently aligned.

Tip#2 – The Vision must be extremely clear. It needs to provide focus. What is in scope, what is NOT. What is success like. Ambiguity brings individual interpretations.

Tip#3 – Strategy means what do we intend to do in order to achieve the goals expressed by the Vision. What should we NOT do.  Again, conciseness  and clarity are  a must. Everybody needs to remember it and apply it.

Tip #4 – Establish a Strategy by looking at your distinctive competences, but also acknowledge the challenges your organization faces, including inconvenient truths. Provide an approach to overcoming them.

Tip #5 – Put together Vision, Strategy and Why your organization believes it can be successful in a coherent, 3-sections statement that fits in a page.  It is a difficult exercise, but it works like a charm if well done.

(I see these more as Rules than Tips actually)

Conclusion: Align your business and your teams to understand what is and how to reach your business destination, the Vision you have set for your organization.  What’s the Strategy. This will provide focus, facilitating decisions and avoiding debates of opinions. As a byproduct, it will increase motivation and engagement in your teams.

Then, if you ask yourself …

  • “Right, but… do we have an actionable vision?”
  • “How do we get there?”
  • “Do we have a clear strategy?”
  • “Will we be able to follow that strategy?
  • “What changes will be required?”
  • “Is my company ready?”
  • “How do I know if I have set the right Vision and the right Strategy for my business?”
  • “How do I actually align them?”
  • “How do I know whether I have factored-in all the variables?”

…Then (note, this is a Self-Promoting paragraph) you want to consider investing in this  effective exercise that will direct your business to repeatable wins and eventually success.This is one of the things I like to do the most in my profession at crystal-ize.com, with a solid, proven methodology drawn from a specific experience in International, US-based and Italian companies of various business models and size.

I am sure you may have questions: please leave your comment. I will surely reply and assist your cause.

“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!”

Smettiamola di profumare il MAIALE!

In media il CMO di una tech company (Chief Marketing Officer) rimane occupato per 23 mesi.  Source: Spencer Stuart

La meta’ di quella per  CEO and COO. Quindi la domanda sorge spontanea. Perche’ il lavoro da CMO e’ cosi’ a rischio?

 Perche’ un CMO non riesce a soddisfare aspettative irragionevoli, anzi, di fatto impossibili:

Il CMO non riesce a creare il bisogno per il prodotto della  sua azienda. In altre parole, quello che capita spesso a marketing managers e’ venir assunti per “profumare il maiale”. O mettergli il rossetto, che come frase idiomatica in US e’ ben piu’ potente.

Sfortunatamente, i buyers non hanno bisogno di quello che non hanno bisogno

Il product marketing viene relegato alla distribuzione semiforzata di un prodotto di cui non e’ chiaro il problema che risolve e per chi lo risolve.

Non c’e’ quantita’ di profumo che possa allontanare il “fetore”

di un prodotto tecnologico di cui nessuno ha bisogno *

Ma allora?

In altre parole, basta essere Market-Driven

facile eh? 🙂

(*) da Steve Johnson #pragmaticmarketing

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

Il Marketing e’ MORTO

IL MARKETING E’ MORTO

Se cercate su Google “marketing is dead,” troverete molte morti annunciate:

email marketing, social media marketing, affiliate marketing, viral marketing, internet marketing, mass marketing, brand marketing, direct marketing, network marketing, relationship marketing,

Persino le 4 P’s del marketing!

Il problema parte proprio da chi “fa marketing”. Quelli che dicono di essere “marketers” ma che invece  sbandierano in modo opportunistico l’ultima novita’ tecnologica o trend, associandole ai propri prodotti o soluzioni in modo sensazionalistico, senza alcun vero valore per il cliente.
Quelli che usano sempre e solo i seguenti termini: Scalabile, Potente, Veloce e Semplice, Il cliente al primo posto,Di Nuova Generazione, Innovativa, etc.

E’ un marketing generico e non targettizzato (“List marketing”)
Spesso invadente ed asfissiante.
…“a questi non interessa se sono pronto a considerare un processo di acquisto o se non posso. Mi aggrediscono lo stesso sempre con le stesse argomentazioni”…
Messaggi “sbraitati” ma piatti, “senza contenuti che mi interessino”, senza un target

IL MONDO E’ CAMBIATO

  • Le vendite non sono piu’ LA fonte dell’informazione
  • I clienti possono  parlare al mondo – “broadcast to the world”
  • I potenziali clienti possono parlare  tra di loro facilmente, istantaneamente, quando lo decidono loro.
  • L’ Informazione di prodotto e’ facilmente accessibile (chi nasconde informazioni e’ sospettoso e viene scartato)

I potenziali clienti  sono spesso gia’ un bel passo avanti nel ciclo di vendita prima che i venditori si accorgono che esistano.

Quindi, quando interpellati, i ns buyers vogliono sentirsi dire qualcosa di interessante riguardo i loro problemi, nella loro lingua.

Non cose che sanno gia’. Non hanno tempo da perdere.

IL MARKETING VIVE ECCOME!!

Invece il vero marketing e’ vivo e’ vegeto, ansi, e’ la chiave del successo. Pochi lo sanno quindi chi lo sa e lo applica ha un vantaggio competitivo notevole.

Il marketing e’ il processo per cui organizzazioni determinano quali prodotti/servizi possano interessare a potenziali clienti, e la strategia da usare nelle vendite, nel marketing communications e nello sviluppo del business.

Le aziende di successo sanno bene che il marketing non e’ solo promozione e pubblicita’.

Sanno che non e’ una lista di cose tipo Fiere di Settore, Direct mail, Newsletters, Pubblicita’, Brochures, Calcolatori del ROI, Presentazioni, Roadshows. Sono tutti pezzi utili ma non possono essere chiamati marketing. Ovvero, questo marketing e’ morto.

Le aziende di successo non assumono un nuovo direttore marketing chiedendogli di fatto di “creare il bisogno per un prodotto”.

Infatti, sfortunatamente, i buyers non hanno bisogno di quello che non hanno bisogno, quindi questo approccio e’ costoso, in salita e avaro di soddisfazioni e di ritorni di investimento. Ovvio, se manca la promozione del tutto bisogna farne prima fare altro. Ma se il prodotto non vende o e’ sbagliato o si sta parlando con le persone sbagliate delle cose sbagliate. E qui rientra il vero marketing, che ha a che fare con Buyers e i loro problemi, non il nostro prodotto.
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.

Se poi usano tecniche tipo Buyer Personas, le probabilita’ di successo si alzano di molto, ma qui andiamo nel particolare.

There are many statistics on the validity of sharply defined market requirement documents, including the following quote from Robert G. Cooper in Winning at New Products,

Successful products have much sharper definition prior to development. Projects that have these sharp definitions are:

  • 3.3 times as likely to be successful
  • Have higher market share
  • Are rated 7.6 out of 10.0 in terms of profitability (vs. 3.1 out of 10.0 for poorly defined projects)

Few technology companies know their markets. It is not that software and hardware companies ignore their customers; in many cases they have reams of customer input from sales, customer service and user groups that product managers sift through to develop lengthy lists of product and feature requirements. But there are some key differences in the methodology used to determine product and release drivers […]

source: pragmaticmarketing.com

 

Good Requirements Relate to Business

Why Requirements are so critical in the software product and project business. How do they relate with the business case?

Have you ever heard of:

  • A Developer complains: “I cannot program to these requirements!”
  • The Product Manager says: “Our developers wrote features that didn’t do what the customer needs!”
  • Developer: “don’t tell me how to do my job”
  • Developer: “This is NOT A REQUIREMENT!”
  • ALL: how much detail is needed?
  • ALL: when do I know when I am done?
  • Who writes Requirements?
  • Who writes specs? What’s the difference?
  • Tech. acct. manager: “It is not my responsibility to write requirements. I am just communicating what the customer told me!”
  • Customer: “this is not what I needed!”

This causes a number of issues:

  • Friction between people, teams and functions make everything harder. When the project is critical and the pressure is very high things often get out of control.
  • Different ways to see the product or the feature objectives and priorities. Misalignment
  • Bad requirements lead to bad prioritization and wrong or very (unnecessarily) risky decisions.
  • Lack of common vocabulary or methodology take the organization to non repeatable success or most often to unsuccessful products.

Examples of why this happens:

  • Requirements are not actionable. Developers have to guess
  • Requirements are too detailed. Developers are told the solution to build (it’s their job and they are they are good at building solutions to problems). But there is no such a thing as a document with all details covered.
  • Developers lack the understanding of the customers need…which makes it harder for them to make informed decisions in building the solution
  • The customer tells the dev team what the solution should be. But Problem Solving is not for them. Explaining us the problem is. We are the experts for finding a solution to the problem (for N customers if you mean to build  a product that sells to a given  market)

The Value of Good Requirements

  • Are actionable
  • Provide a common language for everybody (from dev to customer)
  • Are easier to prioritize (pain, severity, importance etc)
  • Are easier to agree upon when we discuss what we need to do
  • Are easier to compare with others (patterns, use cases)
  • Are easier to analyze and design for
  • Are easier for providing better and faster estimates
  • Reduce the risk of rework (you may not even get to have another shot at it)
  • Are connected to the business

Yes, connected to the business! This is the critical, essential part of all this. What is the impact on business that every technical decision related to the software can have. How to relate a major release success criteria with software engineering tasks and vice versa.

If you are able to master it you will be successful. Making sure you have Good Requirements means you have done most of the work to get to a successful (business) outcome.

What is a Requirement?

What is a Requirement?

check this out at http://bit.ly/q2cyZz

Requirement Describe a user (persona) interacting with a product to resolve a problem. The following format has been proven to be very intuitive and effective:

As a <Persona> I want to <Intent> so that <Valuable>

Example 1

Todd wants to share his design (in form of a sub assembly) with suppliers for a prototype run. He need to generate automatically specific file formats (PDF and IGES) from his many 3D CAD models so that he can save time and distraction from his core engineering tasks.

Example 2

As a technical reviewer I want to access the information I am asked to review in an univalent manner. I don’t want to fish for the files need every time, So that I have the required time to review them before submission and save costly errors

Related articles:

Good Requirements Relate to Business

Il CEO ed i suoi diamanti