280 Insider Newsletter
February, 2005
- Writing Benefits For Your Features
- Working With Difficult Engineering Teams Part 2
- New! Product Manager's Toolkit v1.5
- Hot Companies: GamesGrid
Writing Benefits For Your
Features
One of the most common traps that marketing folks
get into when working on technical products is focusing on the features
of a product rather than the benefits to the end user. Features are great
- we all want to know what is in a product and want to be able to compare
it to other products. But at the same time there are many features that,
while the benefits may be obvious to the Marketer or Product Manager working
on them, may leave potential customers wondering why they matter.
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?
Working With Difficult Engineeering Teams Part
2
Last month we started the first part in a series
about working with difficult engineering teams. As we mentioned in the
previous article some of the engineering teams that you'll work with as
a Product Management professional will be very straightforward and a pleasure
to work with. When you work with a team like this Product Management can
be very rewarding, and you can really make an impact on the marketplace.
On the other hand, there will be other teams that present more of a challenge,
and thus we continue with our article on "Games Engineers Play".
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.
New! Product Manager's Toolkit v1.5
We are proud to announce that we have released a new version of the Product Manager's Toolkit this month. Version 1.5 includes updated MRD and PRD document templates as well as a totally revised Business Case template.
The Product Manager's Toolkit comes with unlimited upgrades,
so all existing customers will be notified shortly about how to obtain
the newest version. We are also offering training based on the methodology
in the toolkit - contact us for details.
Product Manager's Toolkit
One of the companies we are watching is GamesGrid. Formed by an old Apple colleague of mine named Mark "The Red" Harlan and fellow Apple alum Chris Derossi, GamesGrid is an online poker site that promises to change the way people gamble online. If you've ever played poker on a Friday night with your friends you realize that winning money is only a small part of why you enjoy it - much of the fun comes from the interaction with the other players and the environment that is created. Mark and Chris (both human interface and usability wizards) are seeking to recreate this social environment in a virtual manner. My bet is they will come up with something very interesting.
Their main website is at www.gamesgrid.com - there are already other online games there, and the poker section will be up and running shortly. They've also written a book to promote the site and teach people how to play: "Winning at Internet Poker For Dummies" - available on Amazon.com.
Resources
BLOGS/ARTICLES
White Papers
PM 2.0 Newsletter
Product Management 2.0
Cool
Products Blog
Marketing
Strategy
Opinions
OTHER
SV Marketing
Directory
Seth
Godin Bull Market
Product
Mgmt Assn's
PM Job Description
Companies to
Watch
PM Software Comparison
PM Webinars
BOOKS
Book
Reviews
Product
Mgmt Book
Product
Marketing Books
Best
Marketing Books
FREE
TOOLS
MRD Samples
Feature
Priority Matrix
Dev Program Roadmap
Bug & Feature Database
AdWords
ROI Calculator
Competitive Matrix
Launch Marketing Budget
Adwords Strategies
More Details...
Bundle! (save $75!)
Training & Templates