http://marketingsource.com/articles/ Articles at marketingsource.com Articles Library en-us http://marketingsource.com/articles/marketing/marketing-strategies/top-10-product-review-program-mistakes-part-1.html http://marketingsource.com/articles/marketing/marketing-strategies/top-10-product-review-program-mistakes-part-1.html Thu, 08 Jul 2010 17:34:29 -0500 The key to getting the best possible reviews is to create and execute a plan that is appropriate to meet your goals given your resources, budget and time constraints. This paper will summarize the top ten most common mistakes that we have seen companies make when seeking their reviews for their products.
Mistake #1: Launching the program after the product has already shipped
One of the biggest mistakes that companies make is that the review program ends up being an afterthought after the product has already been released, rather than a well-planned and coordinated effort up-front. This results in several problems:
• The product is no longer new, so your ability to get publications to review it diminishes significantly.
• The time to prepare materials adequately and set yourself up for a great review is reduced and the quality of the materials suffers as a result.
• The reviews are often not timed to coincide with the product launch marketing activities, and thus don't provide additional support and synergy to help get the initial revenues and sales going.
• Many times the company has to respond to negative reviews or competitive roundups that they weren't aware were going to happen. Once something negative is written and released about a product it is very difficult to turn around the perception that is created.
To avoid this problem begin planning your review program four months prior to the product launch. This will ensure that all of your PR and launch efforts can be leveraged, and will give you adequate time to prepare the materials and run a first-rate review program.
Mistake #2: Not being responsive to reviewers
Once you start a review program you have to be ready to respond instantly if questions or problems arise. You should have someone dedicated to getting back to the reviewer VERY quickly (within a half hour). Oftentimes if a reviewer encounters an issue with your product if you respond quickly and professionally to help them they will cut you some slack when they write up the review.
The worst thing you can do is delay getting answers to them. Reviewers are busy people. They are on deadline. They can't afford to have a machine crash on them, or to have to wait to get problems resolved so that they can finish writing up your product. When it comes to responsiveness think Nordstrom's - it will pay off for you.
Mistake #3: Inadequate review materials
Providing inadequate review materials is a good way to ensure a poor review. Your materials should include everything the reviewer needs: a reviewer's guide, FAQs, competitive information, product presentation, etc. These are the materials that the reviewer is going to leverage to evaluate your product. You can make it easy or difficult for them. The easier it is, the higher the likelihood of a good write up.
Mistake # 4: Providing the product to all reviewers at once
Don't try to roll out the product to twenty or thirty reviewers all at once. You won't be able to support all of them if there are problems, and the result can be a catastrophe. Instead roll it out to several "friendly" reviewers first (ideally as a beta under NDA), then prioritize the rest of your list of publications and provide it to them accordingly in phases over the next few weeks. This approach will allow you to address any problems and questions that come up early in the process so that the majority of the reviewers will have a positive experience.
Mistake #5: Putting a junior person on the job
Many of our clients think that a review program is something that simply isn't that important - until they end up with negative reviews and have to scramble to try to fix them. Your review program may be the MOST important marketing activity for your product. As such, make sure that you put a very senior person on the job.
The person responsible for the review program needs to be able to answer tough questions and needs to be responsible and responsive. Make sure that the review program is their number one priority for two to three months after the product first ships - the result will be great reviews that pay off.
Next month we'll cover the remaining five mistakes...
]]> http://marketingsource.com/articles/marketing/marketing-strategies/top-10-product-review-program-mistakes-part-2.html http://marketingsource.com/articles/marketing/marketing-strategies/top-10-product-review-program-mistakes-part-2.html Thu, 08 Jul 2010 17:30:57 -0500 Mistake #6: Underestimating the time required to manage the program

Review programs take far more time to manage than most people realize. Creating all of the materials, sending out evaluation copies, tracking progress, following up with reviewers, troubleshooting problems, etc. can take twenty to thirty hours per week or more. Don't make the mistake of thinking this will only take a few hours per week - you'll find that you end up being unresponsive to the reviewers and they will treat you accordingly in their reviews.
Mistake #7: Not addressing the competition
It is very common for a company to release a new product, ignore the competition and then have their product show up with an unfavorable comparison in product "roundup" articles. This is a naive approach. Publications like to categorize and group your product with similar products and include them all in one roundup piece. If you fail to acknowledge your competition and fail to present a compelling competitive argument then you are leaving it up to the publications (or your competitors) to set the terms for comparison and you will likely lose.

Tell the press what category you are in, who your competitors are and why you beat them. Give them a competitive comparison chart. Make your competitors respond to your claims. Chances are if you are better prepared than they are the reviewer will use your materials to create the review criteria, and you have a better chance of winning.


Include a competitive comparison chart that shows why your product
is superior to other solutions (this one is in the Product Review Program Toolkit).
Mistake #8: Undefined goals beforehand
Many companies run review programs without clearly defining their goals up-front. As a result they are often disappointed with the results.

Get clear about what you want to accomplish. How many reviews do you want to receive? What publications are most important to reach your target market? What are the top three messages you want the publications to repeat about your products? Are you trying to use reviews to drive revenues? If so, how many sales are you expecting? Are you trying to re-set the competitive landscape so that your product is the favorite?

Setting goals like these and making them as concrete as possible allows you to do a reality check when you are writing your review program plan. If your goals are ambitious make sure you have enough time and resources to achieve them. Don't rely on wishful thinking here - nothing can upset your company and team more than receiving poor (or no) reviews when you all believe you have a winning product.
Mistake #9: Lack of relationship building beforehand
One critical success factor for good reviews is to make sure that you have built strong relationships with reviewers before they receive your product for review. The person running the review program should go on the press tour, meet the reviewers and start to build relationships with them. Email the reviewers before, during and after the review to let them know you are there to help in any way. Get to know them - ask their opinions about the market and other products.

Building relationships like this can save you if your product does have some problems during the review process. If you have built some rapport, shown you are responsive and shown you are on top of things oftentimes a reviewers will give you some leeway if they know you. If they have never met you before and there is a problem you may not be given the chance to ask for forgiveness. Also, if you get to know them well they may call you for an opinion when your competitor releases a new product, giving you the chance to put the best possible spin on how your product is superior.
Mistake #10: No reviewer's guide
Writing product reviews is difficult and time consuming. Your goal with a review program is to provide the reviewer with absolutely everything they need to make it easy for them to do their job. Reviewer's guides are an excellent way to do this, and can be a good single source of all of the information they need. Don't make the reviewer search through your website or other places for answers - give them everything in one reviewer's guide. Also, provide the reviewer's guide to them in electronic format so that they can borrow text from it to use in their articles (for features and benefits or other areas).

If you provide an excellent reviewer's guide, build up a good relationship and do a great presentation and demo on the press tour you will sometimes find that the reviewer doesn't feel a need to do a thorough analysis of your product. They may simply read the reviewer's guide and give you a positive write up without ever installing or using the product.
]]> http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams.html http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams.html Thu, 08 Jul 2010 17:26:14 -0500
Of course, some of the engineers I've worked with haven't been of this same mindset and were quite difficult to work with. Oftentimes in the past they had bad experiences with Product Managers or Marketing people who weren't straightforward with them (or were simple incompetent and didn't know what they were doing), and as a result they either didn't see the value added or weren't willing to trust and take a team approach. (Ironically many of the best engineering teams with the most brilliant engineers often end up with this attitude, becoming "Primadonnas" as a result of management telling them that they are the most critical asset of the company).

Since we all as Product Management professionals may end up working with less-than optimal engineering teams at some time, I thought I would write an article that covers some of the "Games Engineers Play". (i.e. the popular book "Games People Play"). Following are a few of my favorites - things that have happened to me and how I might deal with them differently now.

Game # 1: Redefining Alpha or Beta criteria at the last minute

This is one of the oldest tricks in the book. The team is approaching a critical milestone date for having the beta release ready. Management is breathing down their neck to get the product out and not slip the schedule. The team isn't going to make it, so what do they do? When the date comes they go ahead and declare they have reached beta anyway. At this point you may hear things from them like "We only have 3 fatal crashing errors left that need to be fixed" (as if this is a good thing) or "The two remaining features that we left out are really easy to implement, so we decided not to hold up beta and to just slip them in before the Golden Master final release" (as if a Beta release can be ready without being feature-complete).

Probably the most effective technique for heading this off at the pass is to make sure that in your MRD (or PRD) and testing plans you have specific criteria defining what Alpha and Beta are. Put this in writing and get it signed, and make sure that you remind the team about it every few weeks as the project moves forward.

Some of the criteria might include the following language:
- The following required features must be implemented and working (X, Y, Z)
- All fatal bugs that crash the user's system must be fixed
- Product Management, QA and Engineering must all agree that the software is ready for beta release and sign off on it
- The product must have been tested on the following systems before beta can be declared (X, Y, Z)
- N customers must have successfully run the software for N days at their sites and must agree that the software is ready to be declared beta
- Performance must meet the following criteria for specified tasks (X, Y, Z)
The list could go on, but you get the idea. Note: the closer you get to deadline dates, the more difficult creating this list and getting agreement will be.

Game # 2: Product Management gets to choose

This is actually a common sales and negotiation tactic, but Engineers can be masters at it too. It goes something like this. You are approaching the Golden Master date and the team has a ton of work remaining in order to make the release happen on schedule. Around this time you get called in by the lead engineer, Director or VP of Engineering. They explain to you that the release will make the date, but that they would like you to decide which is more important, having X or Y. X or Y in this case could be performance, key features, compatibility, full QA and testing, or a variety of other things. But the point is that you as the Product Manager get to make the call (of course what they are really asking for is your blessing that not everything will be there but customers will still find it acceptable.)

This is a difficult situation, especially if you have a team that you really work with well. You may have to sacrifice some of the hard won respect and close relationships you've worked to form with the engineers. After all, you are being put in a situation where you have to point out that they are not making their commitments (and they may be excellent engineers that you respect and enjoy working with).

The best defense in this situation is to calmly state that the release does not meet the agreed upon goals and that rather than choosing between 2 alternatives that are not at all viable for the market you need to see a plan that gets the release back on track. This probably won't go over well with your team or upper management, but someone has to stand up and be the voice of the customer. Thus is the life of a Product Manager.

Another way to deal with this situation is to turn it back around. Tell both the engineers and the management team that from your point of view there are really three choices: 1.) release a product that doesn't meet market needs 2.) miss the schedule or 3.) ask the engineers to come up with an alternative plan to remedy the situation. I've been amazed by how resourceful my teams have become when upper management has indicated that they have to come up with a "Plan B". Remember, Engineers are master problem solvers, and they may come up with a completely new way to get the product back on track if you use this approach.
]]> http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams-part-2.html http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams-part-2.html Thu, 08 Jul 2010 17:22:10 -0500 Game #3 Changing Feature Definitions
Imagine this - you deliver a great MRD that clearly spells out the market needs and required features for your product. You sit down with your team and talk it through and they deliver a functional spec and schedule that appear to meet what you need. Part of the spec calls out one or two of the features by name (XYZ) that you specified in the MRD as being high priority (i.e. would not ship the product without them), and the team agrees that these are critical and must be in the release.
Things are going fine until you see the first working version of the product. The feature that you had clearly agreed on is there, but it doesn't deliver anywhere near what you intended at all. You bring this up with the team get the response that "we thought that's what you meant by XYZ". To you it was so obvious what you meant that you didn't go into great detail in the MRD or discussions. But nonetheless there was a disconnect and now you have a product that may not be viable or that may need to miss its schedule to meet market needs.
This situation is one reason why it is critical to deliver a well-written MRD that spells out in as much detail as necessary exactly what your customers need. One technique that will help you to do this is to create a brief glossary of terms as part of your MRD and review it with the team. Scan your MRD for any features or terms that might have any ambiguity, write down a precise definition of exactly what they mean and then review it with the appropriate engineers. (thanks to Juan Veiga of Vienna, VA for sending in this tip).
Game #4 Features, Schedule, Performance: Pick Two
One of the engineering managers I used to work with had this statement taped on his office window. Frankly, I don't blame him - in the company we worked for his priorities for the product would be constantly shifted - one week he would be asked to add significant new functionality, then the next week management would insist on pulling in the schedule.
The challenge here is if a statement like this is presented to you as a Product Manager in absolute terms. The fact is that each one of these elements can be broken down into smaller, more manageable chunks and handled accordingly. For example, performance improvements can focus on the top five most common tasks that customers perform, rather than sweeping changes across the whole product. And a good engineering team can always work with you creatively to see if there is a slightly reduced feature set or a shift of team resources to make the feature set and schedule stay on track.

Game #5 Using The MRD Process To Stall For Time
Occasionally you'll run across a team that asks for multiple rounds of clarification on the MRD you have delivered. This may be warranted if your original MRD was not well-written and didn't deliver what they needed. On the other hand it may be a tactic they are using to buy some time. Your team may ask for an extreme amount of detail or they may delay meetings and push the process out accordingly.
One of the teams I worked with kept the process going for a good two months before I caught on. In reality they were actually doing quite a bit of background work on other projects and stalling for time before they would have to deliver a spec and be pressed to commit to a schedule.
Of course, when the schedule was published they then pointed to my group and said that if the MRD had been delivered on time the schedule could have been pulled in, but now there was nothing they could do given the realities of how long the development would take.
In retrospect, to avoid this situation I would have insisted that the team make getting to the MRD signoff and spec/schedule agreement their highest priority. Setting milestones for delivery of the MRD and spec and setting the expectation in the company that they would be met would have helped control the process, and I could have put up some red flags if they were not meeting their side of the commitments.
Next month we'll wrap up this series on working with difficult engineering teams. If you've got a tip or idea that has worked for you send it to us and we'll include it in the article.
]]> http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams-part-3.html http://marketingsource.com/articles/marketing/marketing-strategies/working-with-difficult-engineering-teams-part-3.html Thu, 08 Jul 2010 17:17:52 -0500 In case you missed the first 2 articles in this series, here are the first five games that we covered:
Game # 1: Redefining Alpha or Beta criteria at the last minute
Game # 2: You get your choice
Game #3 Changing Feature Definitions
Game #4 Features, Schedule, Performance: Pick Two
Game #5 Using The MRD Process To Stall For Time
So on to the final two games (and these two I sincerely hope you never have to play)…
Game #6: Sorry, but we have the final word
One engineering VP that I used to work with brought me into his office at one point about halfway through a major project. As with any software development effort, there were several points of contention between Product Management and Engineering. We had been through one of the issues half a dozen times and I had voiced my opinion that the release would fail without a specific critical feature that Engineering had originally agreed on including but now did not want to deliver. The reality was that it was a very hard coding challenge, and would have put their schedule commitments at risk. Nonetheless, it was key for our customers, so I was insisting on it.
After politely explaining his position, the engineering VP informed me that he was "Sorry, but we have the final word on this. You will have to live with not getting what you want". I had suggested several reasonable alternatives - scaled down versions of the feature, pushing the schedule out if necessary and even funding a contractor to work on the feature. But he had made up his mind.
Defeated, I played the only card that I could. I cut the revenue forecast by 80% and let management know to lower their expectations. After all, this was a critical feature to drive upgrades, and without it there was little reason that customers would actually pay for a new version. Luckily I had a signed off MRD and spec as a backup that included the feature, but nonetheless I had been put in a difficult position.
In the end I lost on this one. The product shipped without the feature, and I was still held accountable for the original revenue forecast.
Sometimes there are just some things that are out of your control.

By the way, this is one reason why Product Management should NEVER report into Engineering.
Game # 7: We Don't Talk To Marketing
Long ago when I was first starting my career in Product Management I actually had an engineering team that refused to talk to anyone in Marketing or Product Management. The previous Product Manager had been somewhat of a tyrant, making ridiculous demands, oftentimes having completely disregard for working as a team. As a result the engineers would hold secret meetings to discuss the feature set and ship dates. They would not answer the phone or reply to emails. They would keep documents hidden so that no one outside of the core engineering team could comment or even know what was in the release they were working on.
I have to admit, this was one of the most extreme cases of dysfunction I have had to deal with in my career. Nonetheless, I had to find a way to make it work. Luckily I had a very seasoned manager who supported me (and I also happened to be working on several other products concurrently.)
To solve the problem I pulled the engineering manager aside and informed him that my priorities had been changed to focus on the other products I was managing. As a result, even though I thought what they were working on had potential, I didn't think there was any way that the company would ship it since there wouldn't be any Product Management or customer input during development. I also added that even if it did ship the company wasn't likely to highlight it or market it, so few customers would end up using it in the end.
The product did end up shipping. It sucked. Customers were unhappy.
In the Product Management game you win some and you lose some.
]]> http://marketingsource.com/articles/writing/writing-benefits-for-your-features.html http://marketingsource.com/articles/writing/writing-benefits-for-your-features.html Thu, 08 Jul 2010 17:12:43 -0500 Here's an example. Back when I was the Product Manager for the Human Interface for the MacOS at Apple, the company would routinely release new technologies with each operating system release. Since many of these technologies were very "cool" by technology standards they would get talked about as feature. A few examples include QuickDraw GX and QuickTime.
Now for those of us who are more technical geeks, or for those who followed what Apple was doing we immediately understood what Apple meant when they said "includes the new QuickDraw GX graphics and printing architecture and version 2.0 of QuickTime". But for the other 99.999% of the world, stating some benefits would have answered the age old question of "So why should I care" (and "So why should I upgrade").
When writing effective benefits statements think of the phrase "Which means that you can". What do I mean by this? To give you an idea I'll use the 280 Group as an example (this is the part of the article where we do the shameless self-promotion).
One of the "Features" that we promote is that we provide "Hand Picked Marketing & Product Management Consultants and Contractors". On its own you might say "So What?", but here's the benefit statement.

FEATURE:
"Hand Picked Marketing & Product Management Consultants and Contractors…"
Which means that you can…
BENEFIT
"…save the time and hassle of doing the work yourself to find a qualified consultant, check their references, etc."

Here's another example:
FEATURE:
"Seasoned Professional Consultants…"
Which means that you can…
BENEFIT
"…rest assured that you will have a committed and professional resource to see the project all the way through and get excellent results."

The "Which means that you can" phrase helps bring out the real value to your customers. They don't care about technology or features if there isn't an associated benefit to them. This may seem like Marketing 101, but it is amazing how many companies neglect this when writing their marketing content.
To wrap up, let's go back to the Apple example. Now if I told you that you should upgrade to the newest version of the MacOS because you'll get QuickTime 2.0, which means that you can watch movies on your computer that are twice as big and are much higher quality, would you be a little more prone to want to upgrade?
]]> http://marketingsource.com/articles/marketing/marketing-strategies/writing-effective-benefits-statements-how-to-turn-features-into-compelling-benefits-that-matter-to-customers.html http://marketingsource.com/articles/marketing/marketing-strategies/writing-effective-benefits-statements-how-to-turn-features-into-compelling-benefits-that-matter-to-customers.html Thu, 08 Jul 2010 17:08:39 -0500
Here's an example. Back when I was the Product Manager for the Human Interface for the MacOS at Apple, the company would routinely release new technologies with each operating system release. Since many of these technologies were very "cool" by technology standards they would get talked about as feature. A few examples include QuickDraw GX and QuickTime.

Now for those of us who are more technical geeks, or for those who followed what Apple was doing we immediately understood what Apple meant when they said "includes the new QuickDraw GX graphics and printing architecture and version 2.0 of QuickTime". But for the other 99.999% of the world, stating some benefits would have answered the age old question of "So why should I care" (and "So why should I upgrade").

When writing effective benefits statements think of the phrase "Which means that you can". What do I mean by this? To give you an idea I'll use the 280 Group as an example (this is the part of the article where we do the shameless self-promotion).

One of the "Features" that we promote is that we provide "Hand Picked Marketing & Product Management Consultants and Contractors". On its own you might say "So What?", but here's the benefit statement.

FEATURE:
Hand Picked Marketing & Product Management Consultants and Contractors…"

Which means that you can…

BENEFIT
"…save the time and hassle of doing the work yourself to find a qualified consultant,
check their references, etc."

Here's another example:

FEATURE:
"Seasoned Professional and Experienced Consultants…"

Which means that you can…

BENEFIT
"…rest assured that you will have a committed and professional resource to see the
project all the way through and get excellent results."


The "Which means that you can" phrase helps bring out the real value to your customers. They don't care about technology or features if there isn't an associated benefit to them. This may seem like Marketing 101, but it is amazing how many people neglect this when writing their marketing content.

To wrap up, let's go back to the Apple example. Now if I told you that you should upgrade to the newest version of the MacOS because you'll get QuickTime 2.0, which means that can watch movies on your computer that are twice as big and are much higher quality, would you be a little more prone to want to upgrade?
]]> http://marketingsource.com/articles/marketing/marketing-strategies/training-product-managers-getting-product-managers-up-to-speed-with-new-software-and-processes.html http://marketingsource.com/articles/marketing/marketing-strategies/training-product-managers-getting-product-managers-up-to-speed-with-new-software-and-processes.html Wed, 07 Jul 2010 18:33:31 -0500 But for product managers, the concept of training and getting up to speed on new or existing tools isn’t a familiar one. Most product managers learn the software they use on a daily basis completely on their own. Whether it is Microsoft applications like Office, Visio or Project, most of the time product managers are left to their own devices to learn how to use the tools that are critical to their day to day success.
For desktop applications, this has been the way of product management life. But as new enterprise applications become available that are more powerful and useful, it’s important to give your team of product management professionals the support they need. This is even more critical if the software is integrated into your existing or new product processes that span across different functional groups in your company.
Following are a few suggestions for how to be more effective if you are implementing new software and/or associated processes at your company:
1.) Make learning and using the core software tools and processes part of your quarterly MBOs, goals and objectives. Even better, make it a part of employees’ annual review goals so that they are clear that it is a critical part of their job they will be judged on. That way they’ll know that if they aren’t proficient in the applications that are critical to their job, or don’t follow the product processes, they won’t get rewarded.
2.) Give your staff dedicated time to learn the new software. Force them to go off-site to a place where they have to turn off their cell phones and can’t access email. Without this dedicated, non-interrupt-driven time, learning the software will be given little less than lip service.
3.) Make sure that when new employees are brought on board they understand what tools and processes they are expected to use, and give them the resources they need to be successful. Provide them with training materials and pair them up with others in your group that are proficient and can help them if they run into questions or problems.
4.) Get full buy-in for the new processes and software and the training time required. Make sure that upper management as well as mid-level directors and product line managers understand how the new software fits into your product process, and that it is critical that your teams be proficient with it.
By using some or all of these suggestions above you’ll be sure to get the most of out of new software. And you’ll make sure your Product Management teams know what is expected of them, and can integrate new software and processes into their jobs quickly and easily.
]]> http://marketingsource.com/articles/marketing/marketing-strategies/truth-in-marketing-or-not.html http://marketingsource.com/articles/marketing/marketing-strategies/truth-in-marketing-or-not.html Wed, 07 Jul 2010 18:28:42 -0500 Years ago when I was working at Apple as the MacOS Human Interface Product Manager I remember talking with Chris Espinosa, one of the first Apple employees (and still there). We were discussing Apple's latest advertising campaign at the time in which it blatantly put down PC users, telling them they had made "the wrong choice".
It was a hard-hitting campaign that included many good facts to support this argument, but we both agreed that insulting your potential new customer's intelligence was NOT the way to convince them to switch over. After all, customers had made a decision to go with the Windows platform, and telling them they had made a stupid decision wasn't going to give them the ego stroke or the corporate ammunition they needed to consider switching.
Enter Apple's latest campaign, which I believe not only insults potential customers but also violates the law of marketing congruence.
Now before I go any further don't get me wrong - I am a Mac fan, and I believe that the OS and integration with the hardware provides a great experience. I use a dual-processor OSX Mac in my music studio and it provides outstanding performance and results, with very few problems.
That said, I use Windows for work with clients, and have since I left Apple in 1995 (the day Windows 95 shipped). Using Windows on my ThinkPad provides me with a very productive environment - as a business user it is my tool of choice.
Now that you know where I stand (I'm all about using the best tools to get the job done quickly), let's look at Apple's current "I'm a Mac, I'm a PC" ads.
Psychologically the first impression from these ads implies that the PC user is an incompetent and misinformed geek. The Mac guy, on the other hand, is a young, smart, cool guy who is portrayed as obviously knowing "the truth". This sets up an instant conflict in the mind of anyone who is relatively happy using a PC - who would want to be labeled as that geeky guy? But worse than this, the Apple commercials cross the marketing congruence line.
If you are fairly knowledgeable once you watch a few of the Apple ads you quickly catch on that the advertising is too far out of touch with reality to be believable. Again, one of the fundamental tenets of good advertising and marketing is that it has to be congruent enough with reality - if you stretch it too far people will catch on, your credibility will be shot and you won't be considered as a choice.
I could go through and argue point-by-point about what Apple is trying to get across in each of the ads (fewer viruses, run both operating systems, etc.), but that's not the point of this article. Some of their points are absolutely correct, but for me I know in my gut that the experiences they are describing with Windows versus a Mac are too exaggerated and don't match my truth. And I have to tell you, as an educated user who knows quite a bit about using both operating systems in a real-world environment I feel insulted and flip the channel or mute the sound when I see their ads.
Maybe the masses don't feel this way and won't catch on. But if the masses ask people who are knowledgeable and open-minded for a recommendation about what to buy then the campaign could completely fail. It's quite possible that the ads will only ring true to the Mac faithful.
So what's the moral of the story? When you are creating your core marketing messages and campaigns if you want to win the hearts and minds of potential customers and convert them to your solution, your marketing claims have to match reality closely enough. Don't claim to have a feature that you don't have working yet. Don't tell prospects that you can do something you can't (because they WILL find out you can't). Don't claim your competitors can't do something that everyone knows they can. And most important of all, don't insult your prospect's intelligence.
]]> http://marketingsource.com/articles/marketing/marketing-strategies/using-themes-to-focus-product-releases.html http://marketingsource.com/articles/marketing/marketing-strategies/using-themes-to-focus-product-releases.html Wed, 07 Jul 2010 18:23:29 -0500 process is to use themes.

This typical product planning process of gathering data and delivering an MRD/PRD presents 2 challenges:
1.) How does the Product Manager prioritize, rank and make sense of what sometimes amounts to hundreds or thousands of feature requests?
2.) When new features are proposed after the functional spec and schedule are frozen, how can they be evaluated to determine whether it is reasonable to consider risking the schedule to include them?

Using a theme for your product can make both of these dramatically easier.

To create a theme take the original list of feature requests and begin to classify them into similar categories to see if any trends emerge. It might be that the majority of requests are for product stability or for increased performance. There might be a trend towards better security in the product, or a trend towards multi-user collaboration. The key is to identify whether there are one or two high-level categories that have a large number of features that fall under them.

If you can identify one or two, then you can go to your team and propose using a theme for the release. Your theme might be “Security and Performance”, “Secure Collaboration”, “Extreme Ease of Use” or something else in line with what you are trying to accomplish. Come up with a good name for it and then meet with engineering and other
teams who have a stake in the product and get them to buy into this as the primary theme for the product.

So why go to this extra work? There are many reasons. First, writing the MRD or PRD will be far easier because you’ll have a focal point around which to make decisions and tradeoffs. You’ll have some context for making your high-level decisions about what is in and what is out of the release. Second, when one of your engineers or salespeople insists on adding a new feature late in the development process, you can ask whether it falls under the theme of this release. If it does, maybe it should be considered. If not, it is much easier to defer it to one of the next releases. (you may even want some high-level theme names to use as placeholders for upcoming releases as well so that people can see where their deferred suggestions might fit into the future product roadmap).

I have used this approach several times as a Product Manager with great success. One product that I used themes on was an all-in-one Internet appliance for small businesses named the Whistle InterJet (server, router, etc.). The theme for one of the releases was “Total Control”, which included being able to monitor and control website usage by employees, perform basic spam blocking, and limit the hours of usage of the device to business hours. When new feature requests came in we as a team could immediately ask “Does this fit under the theme of Total Control?” If so, then we evaluated whether it was worth risking the schedule and what the resource implications would be.

Oftentimes the team was much more understanding if their feature wasn’t included because they saw that it didn’t fit in with the theme, yet they could see where it would fit in the future. Of course, not all of the new features will fit cleanly under the theme you choose. There will be some required features that have to be put in even if they have nothing to do with the theme (bug fixes, must-have requests to close deals, competitive pressure, etc.). But using this approach will help your products and team to stay more focused and on track, and will result in a higher likelihood of meeting the schedule and delivering a great product.
]]>