RSS
 

Archive for October, 2010

Write Once, Print Often

A wise man once taught me that there is no need to write and rewrite and write again the marketing collateral for websites, brochures, and flyers for a product. In fact, consistency across marketing collateral goes a very long way towards communicating complex product descriptions and value propositions to customers, market analysts and sales teams.

I had first experienced the impact of writing canonical text in 2006 when I was working for a highly-technical company and was trying to find ways to communicate clearly what the different products did, how they related to each other, and why they would solve the customers’ problems.

The first thing that stood out when we began to review our collateral was that there was an awful lot of text on every webpage, brochure and flyer. And the text on each of these items was completely different from the others. This meant that the marketing teams were rewriting the text for every piece of marketing material relating to each product. It confused the sales teams and market analysts, and it certainly confused our customers.

The leader of our marketing department decided to have us write canonical text for every product in our division. He had us begin by writing a problem statement for each product (see my previous post titled “What is your Problem?”. The problem statement helped to clarify the basic value proposition of the product.

Because the problem statement included a list of features and benefits, an elevator pitch for each product became much easier to put together. This is a description of the product that you could tell someone during an elevator ride. For some products, this is a remarkable difficult achievement!

As pieces of sales collateral needed to be written with more detail, such as flyers, brochures, and seminar slidesets, the canonical text proved to be a very good starting point. Each piece of material that was written with more detail could be tailored to the audience, whether it needed to be more technical for seminars or at a laymen’s level like websites and flyers. This helped to ensure the message was consistent across audiences.

We then proceeded to expand this text into a website where we needed images – in this case screenshots. As part of the canonical text exercise, we chose a very small number of screenshots, graphs and graphics that would be relevant, interesting, and easy to reuse. Like the canonical text, these images were the same across all of the marketing collateral for each product. Make certain to save them as high-resolution the first time as recreating them for printed brochures is not fun.

By finessing all of the marketing material in the department in this way, we found that we were able to respond much more quickly to marketing needs, we were much more confident in our external communication, and our sales department and customers finally understood what we were talking about. Well, most of the time.

Share
 
No Comments

Posted in Product Management

 

What is your problem?

The other day my husband and I were in the middle of a long drive when we started discussing one of his business ideas. When described verbally, it was one of those ideas that was very complex and difficult to explain. We started thinking about how to simplify the explanation of the business model enough that people hearing about it would not get overwhelmed.

This was the perfect scenario for a problem statement.

For anyone who doesn’t know what a problem statement is, it is the basic problem that the market is experiencing which you feel you can solve with a product.

Writing a problem statement is not an easy task. I have found that it works best as a very simple statement without caveats or descriptions.

Good Problem Statement: “Traffic into Cambridge can come to a standstill, usually in the mornings.”

When I ask someone to write a problem statement, they invariably try to use their solution as the problem.

Bad Problem Statement: “Cambridge needs to create a congestion zone and charge drivers for driving within that zone.”

By using their solution as the problem statement, they have not only avoided acknowledging the actual problem they are trying to solve, but they have essentially ended any discussion around how to solve the core problem. If the audience doesn’t agree with their solution, there is no empathy remaining around the need to solve the problem that still remains.

Using Google as an example, chances are that the makers of Google didn’t sit down and say “lets build a search engine” just for fun. They probably first identified a problem in the market such as “finding anything on the web is difficult.” Their solution was “build a search engine.”

Now that the problem statement and solution statement have been sorted out, it is a good time to begin listing the features and benefits of your solution. This is another situation where people often mistake one concept for another. Your feature is not inherently a benefit, and the benefits that your solution provides don’t count as features.

I prefer to list the features and benefits in table format with features in the left column and benefits in the right column, each benefit aligned with a specific feature. The hypothetical Google features and benefits might read:

Problem: “Finding anything on the web is difficult.”

Solution: “Build a search engine.”

Feature #1: Robots scour the internet for words and phrases
Benefit: Website owners do not need to submit their sites for inclusion into search results
Benefit: The latest versions of website are always searchable

Feature #2: Words and phrases on the internet are indexed into a database of results
Benefit: Searches can occur fast and results displayed almost immediately

If you take this example and use it as a template, keep an eye on how often you find yourself writing a solution in the problem field or a benefit in the features field. After a bit of practice, you can get your product idea clearly defined and communicated.

Share
 
2 Comments

Posted in Product Management

 

It’s Not About the Features

Something that many companies miss is that the success of a piece of software is not necessarily based on the features, nor is the success of hardware based on the technology inside. Instead, it is most often the pleasure of using software on a computer or device that drives adoption and leads to a product’s success.

How many users do you know who say “I love my HTC TytnII mobile phone. It has an ARM CPU in it which can be very powerful”?

Answer: Zero.

Outside of ARM’s employee base, I would wager that this sentence has never been uttered. When asked about how they like their Tytn, I’ve heard people respond with “it is too difficult to find what I am looking for” or “It is slow”. Similarly, the Nokia phones have traditionally been the market leaders in Europe, but time and again, despite the leading edge technology inside, the thing people focus on the most is the difficult user interface which often requires 8 clicks to do something that could only require two clicks.

There have been many astounding advances in hardware technology that should have made our devices such as televisions, mobile phones and laptops snowball into futuristic gadgets, but there is a chasm between the hardware technologies in a device and the software being written to exploit all this power. One example is graphics processing units (GPU). For years, high-end computers have had GPUs in their systems for driving video games and mathematical rendering, but now GPUs are entering the embedded space.

About this, users don’t care.

Where this gets interesting, though, is when software developers are trained on the programming languages specific to the GPUs and can really take advantage of the speed and power provided to them.

Still, users don’t care.

It is only when the user interface designers, software developers, and product managers work together that any of this becomes remotely relevant to the end users.

As an example, look at my favourite subjects, the iPad and the iPhone. Why do people love these devices? It isn’t because of the incredibly powerful CPUs in sided. It isn’t the GPUs inside. And it isn’t even the features. The users love these devices because the experience of using them is fun.

There is an emotional reaction to using these products that spans generations, cultures and lifestyles. Part of generating an emotional response is to be responsive and reactive enough that the excitement level doesn’t dissipate (no slow rendering). Another aspect of an emotional attachment is safety or absence of fear (the user cant break anything).

The users don’t care about the guts of the machine. They don’t care that the software developers wrote the graphics rendering code in OpenGL ES or DirectX to take advantage of the GPU. They don’t even care if you loaded the hardware or software with features or left everything simple.

The users care about the experience.

Share
 
No Comments

Posted in Apple, iPad, iPhone, Product Management, Usability