ProductMarketing.com

Test Smarter, Not Harder

Successful projects require automated tools for both developers and testers. While much has been written about development tools, Scott Sehlhorst writes this about testing tools:

Automated testing has become a critical component of software product success. Processes like continuous integration require test automation to be effective. Unit testing requires automated testing to be effective as a rapid-development tool. Whitebox testing is almost always done with automation. More and more blackbox testing is being done with automation. A team without a good approach to automated testing is working at a severe disadvantage, and is arguably doomed to extinction.

Read more about test automation in Test Smarter, Not Harder.

Issue 3| The New Rules of PR posted

In productmarketing.com Issue 3, we explore The New Rules of PR, Building a Better Beta, Prioritizing Software Requirements with Kano Analysis, and a case study of product management at Thomson Medstat.

iPod + Nike

Is this a good idea? Interfacing your running shoes with an iPod could be cool or it could be another "possible but stupid" idea. I hope they tested it with some serious runners before they launched it. Or is it yet another "golfing partnership"?

Tell Us What You Think

The Office 2007 team wants to know what you think about the features of the beta version. They write, "The best tool to use to give us feedback on Office 2007 Beta 2 is called Send a Smile. Install the Send a Smile tool and two icons are added to the notifications area of the taskbar over by the clock: a happy face to click when you want to give us positive feedback and a sad face to click when there's something you don't like." Read more in Tell Us What You Think About Office 2007 Beta 2.

The tool provides an easy way to send feedback--positive or negative--and sends a screen shot of what you were attempting to do when you clicked the smiley. Pretty clever. (Unfortunately the installation requires a somewhat arduous sign-up/sign-in process.)

And remember, Microsoft is not selling direct but through distribution; couldn't you do something similar in your products?

What are you doing to solicit feedback?

Don't mindlessly copy features

Michael writes, "Don't mindlessly copy features that competitive products have. Focus instead on features that competitive products don't have but customers need." Read his excellent story on the typical 'listening to competitors instead of customers' in Sun Tzu on Product Strategy - Part 1.

Differentiation vs. Improvement

Scott Sehlhorst writes,

Sailboats can sail into the wind because the sail acts like a wing. Why did we wait decades until someone actually used a wing instead of a sail? We've had the data since the Wright Brothers built the first wind tunnel a hundred years ago. People were trying to make sails better instead of making sailboats different. We had to wait until someone had a differentiated innovation.

Sailboat designers weren't focused on the market requirement - make sailboats faster. They were focusing on a product specification - make a better sail. Read more in Differentiation vs. Improvement.

Do You Have To Drop Price To Increase Sales?

Chuck McKay reminds us that it ain't the price that matters. When will your sales people learn this?

The tools your sellers need from your website

Kristin Zhivago writes,

I recently interviewed dozens of salespeople for a client as the first step in redesigning the selling section of their reseller portal. The salespeople were very clear about what they wanted: Information they could use to answer the questions customers were asking about the manufacturer's products. They wanted to be able to find this information in a couple of clicks. They wanted to spend their time selling, not searching for the information they needed to sell. Here's what you need to do to make sure your sales force has the information they need at their fingertips.

Read more in The tools your sellers need from your website.

Another negative development rant

You know, I think I posted this--or something like it--before. Must the product manager have to specify everything in the requirements or should the developers know how to be good?

I love my Garmin Nuvi--it's a small GPS that I can take anywhere. Periodically I like to update the software, not that I really need to since it's working just fine but I like to keep "current."

So I jump on the Garmin web site, download the web updater and the problems begin. First, the software is installed at C:\ instead of in the program directory where it belongs. That really bugs me! Must the product manager have to specify everything in the requirements or should the developers know how to be good? "The product shall install in the Program directory" seems an unnecessary stricture.

Then I run the updater which does some type of LiveUpdate and downloads the new software. After some confusion about how I should reboot the GPS, it asks, "Do you want to install version 3.30?" Cool. It reinstalls the software but deletes all the configuration information from version 3.20. Huh? I had set up preferences plus a few dozen Favorites that are now gone. In what world do the developers feel that a clean install should be the default? Must the product manager have to specify everything in the requirements or should the developers know how to be good? "The product shall retain preferences, configuration, and saved locations from previous versions." Yeesh!

But I'm patient--or perhaps I'm an idiot--so I decide to re-enter all my saved locations. But the GPS thinks I'm in Kansas (since that's where Garmin is based I'm guessing). Now I have to go outside so the GPS can find out where I am. I'm wandering up and down the driveway for ten minutes while it finds itself. How do I set my "Home" location again? Do I just save as string "Home" or is there a menu option somewhere? I forget. Now what's Bob's address again? Lemme look that up in my address book and then re-learn how to save an address that is not my current location. Durn it! Never mind; I'll just enter it next time I go to Bob's house. And since it doesn't save my preferences from one release to another, there's really no need to stay current on the software. And certainly no "lock-in" for me to continue using Garmin when I make my next purchase.

Must the product manager have to specify everything in the requirements or should the developers know how to be good?

What does "good" mean? Good programmers adhere to industry standards--at least when it makes sense. Put your programs in the programs directory; don't corrupt or destroy data; retain preferences and customization between releases--or at least offer to convert them; be clear on how to complete any operation that is critical but rarely performed--such as installation and version upgrades.

To say that these should be in the requirements is a cop-out; it's just lazy programming. It's programming that says "I don't really care." Product managers shouldn't have to specify everything; developers should know enough about their target environment and customer to know how to be "good."

Seth's Blog: Three big barriers

"It's not always the stories that we tell to prospects and consumers that matter. It's often the stories we tell ourselves. In talking with companies that are unhappy with the way they are growing, I find two common themes (and one a little less often)." Read the Three Barriers in Seth's Blog.

Requirements roles and artifacts

Scott Sehlhorst offers clarity on requirements artifacts and roles in the development process. Read One Man's Trash on his blog.

May newsletter posted

The initial product launch may be the only time that sales people get information about your product. Your sales people probably have more information about your competition's products and strategy than they do about your own. Think about it. How much time do your sales people spend learning about your product? And how much time do they spend learning about the competition? And being reminded constantly of the competition by their customers?

Sales people need to be schooled continually in the value of your product. By making product information available and accessible, you can give sales people the tools they need to help themselves. Read more in On-going sales education.

Top Ten Myths about Business Innovation

In another post, Geoff Moore writes,

You have some success, some momentum, and therefore some inertia, and it is the inertia that has you worried. By design, inertia resists change. This is a good thing, as long as you are headed in a direction you want to go. But when the market changes, inertia acts against your future interests. Now you are right to be worried. So you raise the topic of innovation in hopes of getting some insight. Good luck. My recent research leads me to believe that innovation, as a topic, leads the business writing industry in twaddle per page.

With that in mind, let me dispel what, in David Letterman tradition, we might call the Top Ten Myths about Business Innovation.

Competing for Market Share--Maybe

And speaking of pricing, Geoff Moore discusses when it makes sense to make pricing sacrifices in pursuit of market share--and when it doesn't.

Competing for market share drives some of the best--and some of the worst--management decisions in business. Companies are particularly susceptible to going astray at the end of the quarter when they seek to use market share impact to justify horrendous deals--that is, deals that sell out all future quarters in order to make the current one. Here are some guidelines to help you stay on the straight and narrow.

Read Competing for Market Share--Maybe for guidelines on pricing and strategy.

Camels and Rubber Duckies

Pricing is a mysterious thing. We talk about pricing in Practical Product Management and find that almost everyone has a point of view and a recent challenge with pricing. "Do I charge a lot or not?" "Should I do a site license?" "How about different prices by segment?"

Joel Spolsky explores the conundrum of pricing:

"You've just released your latest photo-organizing software. Through some mechanism which will be left as an exercise to the reader, you've managed to actually let people know about it. Maybe you have a popular blog or something. Maybe Walt Mossberg wrote a rave review in the Wall Street Journal. One of the biggest questions you're going to be asking now is, 'How much should I charge for my software?' "

Read Joel's strategies for pricing in Camels and Rubber Duckies.

Open letter to employees across the corporate world

Pam writes,

"I have met you in meeting rooms, hallways, on conference calls and on the internet. You work for large corporations which you detest. You arrive at your cubicle every morning with a vaguely sick feeling in your stomach and begin your day of work. You have too much to do. Co-workers left and no one replaced them, so you have inherited their job and all the work that went with it.

"I did what I could to comfort you and give you hope. But since I am helpless to change the overall state of corporations, here is my best advice."

Read six life lessons for dealing in a cubicle world in Open letter to employees across the corporate world.

Building a Requirements Foundation Through Customer Interviews

"Our customer doesn't know what he wants," complained Sandy. "I try to get him to talk about the product and tell me what he wants, but it's like pulling teeth."

Sound familiar? Read more in Building a Requirements Foundation Through Customer Interviews by Esther Derby.

Time for Software Marketing to Grow Up

Tom Hogan of Catapult Direct advocates more customer focus and less product focus. He writes:

Despite being in its thirties, high-tech marketing is still an industry in its adolescence. And like any adolescent, it's unsure of where it wants to go but knows better than anyone else how to get there. Part of the problem is the crowd that Marketing runs with. Marketing hangs out almost exclusively with 'Product Guys' - not salespeople. Product Guys are like those guys who go on first dates and talk endlessly about themselves. Finally, as the evening wanes and the date is utterly bored, they smile engagingly and say, 'But enough about me. Let's talk about things I like to do...'For these Product Guys, it's all about 'The Product' and its capabilities. On sales calls, when talking about The Product, they just can't stop. 'But enough about the features, let's talk specs...'

Read more in Time for Software Marketing to Grow Up. I wish he used the term "Customer focused" instead of "Sales focused," as the latter implies that we should focus more on our sales people. And most people know that that is a formula for failure too.