Seth Godin makes an interesting point in "saying thanks in a conference presentation." He writes,

Not only is this a total waste of time for most attendees, it doesn't even satisfy the core objective, which is thanking and rewarding the folks who helped. And it certainly doesn't encourage others to look forward to helping out.

It seems to me that conference organizers know almost nothing about organizing conferences; they seem to lose sight of any of the conference objectives. Conferences are usually designed around papers delivered by speakers yet they often don't provide printed proceedings and they typically do not provide support for the speaker--such as the ability to see the slides without turning around.

Maybe that's why conferences are often so expensive and yet so poorly attended.

Alas, organizers seem to focus mostly on the logistics and the exhibitions. They get everything in the right place at the right time and they make sure that the sellers have a place to hawk their wares. But in my experience, these organizers  do a poor-to-fair job of promoting the conference, do a poor job of supporting the speakers, and do a poor job of supporting those who attend.

Perhaps that's why "unconferences" were born. Rather than suffer a glitzy but empty traditional conference, people who are actually interested in the conference topics have started their own conferences. Many of you in the Austin area participated in the Austin ProductCamp last month. I'll be speaking on The Strategic Role of Product Management at Agile 2008 in Toronto next month.

If you are a conference organizer, actually watch the sessions at your next conference. You'll see dozens of ways to improve the experience for the speakers and attendees.

Got an offer for USB sticks in my email this morning. But I don't have enough to buy a mimimum order. Dang.

Everybody makes mistakes which is why you should always have someone else review your work before it goes out!

I agree with the forestry service: we should let some fires burn. Many will just burn themselves out; others will get really interesting. But what about the people who dropped the ball and let these fires begin in the first place?

In Why a good PM will never be Employee of the Quarter, Saeed writes,

Kind words are usually reserved for those who take a nasty operational situation, and help alleviate the problem through significant personal sacrifice.

Remember the old cartoon in your admin's office? "Lack of planning on your part... doesn't constitute an emergency on my part." Alas.

As Product Management Thursday approaches, can you set aside firefighting for one day and identify ways to prevent fires? Here are a few ideas:

• schedule some work-at-home-and-get-something-done days
  
• schedule some customer visits
• perform some win/loss analysis
  
• identify and articulate your buyer and user personas
• map out a repeatable sales process
• reorganize your sales tools on the intranet so people can find stuff
  

What can you do to prevent some fires instead of just fighting them?

Using a customer advisory board is one way of listening to the market and keeping your product focused on solving real problems. The trick, of course, is that you should be listening more than talking. Nature gave us two ears....

CAB Exchange is conducting the first best practices survey of Customer Advisory Programs. Our friend Bill writes,

I'd like to invite your clients to participate. Those who do so will receive a free copy of the completed survey results and analysis (a $200 value). In addition, they'll receive a discount on the registration fee to next month's CAB Exchange Summit.

Take the survey here.

Learn about the CAN Exchange Summit.

Quick! What's the second word in "beta testing." If you said "testing", you're right. That's why beta testing should be run by the testing people in QA. However, as Paul Young writes,

If you run Product Management, especially in a smaller company, you may find yourself running the beta program.  This is a tactical activity, and you will be knee deep in beta user qualification, feedback, administration, possibly even support, but you can take positives from a good beta.

Product managers are often involved with beta testing because product managers want to validate the usability of the product (hint: do it much sooner), they want to show the product to some key customers, or maybe they just know more customers than the QA people. Read Paul's description of 5 types of beta. Great stuff. Are there more?

Kristin Zhivago writes,

Before you hire someone, you'll map out your successful sales. You'll figure out the sales tools that are needed at each step in the buying process. By the time you hire a salesperson, you will be ready to provide him with everything he needs to succeed.

Read more in The 7 CEO Selling Mistakes.

I've long been an advocate for a repeatable sales process. Mapping out a repeatable sales process is perhaps one of the easiest and most effective activities for a new product manager. It's an emergency prevention activity. Do you have one for your product?

If you're in the Austin area this upcoming week, you may want to stay over on Saturday to add ProductCamp to your schedule. ProductCamp is in Austin at St. Edward's University Professional Education Center on June 14th, 2008 from 8:00 AM to 6:00 PM.

Pragmatic's John Milburn will be speaking on "Technology Assessment: Where to put your Development Dollars." Other Pragmatic Marketing friends at this conference include Paul Young of Product Beautiful on "How to Build a Successful PM Practice at a Startup" and Scott Sehlhorst of Tyner Blain on "Can Requirements Be Done Offshore?"

You can still come to ProductCamp for free, even as a walkup. Sign up here!

We discuss the idea of buying and using criteria in Practical Product Management.
My friend Gopal takes the idea further, asking "will customers like it enough to buy it?" He explains that you want to build products that customers will BUY and not JUST LIKE.

Tuned In is what I’ve been looking for. For years I have listened to product managers and marketers lament that their executives just don’t get it. I’ve taken a couple of passes at it with my article “Stop Perfuming the Pig” and my ebook “The Strategic Role of Product Management.”

The essence of Phil’s post is the idea that we start with a problem first and find a product second.

You know, it’s so crazy it just might work!

I work with product managers and marketers every week. And every week they describe product first, problem second. “We have this product, how do we sell it?” Marketing people search for clever positioning to get people to want what they have. Sales people look for gimmicks or tricks to persuade people to want what they do not want.

Tuned In shows us an easier way. Start with the problem.

Do you know about TV-B-Gone?

Let’s start with the problem: you’re in a nice restaurant and there’s a TV set blaring in the bar that no one watching. Or you’re in the airport with CNN blasting and no one’s watching. Wouldn’t it be great to be able to turn off that TV? Then try TV B Gone. This product sends “off” codes for every brand of TV. From their website, here are the directions for using your TV-B-Gone

1. Point it at a TV set
2. Press the button (no need to hold the button down)
3. Keep pointing it at the TV until the TV turns off

Find a problem, solve it, tell people. What could be simpler?

You know, it’s so crazy it just might work!