Many years ago I came across a booked titled “Quality is Free”, written by Philip B. Crosby. I must confess that I only skimmed through the book at the time, and haven’t really read it in details. I wish I did though. Read the rest of this entry »
Unfortunately, some customers may not always be happy with your company’s product or service. As long as the majority of your customers are happy with it, most of the time – you are probably doing fine. However, every once in a while you may encounter a customer that is more than just “unhappy”. In fact, they may even be furious. Any situation where a customer is grossly unhappy with your solution, and possibly experiencing negative financial impact or a major loss of productivity, should be defined a “customer crisis”. Read the rest of this entry »
Whitepaper are often regarded as “sales tools”, created after product development is complete and as part of getting ready for sales. But a whitepaper can do much more than augmenting the company’s sales collateral. It can help crystalize the product strategy and establish the value of developing a specific product or a service in the first place. After all, a product should address a specific customer need and deliver economic value – and that’s precisely what a whitepaper is supposed to communicate.
I started working as a product manager for a company that focused on developing electronic system-level (ESL) design tools. Without diving too much into the technical minutia, ESL software tools help engineers quickly model a complex system and simulate its behavior – without spending a ton of hours on its specific implementation details. Think of it as helping architects quickly sketch and visualize a large building before diving into the details of each and every part of its structure. ESL tools let engineers “play” with different concepts for a large electronic system, pick the best concept, and only then proceed through the arduous process of actually designing and building it.
The product I was hired to manage was supposed to provide a link between the ESL tool the company offered, and 3rd party hardware design tools that already existed in the market. I was very excited about the prospects of such a product, but for a while it seemed like I was the only one…
A couple of weeks after I joined the company, the engineering manager responsible for developing the product quit the company, taking half of our small development team with him. The remaining engineers on the team looked quite demotivated themselves, and I am pretty sure started looking elsewhere for a job.
It was hard to garner support for the project throughout the company. The project was generally viewed as an “interface” between our “high level” design tool and 3rd party “low level” design tools. And when engineers face the choice between enhancing and improving “our tool” vs. creating an interface to “other tools” – their preference is quite clear…
I could tell by the looks of other folks in the company that they thought my product was clearly doomed, and my days in the company were numbered. However the phrase that kept running through my mind at the time was: “It ain’t over till it’s over”.
I decided to write a whitepaper titled: “Bridging the Gap between Concept and Implementation”. It described the overall process of designing a complex electronic system – starting with the conceptual level, where key architectural choices are made, all the way through the detailed design level, where actual hardware is designed. It further described the need to develop an adequate testing framework that would ensure that both the high level model and the detailed implementation meet the desired functionality.
My whitepaper highlighted the gap that existed between our ESL tool and the other hardware design tools. The engineers who worked on the system architecture used our tool to capture the system functionality. Once their task was done, they “tossed it over the wall” to the hardware designers, who had to essentially start from scratch in a different design tool. The gap between the high level and the detailed design phases made the overall process significantly longer and much more error prone. However with the help of a “little interface” between the two types of design tools, we could dramatically reduce the overall design time, improve the final product quality, and save our customers a ton of money.
The value to the customer which was described in the whitepaper was quite straightforward. But it also pointed out the business benefits to our company. Given an interface to hardware design tools, our ESL product would get into the hands of many more hardware engineers, which meant growing the number of seats we sell, and increasing the value of each seat.
The project, officially named the “Hardware Design System”, eventually gained full management support. It became easier to recruit engineers to work on it, and our sales teams loved the prospects of making extra $$$. Once launched, the product exceeded all expectations and became one of the company’s main revenue sources. Not too bad for a “half dead product”…
I don’t want it to sound as if the whitepaper did all the “magic” by itself. It still took multiple internal meetings and heated discussions to get the message across and win support for the project. But I would say that the whitepaper laid the foundations for the whole internal campaign.
The same whitepaper, with a few modifications to fit it for external use, became the cornerstone of our outbound marketing campaign. It established the key messages, which were later used for developing all other sales collateral – presentations, datasheets, etc.
Granted, not every product development is driven by a whitepaper. But the basic tenants of ‘customer problem’, ‘alternative solutions’, ‘our solution’ and ‘why it’s better’ should be captured in every solid product requirement document (PRD). And once captured correctly, then creating a customer facing whitepaper should be mostly a “cut & paste” operation.
One of the challenging marketing tasks I personally came across has been ‘naming’. Assigning a name to a product, a device, a solution, or a company has been much harder for me than it looks. This is especially true when the name has to be associated with online presence – a web address (URL), a search keyword, or a social media term. When you search for a name that is catchy, easy to remember, meaningful, easy to spell, and has an associated domain name – the process can be lengthy and frustrating.
Assigning a name to a product, let alone a company, is a serious matter. A ‘naming consultant’ I once met called the process “verbal branding”. According to her, a ‘name’ should be an integral part of the company branding strategy.
Marketers often make substantial investments in building their company/product ‘visual brand’ through careful selection of graphics, color schemes, etc. They hire design experts to build the elements of the ‘visual brand’ – logo, website template, presentation templates, etc. In contrast, the process of selecting a name, particularly a product name, is sometimes handled as a popularity contest among company employees.
In my discussion with the aforementioned ‘naming consultant’ she pointed out that there are generally three types of names: Descriptive name, Suggestive name and Arbitrary name.
- Descriptive names are a succinct version of what the product or the company does; for example: ‘Intelligent Business Machines’ (IBM) for a company or ‘Integrated Services Router’ (ISR) for a product.
- Suggestive names provide a “hint” as to what the product or the company is about; for example ‘Qualcomm’ is a company that offers quality communication solutions, and ‘iPhone’ is a product that combines Internet services with a phone.
- Arbitrary names do not directly or indirectly describe what the product or company does. However if properly selected, they could have an effect on the audience. For example, the name ‘Verizon’ doesn’t describe a communication services company; however it resembles the word ‘Horizon’, and thus may benefit from a positive effect. Another example is the name given to the Intel microprocessor ‘Pentium’, which was a departure from the company X86 naming convention.
There are additional subtleties associated with company or product naming. But starting with a choice between a descriptive, suggestive or arbitrary name is a good place to start. Whatever you do, keep in mind that names tend to stick with a company or product for a while. The cost of changing those names increases dramatically over time. So don’t leave the name selection process to the very end…
Usually a lot of thought is given to choosing a company name. However product names are sometimes handled as an afterthought – a task left to be tackled right before the public launch. A “working name” is selected at the beginning of the development process, and that name somehow finds its way into the code, software menus, documentation, etc. Uprooting the “working name” and replacing it with the chosen “marketing name” can be a challenging task, especially when time is running out before the launch. As a product manager, you should invest in selecting the proper name early on, and make sure that all the teams involved get on board with the selected name.
Anyone in the company can come up with a product name, but it is important that a marketing professional is tasked overseeing the selection process. The team can follow the ritual of announcing a ‘naming contest’ where the winner gets a small prize (a free pizza…). Alternatively, you can hire a naming consultant, and task them with coming up with a list of recommended names. The process for name selection may depend on budget and timeline, but regardless – it should start early!
There is no single recipe for name selection; however there are a few common tasks involved in the process:
– Desired attributes: define the set of attributes the selected name should possess. This should preferably be done before any naming candidates are available. Think carefully about the desired attributes, list them, and if possible – prioritize them. Having a set of attributes will greatly help evaluate the proposed naming candidates. Some of the attributes are generic, while others are company/product specific.
- Generic attributes: these include elements such as: easy pronunciation – in target languages, straightforward spelling, avoiding negative connotation (in target languages), availability of domain name, etc.
- Specific attributes: related to the company or product at hand. For example: should the name reflect performance? Quality? Trustworthiness? Luxury? Affordability? Also, if there is a theme already adopted by the company (e.g. flower names), then new names must comply.
– Naming candidates: generating a list of naming candidates can be done in multiple ways. For example: brainstorming sessions; or theme-based searches (e.g. Greek mythology gods); team contest with prizes; or hiring a naming consultant. Regardless of the process chosen, it is useful to communicate the desired attributes as guidelines for suggestions.
– Top candidate(s) selection: using the list of desired attributes as a benchmark, the suggested names should be prioritized and top candidates selected. It is important to select more than one top candidate, since the subsequent approval process may disqualify some.
– Legal screening: the top naming candidates should go through a legal review process. Any trademark contention issues should be reviewed and resolved. The candidate list should be pruned down to those names that can withstand challenged from other companies. Note that the legal screening should be done in all key target markets.
– Internet screening: check if the candidate names can be associated with relevant domain names – especially important for company names. They should also be tested in multiple search engines and social media sites to detect potential contentions with existing names/keywords.
– Final selection: hopefully at this stage there are a couple of names which passed the screening process and can be presented for final decision by marketing and senior management.
As you can tell, the above process can become lengthy and convoluted. You may encounter barriers such as trademark issues or contentions in a particular target market – hence the suggestion to start the naming process early and in earnest. A good name can be a powerful branding asset, so it is well worth the effort.
While choosing a name is important, one must avoid the risk of “over naming”. This is particularly true for small companies, where the company name and its product name can be easily interchanged by customers. An example of blurring product and company names is Oracle Corporation. It was founded as Software Development Laboratories (SDL), later renamed as Relational Software, Inc. (RSI) and eventually named Oracle Corporation after its flagship product.
Likewise, if your company has a broad product line, naming every sub-product can be superfluous. Customers may remember the product line names, but sub-products names will be lost in the noise. You may still need to assign names to sub-products for logistical purposes (e.g. order processing), but those names should not be viewed and treated as a brand. The branding emphasis should be on the main product line, while sub-products can be simply given “descriptive names”.
At the end of the day, the product manager must decide where to put the emphasis on naming. Naming is part of the overall branding strategy, and should fit right into it. Spend the energy, time and budget on names that are critical to your brand – e.g. company name, or key product line name. Keep in mind that customers remember only a handful of names, so choose your battles wisely.