Forbes.com recently interviewed me about the software and online services I use to run Sure Product Consulting.

They were interested in my perspective as a self-interested small business owner and as an expert in evaluating, defining and launching software products with real business value.

Check it out: “A Software Maven Picks Her Tools,” by David F. Carr, Forbes.com, June 18, 2010.

I especially like the part where they refer to me as a “software maven.” 

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Forbes.com – Talking about software for small businesses

A colleague asked me this the other day: If a company is pursuing a “freemium” business model, how should they determine the optimal mix of features to offer in free vs. paid software?

It’s a good question. Freemium – where a product is made available in both a free and paid-for version – is a scenario I’ve encountered quite a few times and one that’s becoming increasingly common.

Today, customers pretty much expect free versions from any kind of online service. Free versions are also becoming common in installed software, even in the case of very high-priced, server-based enterprise software.

The free vs. paid question is worthy of an entire project, but here are some high-level thoughts that may be helpful to your decision calculus.

First, there are three basic kinds of “free” software, though some companies offer a hybrid:

1. Free product is functionality-limited.
2. Free product is simply a limited-time trial of the paid product.
3. Free product is identical to the paid product but includes neither customer support nor indemnification.

I strongly recommend staying away from offering only Option #3. In my experience, most companies that start this way eventually move to option #1 (functionality limited). Option #2 (time limited) is easiest to implement but may not garner the same widespread installed base as Option #1.

If you choose Option #1 (functionality limited), expect that all your customers will try the free version first. If they like it, fewer than 10%—often fewer than 1%—will go for the paid version. (Rarely will anyone to go for the paid version out of the gate.) After anywhere from a week to a few months to evaluate its benefits, the afore-mentioned small percentage of customers will upgrade to the paid product.

With this “typical purchase pattern” in mind, you’ll want to consider the following:

1. Be sure you understand your product’s value proposition and benefits. Extra research to nail that down is worth it at this stage.
2. Make sure the free version is a pleasure to use and delivers real value (see the previous bullet). If the user experience is not very good and if benefits take longer to percolate to the top than expected,then  don’t offer a free version to begin with. You’ll do more harm than good.
3. The free version must lack key functionality that is in the paid version. The paid version should provide a “pain killer” that the free version does not. The paid version shouldn’t merely offer a “vitamin,” it should deliver real pain relief. Otherwise, users will never upgrade. 
4. If possible, encourage customers to integrate the free product into their business processes and IT systems, so that it is hard to remove. Then, when they hit the above-described pain point, they’ll buy the paid version instead of starting a selection process with multiple vendors. For example, you might want to make a free online product easy to integrate with the company’s single sign-on systems and other sercurity protocols, or maybe make it easy to integrate with in-house databases and services.
5. The differences between free and paid versions must apply to a customer who has been using the free product for two to three months. This sounds obvious, but it is amazing how many companies botch this. For example, if you offer any of the following features, tools, and support, then they should be available in the free version and not limited to just the paid version. Remember, the whole point of Freemium is to get as many people as possible using your product. Without the following features, you’ll needlessly limit your audience:
   • Installation and configuration wizards.
   • Access to APIs and tools for developers. A goal is to have your customers’ programmers embed the free product into their business processes if possible (see previous bullet).
   • Documentation on setting up the product and integrate it with business processes / IT systems.
   • Assistance with getting started. For example, don’t limit access to “getting started” user forums to paying customers.
6. Be sure that it is exceedingly easy to upgrade to the paid version, even if the free version has been programmatically embedded into business processes and IT infrastructure. If customers must rewrite code, install new software, or implement a migration process in order to use the paid version, they will likely continue to use the free version—or contact your competitors.

Finally—and this is important—realize that if you make too much available for free, it is very hard to put the genie back in the bottle—unless users understand that you are offering a time-limited free trial from the get-go. People are furious at Ning, for example, for charging formerly free communities. I am not sure the brand or company will survive. In fact, it appears that competitors are already hovering to snap up disgruntled customers.

Clearly, I could write a dissertation on this. Maybe I already have. Let me know if these high-level thoughts are useful to you.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

“Freemium” Business Models – How to Decide What’s Free and What’s Not

I’ve said it before, and I’ll say it again.  All product managers should develop well-researched and well-supported product strategies, even if your boss is not requiring it.  It’s difficult to make the time, especially with the dozens of activities that product managers are usually simultaneously juggling, but it must be done.

Why?

1. Otherwise, you will only arrive at your desired destination by happenstance.
2. Otherwise, all your time will slip away fighting fires – many of which would never have started to burn had a clear product strategy been in place.

80% of the value of creating a product strategy is for the product manager. It clarifies your thinking, challenges you to come up with new ways of addressing problems, helps you better express WHY this is the best plan to all concerned, and gives you confidence that your plan is good, which in turn gives you the motivation to doggedly pursue your vision for the product.  You will need this motivation.  In fact, the best product managers are beyond “motivated” – they are “passionate”.

The other 20% of the value is in communicating your vision and your plan to others – the developers, the sales people, your customers, the market in general.   Having done your homework, you’ll be confident with yourself, credible with others, and convincing even to the skeptics and folks who like to play “stump the chump”.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Why You Need a Product Strategy. Now.

In Silicon Valley, every company wants to produce white papers. They’re considered an essential part of marketing technology products, and they’re on the checklist for every product launch. Beyond the launch, Product Management and Product Marketing typically want to provide prospects and customers with a wide variety of white papers on product-related topics.

White papers have their strengths: you have several pages to describe your products, their benefits, and their underlying technology to an interested audience. Customers or prospects in the early stages of learning about your sector get educated about why their problems should be solved, different approaches to solving them, and how to evaluate these approaches. In the case of experienced customers, a good white paper can further establish your credibility and deliver convincing arguments about why your company’s approach is superior. Done right, white papers can be great marketing tools and often generate more qualified leads than any other source.

Unfortunately, though, companies often squander this opportunity. Most technical white papers are never read, even if readers actively sought them out. Typically, in the software industry, many readers stop reading part way through the first page, overwhelmed by verbose, jargon-filled content and wondering how it applies to them.

White papers can avoid this fate and be much more effective marketing tools if you 1) do some up-front thinking, 2) carefully craft your arguments and provide proof points, and 3) use a good writer.

In the case of point #1, up-front thinking, Sure Product Consulting asks clients who want us to write their white papers the following questions. Prior to our even bidding on the project.

1. Why do you want a white paper?
2. How should this white paper be different from your marketing collateral? Does it have different goals? A different target audience? Will it have different messaging? Different content?
3. How should this white paper be different from your competitors’ white papers?
4. What are you going to do with the white paper? Give it away at conferences? Offer it as a “freebie” to customers who subscribe to your monthly newsletter? Or just make it a website download for anyone who wants it?
5. How critical is it that customers actually read the paper, digest it, and remember its main messages? (This may seem like a silly question, but you’d be surprised at how often the real goal is to collect email addresses instead of truly communicating ideas.)
6. How will you measure the success of this white paper as a marketing tool? (Qualified leads generated? The customer’s ability to remember key messages? Sheer number of email addresses collected?)
7. Why do you believe a white paper is the most effective method to reach your goals?
8. How “neutral” do you want your paper to be? Neutrality increases your credibility. But it also means you must even-handedly discuss alternative ways to solve customer problems—perhaps even naming your competitors.
9. If there is just one message you want readers to take away, what is it?
10. What tone—informal or formal—should your white paper take? By “informal,” I mean using “you” and “we” and not worrying very much about dangling prepositions and split infinitives. In the software industry, most white papers refer to the company in the third person, rather than “we.” They talk about “customers,” rather than “you.” In our experience at Sure Product Consulting, most software companies prefer this more formal writing style, even though readers are more likely to actually read and retain the messages presented more informally.

If you get clear on these issues before you start to write, your white paper project will go much more smoothly. You might even eliminate a feedback round or two, which has been our experience. The result will be a better and more effective white paper.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Product Marketing 101: Writing White Papers for Software Companies

I am much delinquent in posting this, but check out the recording from the webinar, Five Common Challenges for Product Managers in Agile Teams, given by Steve Johnson and me on May 22, 2009.

You can hear/view it on Pragmatic Marketing’s website, or on iTunes.  Or, just check out the slides here.

It was really fun to work with Pragmatic Marketing and the super-funny Steve Johnson on this.  And I’ve really enjoyed chatting with some of the listeners in the aftermath of the webinar.

I’d love to hear your feedback in the comments!

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Webinar Recording: Five Common Challenges for Product Managers in Agile Team

On May 22 at 10am PST, I’m giving a webinar with the always-hilarious Steve Johnson of Pragmatic Marketing.

The topic?  Agile Product Management and “Five Common Challenges” organizations face when transitioning from a waterfall software development model to an Agile model.

Here’s the official blurb (also on Pragmatic Marketing’s website):

Agile is all the rage – developers are using it to deliver products more quickly and more reliably. But many organizations will find that their initial success with Agile is unsustainable unless they address how Agile impacts the rest of the organization, including product management. In this webinar, Sue and Steve will discuss five common challenges faced by newly “agilized” organizations and will propose solutions.

Interested?  Sign up here: Five Common Challenges for Product Managers in Agile Teams.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Join us! Free webinar on Agile Product Management, 5/22

I’ve been quite remiss in posting my slides from my “Charm School for Product Managers” presentation that I gave at P-Camp Silicon Valley.  Sorry about the delay.

In the session, we had a great discussion about how to handle sticky situations product managers find themselves in every day.  One example: how to handle a customer who demands a definitive release date and feature list when it is too early for you to know.  Another situation: dealing with situations when Sales has misrepresented the product to the customer.

Thanks to Enthiosys for putting on such a great event.  I met a lot of great product managers and product marketers at P-Camp Silicon Valley – over 350 were in attendance!   Looking forward to the next one…

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

P-Camp Presentation: Charm School for Product Managers

OK, you know you have to do Win-Loss Analysis. We talked about this earlier.  It’s one of the best ways to make sure you correctly understand the market and its problems — upon which you based, well, everything.

But unfortunately, it is very difficult to get these customers/former prospects lined up for Win-Loss interviews, and even rarer for the interviews to actually happen. Why? Because the Win-Loss interview usually benefits only the vendor and not the interviewee.

I’ve done many Win-Loss interviews, so here’s my advice for getting these interviews to happen.

1. Ask for Win-Loss interviews about 3-4 weeks after the deal closed or was definitively lost. You want them to clearly remember why they did or did not pick you, so don’t wait too long. But if you approach them too early,  lost prospects might decline from fear that you are really trying to re-open the sales process. Or you might unknowingly introduce doubt in the mind of a “won” customer who hasn’t yet paid for your product.

2. Make the following exceedingly clear in your request for an interview:

1. The interview will last no longer than 20-30 minutes.
2. You will not be attempting to re-open the sales process. You are not in Sales, you are in XXXX (i.e. Product Management, Marketing, Development, etc…).
3. Your main motivation is to make sure you correctly understand the market, and can build the best product for that market.

3. Promise some degree of confidentiality. Obviously, you want to share the results of Win-Loss interviews internally and can’t provide complete confidentiality. But to get honest feedback about, for example, whether a personality conflict with your sales rep was a factor in a loss, you should give interviewees the option to request that certain remarks be “off the record.”  Explain that for “off the record” comments, you might include the remark in an aggregate report that covers many customers, but only if it can’t be traced back.

4. Offer something in return. All the above suggestions make it less painful for customers/lost prospects to participate in Win-Loss analysis interviews, but there’s still nothing it it for them.  By making the Win-Loss interview an exchange, even a very lopsided one, you significantly increase your chances of landing an interview.

For “won” customers, offer something that will help them become more successful with the product more quickly. This might be a white paper, access to a special web-based training session, or something similar.

For lost prospects, it’s tougher to offer them something without the appearance of impropriety — as if you’re trying to buy your company back into the game.  To avoid this, one possibility is hiring an outside consultant, and having him/her say “thank you” to interviewees with gifts of nominal value, such as low-dollar-value Starbucks or Amazon gift cards.  Another idea is to thank them by donating $100 to a a charity they choose or to a neutral charity like United Way or the Red Cross.

5. Be persistent but very nice. More than likely, you will have to work hard to set up a full schedule of Win-Loss interviews with customers and lost prospects.  If they don’t call you back, call again later  and send and follow up with an email.  I typically call five times before I give up.  Each time, be as nice as possible.  Remember, you are asking for a favor!

6. Be prepared for last minute cancellations and postponements. It’s going to happen. Your Win-Loss analysis is much more important to you than to your customers and lost prospects, so many will blow you off. Expect this, but immediately try to reschedule for a specific time and day.  If your target interviewee declines, ask if there is someone else at the company you might ask who has a deep understanding about the factors that drove the purchase decision.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Win-Loss Analysis: Getting Customer Interviews Lined Up

Today, enterprises and consumers alike, expect to try out your software (or online service – see note 1) hands-on before making a purchase decision.  Thus, the necessity of Product Evaluation Guides that:

1. Get prospective customers up and running with your software as quickly and as easily as possible.
2. Give positive, low-risk product experiences, so prospective customers have the confidence to start tackling real problems with your software — all prior to purchase.
3. Make it clear how the software is better than the competition’’s.

Sounds simple enough, but many Product Evaluation Guides fail due to simple mistakes.  Here are the three most common mistakes that product marketers make when writing Product Evaluation Guides:

1. Not providing detailed-enough step-by-step instructions.

I’ve seen too many Product Evaluation Guides with hyper-brief instructions like: “1. Create a new project.  2. Create a new workspace,” without any explanation about HOW to do these tasks.

Where’s the icon the user should click to create a new project?  What should the user input into each field in the “New Project dialog box” that pops up?  What’s a workspace anyway?   Explain please.   Otherwise, the user will get frustrated and conclude your product is unusable, when in reality it’s just your Evaluation Guide.

Remember, most users of Product Evaluation Guides are unfamiliar with your product and your lingo, because, after all, indoctrinating those unfamiliar users is the main purpose of your Evaluation Guide!  Assume they have scant knowledge of your product or similar ones.

2. Not providing  context or explanation about why these are the steps.

On the flip side, I’ve seen Evaluation Guides filled with detailed, step-by-step instructions — but they never explain WHY these are the steps.  This leaves the reader uncertain about how to apply the same “step template” to his own problem.  What parts of the instructions are “template” and applicable to other similar problems, and which parts are specific to just this example?  The user is left guessing,  frustrated, and unable to move forward with using the product to solve his problem.

One way to remedy this is to smartly divide the document into sections and sub-sections of related steps.  At the beginning of each sub-section, briefly explain the high-level process and why these are the steps.  When describing each step in detail, note if this particular step is specific to this example and how it would be changed for other situations.  And finally, at the end of the section, recap why these were the steps and provide some more context about how to adapt them if necessary.

3. Including too much marketing-speak.

It’s very tempting to load up a Product Evaluation Guide with lots of puffery and claims of your product’s status as the “leading high-performance platform for scalable, synergistic ,and secure social networking” (or something like that).

However, remember your goal is to get the user successfully using your product — hopefully with his real-world problems — as quickly as possible.   Marketing-speak slows the user down.  It requires him to use too much of his brain to understand what you are saying — brainpower he could have applied to using your product and figuring out how he could apply it to his own situation.  Plus, many of today’s users are just turned off by the usual marketing blah-blah and will think less of your product for using it.

Note that by “Marketing-speak” I am not referring to “good marketing”  language the clearly states what your product is, what it is not, its benefits, and its unique differentiators.  I mean language that – intentionally or not – is buzzword-laden and ambiguous.

Conclusion

Writing a great Product Evaluation Guide can be a tricky business.  But if you keep the main goals in mind and avoid the three common mistakes, you’re on your way.

————–

Note 1 - To avoid awkward language in this article, I use the term “software” generically to encompass online services, enterprise software, and consumer software.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Writing a Product Evaluation Guide? Avoid These 3 Mistakes.

Once upon a time, as far back as 2004, enterprise software Product Marketing Managers and Product Managers spent time creating “Product Reviewer Guides.”

These documents were intended to step technical journalists through the process of installing and using the product, all for the purpose of getting the journalist to write a smashing review of the product and publish it in the likes of InfoWorld, Information Weekly, or some similar trade rag.

Because these documents were geared toward reporters, certain shortcuts could be made.  Since reporters only had limited time — a few hours tops — to work with the product hands-on, PMMs could create pathways through the product that were not typical, but avoided broken functionality or other ugliness.  They could skip directly to the sexy stuff in the product by using pre-baked examples and sample databases.  Further, these documents had a lot of “marketing-speak” — in hope that the reporter would just parrot it directly in their article.

Well, those days are gone.  The “Product Reviewer Guide” for reporters is no longer very relevant.  Instead the “Product Evaluation Guide,” for actual potential customers, is what’s needed.

What are the differences between Product Reviewer Guides and Product Evaluation Guides?

1. Evaluation Guides are geared toward potential customers, where Product Reviewer Guides are geared toward reporters.
2. For Evaluation Guides, the goal is getting potential customers using the product so successfully that they start using the product for real world tasks and even integrate it into their business — all prior to purchasing.  For Reviewer Guides, the goal is to support a favorable product experience  — basically a demo — that lasts a few hours.  After working with a Reviewer Guide, the reader is usually not ready to start using the product for real world tasks, but is ready to write about the product’s benefits and how it compares to competitors.
3. Evaluation Guides get readers using the actual product successfully in their own environment by stepping users through the typical ways to use the product, and by starting with step one.  In contrast, Product Reviewer Guides carefully step around ugliness in the product, even if it means showcasing the product in an atypical way.  Further, Reviewer Guides often skip the (necessary, but sometimes ugly) first steps by having readers use pre-baked examples and sample databases.
4. Evaluation Guides take a matter-of-fact tone and are generally free of marketing-speak, in support of the goal of getting users productive in the real world as quickly as possible.  Marketing-speak makes this more difficult, and can be very frustrating to users that are simply trying to learn if a product can do what they need. In contrast, Reviewer Guides usually have lots of marketing-speak because the company hopes reporters will quote it verbatim in articles.

Why are Product Reviewer Guides on the way out?

For one, the influence of traditional technical media is shrinking as the clout of social networks is increasing. Spending time on Reviewer Guides is not necessarily a good use of marketing dollars anymore.

However, the more important reason why Product Evaluation Guides are rising as Product Reviewer Guides wane is that most software companies now offer free product trials to potential customers, even for enterprise-grade products with multi-million dollar price tags.  And while free product trials are not exactly new, they are now offered earlier in the sales process than ever before, often prior to any contact with a sales rep.

So, next time someone says they need a Product Reviewer Guide, think twice.  A Product Evaluation Guide will often have bigger impact for the same effort.

Interested in more articles like this? Read the Sure Product Consulting Blog.
Copyright &c2008-2009, Sure Product Consulting, Inc. All Rights Reserved.

Forget Product Reviewer Guides. Instead, Do Product Evaluation Guides.