web counter

From the category archives:

Customers

Guest Post: The Cranky Sales Engineer Shares Sales Secrets

by The Cranky Sales Engineer on March 17, 2009

in Customers,Guest Posts,Sales

Annual planning is nearly over and the Cranky Sales Engineer almost has his quota for the year.  In a tequila inspired fit of account-planning ecstasy, he has decided to share how he and his brethren actually sell products and what product managers can actually do to help.

The Cranky Sales Engineer and the rest of the sales force look for a mystical confluence of three features to make any deal happen:

  • A Technical Problem—Nobody buys anything because its “cool” or “neat” unless they are penniless early adopters.  The rest of the market needs a problem to solve or they aren’t interested.  We need to find a real problem.  Not a “my back bothers me sometimes” problem but a “I’m going to knock my own septic molar out with an ice skate” kind of problem.
  • A Relationship—The Cranky Sales Engineers spends an inordinate amount of time at sporting events, dinners, lunches, and, yes, pub crawls, with customers.  Why?  Because customers will only buy if there is a relationship. Without it, they don’t trust us to actually solve the problem.
  • A Business Proposition—There needs to be a business deal on the table that makes economic sense.  Without it, the problem remains unsolved, and the relationship is just another excuse to go to the ball game.  The business numbers must add up.

The Cranky Sales Engineer is constantly astounded by product managers who manage to be completely irrelvent to this process.  These managers talk about features with no problems.  In fact, that’s all they talk about.  Features they have, features they will have, features they don’t have, and the Cranky SE’s favorite: features that don’t work.

What can you do to help your SE’s sell your product?

  • Tie features to technical problems—You should know what gawd-awful problem you’re solving before you invest in new features.  It’s true, that sometimes the problem being solved is that the customer is tired of five mouse-clicks when there could be three. But that’s a problem if you have to do it 100 times a day.  Show us a technical problem to solve.
  • Make sure the features work—Trust is one of the keys to a sale, and the Cranky Sales Engineer loses trust and credibility every time a feature isn’t fully tested.  Here is a clue to when your sales engineers have lost the customer’s trust: the customer asks, “Don’t you guys test your programs?  Why do I have to do it?”
  • Ask the sales team about pricing—You can screw up pricing two ways.  If you make it too high, we can’t sell the product.  But worse, if you make it too low, we can’t make any money selling the product.  Here’s a thought.  Ask us.  Ask the good account managers and good sales engineers.  The good ones don’t want to sell cheap products, and they especially don’t sell on price.  Make it worth our while.

It’s hard to make all three parts of a deal line up.  Customers have no money.  They are retrenching.  Help us find toothaches and give your sales team the tools to pull the the deals together.

{ 13 comments }

Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands

by The Cranky Product Manager on December 31, 2008

in Customers,Divine Rules for Product Managers

View all the Divine Rules of Product Management here.

Law #2: On dealing with customers who can’t understand you don’t develop custom software just for them.

If a customer presents a detailed list of features, demands they be developed immediately, and then tries to extract firm commitments with specific dates for each feature, the Product Manager shall adroitly step around the trap as follows.

The Product Manager shall assure the customer s/he understands the  issues by paraphrasing them back and sympathizing with the customer’s frustrations. 

The Product Manager shall, in front of the customer, write the details of each issue, for posterity, inside a high-class notebook with gold gilded page edges.

The Product Manager shall frequently say phrases like:

  • I can see why that’s important to you
  • We’ll see what we can do
  • I wish we had the resources to work on all these great ideas… which two are most important to you?

The Product Manager shall not definitively promise a feature will be developed nor its delivery date, unless the feature is already done, tested, and due for release within the next 2 weeks.

The Product Manager shall also take copious notes of the entire conversation and circulate these notes to the Product Manager’s boss and the customer’s account team, highlighting that NO PROMISES were made.

If thou does this according to THE SOFTWARE LORD’s wishes, the customer will calm down and perhaps take a less adversarial approach in the future. Even better, the Product Manager won’t get fired in 6 months for allegedly promising the customer something that can’t be delivered.

—————-

Have the Software Gods been speaking to you as well?  Have any additional Divine Rules for Product Managers you wish to share?  Share them in this post comments.  The Cranky Product Manager will feature the best Divine Rules as posts on this blog, with appropriate link-backs to the destination of your choosing….

Also in Divine Rules of Product Management

  1. Divine Rules for Product Managers #1: Prepping for Engineering Meetings
  2. Divine Rules for Product Managers #2: On Dealing With Unreasonable Customer Demands
  3. Divine Rules for Product Managers #3: On Helping the Press with Product Reviews
<< Previous in series | | Next in series >>

{ 11 comments }

Customer Self Sabotage

by The Cranky Product Manager on October 23, 2008

in Customers

The Cranky Product Manager flew many miles, suffering through innumerable connections, delays, malnourishing food, and indignities heaped upon her by TSA officials. All to interview this fantastic new customer that just spent a huge wad of cash to buy DysfunctoCrank. Even better, this new customer represented a new and potentially very lucrative market segment. With a bit of product work, perhaps DysfunctoSoft could make Big New Customer blissfully happy plus have legions of new prospects beat a path to its door.

So the Cranky Product Manager had big plans. She was going to LEARN this customer, Ninja Style. All its sundry business problems. All its hopes and dreams. All its political quagmires.

She was going to LISTEN LISTEN LISTEN and identify those key use cases, capturing their very essence, and distilling them to succinct, beautiful user stories that were perfect in proportion and packed more punch than a Long Island Iced Tea.

The CPM would get to know those users better than their own mothers and spouses, and then — like Steinbeck, Hemmingway, and Shakespeare before her — she would create personas. But not just ANY persona. No, the Cranky Product Manager could never abide by that. Her personas would NOT be lousy one-dimensional cartoons, ala Joe the Plumber. Never! Instead,the CPM’s personas would be fully realized characters that spring to life on the page and burrow deep into the developers’ psyches — making those Code Boyz and Grrls not only better coders/artistes, but also more empathic, more grounded, and better people.

And so the Cranky Product Manager prepared. A lot. She made lists of questions and topics. Unearthed her voice recorder. Thought of fun games and exercises she could do with the customers. Practiced active listening and open-ended questioning with her Cranky Kid (“So tell me, Cranky Toddler, what do you think about Elmo? Does he help you? How? What is the value of Elmo completely solving this problem for you? How would you compare the value of Elmo’s help to Thomas the Tank Engine’s?”).

The Cranky PM got the Sales Droids to line up a full schedule of in-depth one-on-one interviews with representatives of all the main stakeholders. She even sent ahead her favorite handout on Persona interviewing, so the customer would understand why the CPM was asking such detailed questions about each user’s overall job responsibilities and motivations.

And then. Of course. It all got screwed up.

A simliar act of customer self-sabotageWhile the CPM was flying 40,000 feet above some square red state, a Veep on the customer side decided it was a big waste of time for “her people” to spend so much time meeting with the Cranky Product Manager. Instead of the six one-on-one interviews, the Veep decreed there be just one 60 minute meeting of the group. Never mind that everyone was still “wasting” the same amount of time, exactly 1 hour. No, that didn’t matter. Because the Veep’s whole point was about flexing her power over a software vendor, and NOT about being logical or rational.

As expected, the one hour group meeting did not go well.

Strike One: The room was overflowing with 30 people, 75% of whom were completely unfamiliar with the product and had no idea how they would ever use it. They were told there was going to be a product demo and food. But alas, neither was planned.

Strike Two: The Cranky Product Manager gave her introductory spiel about how important it was for her to understand Big New Customer’s actual business problems, all to ensure that future product changes lined up with their needs. Well, despite all the nodding heads in the room, the Veep laid down the law. “I don’t think we need to go into all that. Let’s stop wasting time. Your Tech Support already has the list of all the enhancements we need.” Great. Nothing like a list of enhancements with no context to guide product development.

Strike Three: The Veep insisted the Cranky Product Manager give a demo and then a roadmap presentation. Neither of which was originally planned. Fortunately, the CPM was always ready to give either at any moment. But damn if the roadmap preso wouldn’t have gone better if she had understood this customer’s problems better and was able to speak specifically to their pain.

And so the entire customer visit was (mostly) for naught. Despite the CPM’s attempts to turn the audience’s roadmap questions into learning opportunities (“You’re asking if we’ll have feature X. Is that important to you? Why?”), very little was learned. Not enough to create personas. Not enough to identify key use cases and write user stories. The best she got was a few business cards. Maybe she’d be able to contact these people for interviews later, but probably not since their Veep made it clear she thought their communicating with a vendor was wasteful.

Naturally, the tale ends woefully.

The next release was NOT what Big New Customer wanted, nor what they thought they outlined so clearly in that list of 37 enhancements submitted to Tech Support. The Cranky Product Manager had every intention of making major revs to the product to meet this customer’s needs, but instead Big New Customer sabotaged the Cranky Product Manager’s information gathering efforts, thereby unwittingly sabotaging themselves as well.

Stupid dumbass customer.

{ 5 comments }

Following Up: Customer Advisory Groups

by The Cranky Product Manager on October 2, 2008

in Customers

Following up on yesterday’s post on Customer Advisory Groups/Boards/Councils, you should realize that the Cranky Product Manager is hardly the definitive authority on the subject. So she thought she’d ask you all to contribute your wisdom.

  • What are your thoughts on the effectiveness of Customer Advisory Groups?
  • Any tips/tricks on how to get the most bang for the buck from your CAG?
  • What are your thoughts on the following?
    • Getting the right people to attend, from both your customers and your company. And who are the “right people” anyway?
    • How frequently should you meet?
    • Who should organize the CAG?
    • Location, agenda, …?
  • Dos and don’ts for soliciting feedback that helps with product planning?
  • What was the WORST Client Advisory Group you’ve ever been to, and why?
  • And what was the BEST, and why?
  • What other resources (blog posts, articles) on CAGs would you recommend?

The CPM would REALLY like it if a customer-type also posted their thoughts on CAGs. Not too many of them read this blog, though, so maybe you could forward along the link…?

Please add your comments below! (Note that if you include two or more hyperlinks in your comment, the CPM will have to approve it before it appears, but she promises to do so quickly.)  Note that this is not an invitation to get spammy.

{ 4 comments }

On Customer Advisory Groups

by The Cranky Product Manager on September 30, 2008

in Customers

Two questions from readers triggered this miraculous post:

“What is your opinion of the effectiveness of Client Advisory Groups, and do you think that PMs (cranky or not) should organize and facilitate them?”

“Follow up to the Client Advisory Groups, assuming you have an existing CAG how do extract useful feedback and integrate it with the development process? A ‘rate this feature’ tool? Something all together better?”

So, let the Cranky Product Manager go on record. She LOVES Client/Customer Advisory Groups, provided they are done right. Customer Advisory Groups can get you WICKED AWESOME unvarnished information about:

  • The actual BUSINESS problems that your customers are facing now and in the future
  • How customers view your products’ approach to those problems
  • The market and technology trends your customers sees and what their effects might be
  • How the market views you versus your competitors

Further, if the CAG goes well, you have an unparalleled opportunity to build real relationships with actual customer decision makers. Play your cards right and make friends (or lovers, if you’re a slutty guy), and you’ll leave with relationships with a handful of customers you can call directly — to get impromptu reaction to your product strategy, product feedback, and even competitive information.

Developing these direct customer relationships is ESSENTIAL for a product manager. Because you need to find out what REALLY turns your customers on. Without your own direct relationships, you have to rely on Sales Droids to setup and supervise all your customer conversations. And that’s like having your dorky Dad chaperon you on your hot dates — no fun, kind of embarrassing, and no one gets what they really want out of the interaction.

Alas, Customer Advisory Groups are often done wrong. They turn into multi-hour bitch-n’-moan sessions where each customer lists all the low-level enhancements (and bugs even) that they already filed with Tech Support. None of the above questions are answered, and none of the right relationships develop — wasting the time of all involved.

So, how do you do a Client Advisory Group RIGHT?

There’s a lot of magic, but the biggest thing is getting the RIGHT people there.

Who are the RIGHT people? Usually a higher level person than a PM might normally get to talk to, and definitely higher up than those Tech Support talks to. The RIGHT people are those who OWN the business problems your product solves; they write the big checks and are responsible for actual business results.

So, for example, assume your customer runs all their call centers using your product. Well, get the customer’s Sr. VP of Customer Service to attend, plus maybe the main tech influencer — often the CIO or CTO.

Who are the WRONG people? The software engineers who don’t like the wording of particular error messages. The system administrators who are primarily concerned with automating things they can do perfectly well via the interface. The content developers. The customer’s QA guy. (See footnote 1).

Um, Problem. I can’t get any of the RIGHT people to attend.

Yes, it is VERY difficult to get the real decision makers to attend your little Customer Advisory Group. They are very busy people and very important to their companies. Even if one agrees to attend, the chance of him/her bailing out at the last minute is > 50%. These folks will be VERY tempted to delegate this to the more technical, lower-level members of their team — the WRONG people. And then all is lost.

So you gotta make attending your Customer Advisory Group a SWEET deal. You gotta make these high level folks want to attend desperately, enough that they’ll actually keep their schedule free.

So repeat after me:

Location is everything: If your typical sale has a multi-million dollar price tag, your decision makers are C-level business-side execs. Better go for Pebble Beach and secure tee times for attendees. If it’s an IT-only sale with typical deals being in the mid-to-high six figures, think a high-end resort in Napa Valley, or something similar for your locale. If your product goes for a few thousand bucks, well the local Marriott will probably do. You get the idea. Whatever you do, don’t cheap out and make them buy their own food/drinks or eat rubber chicken on a stick.

Purchasers of enterprise software LOVE Pebble Beach. Trust the Cranky Product Manager on this.

Purchasers of enterprise software LOVE Pebble Beach. Trust the Cranky Product Manager on this.

Provide a “looks good” excuse to attend: Your target attendee will catch flak for going on a vendor-sponsored boondoggle to Pebble Beach unless you provide a way to justify attending to his/her boss and shareholders. Best Bet: Have a topical presentation by a well-known, “impartial” outsider. Preferably a charismatic author of a best-selling business book that somehow relates to the problems your software solves. Second choice is an “honest broker” presentation by one of those Gardener or Forrest Ranger ho-bags (hahahahaha! The CPM can’t control her laughter about that one, “honest!” hahahaha), or maybe a former exec at a well-known, admired company. Last choice: a professor. Please , let her at least have tenure. Also, you might want to have the outsider stick around to moderate some of the discussion.

Oh yeah, if your company has a rock star CEO/Guru (i.e. Ellison, Andreesen, …) try to at least get a meet-and-greet.

Other advice

Agenda: Two days with plenty of breaks, a cocktail hour and an awesome dinner. Include the following sessions:

  1. The thought-provoking presentation by the outsider (see above), preferably related to the problems your product solves
  2. A moderated discussion on the general business trends and strategic issues customers see and what it means to them
  3. A product discussion that links the trends/problems to potential product directions.
  4. Plenty of time to facilitate networking among the attendees. Help them break the ice and get to know each other.

Who Attends: 4-5 of your company execs and product management leaders. Have key Engineering directors/VPs and junior PMs attend relevant parts, but they must sit quietly in the back of the room. (NO banging away on laptops).

Salespeople stay away or shut the hell up.

What Product Managers Should Do: Milk this session for all its worth. PREPARE. Big Time. During breaks, socialize with the attendees as often as possible without annoying them. Which is hard if you have a crabby personality like the Cranky Product Manager.

More Specifics on the Product Session

Product Management should design and facilitate the Product Session. And NO, the Cranky PM isn’t going to tell you exactly how to structure the Product session. Deal with it. Your approach should vary anyway, depending on the burning questions you have. The key is to get the customers ENGAGED and learning from each other — Interactivity, BABY! That’s what makes them happy and will get them to come back next year.

OK, a hint. DON’T DO THIS: Each customer gets up, gives a presentation about how they use the product and the enhancements they want to see. This will bore the bahjeezus out of everyone, the RIGHT people will decide then and there not to come next year, and — trust the Cranky Product Manager — Tech Support already has this entire list anyway.

OK, Yet Another Hint. The Cranky Product Manager has had lots of success with workshop-style exercises that involve walking around the room and pasting sticky notes to flip charts — an artifact from her days as a management consultant at one of those big-dealio strategy consulting firms. Read Luke Hohmann’s book, Innovation Games: Creating Breakthrough Products Through Collaborative Play to get some ideas.

(Just remember to send Hohmann royalties for any “games” you use. Haha, just kidding, Luke. OK, not really. Seriously, Luke, the CPM is impressed you that you trademarked these “games”, since most are de reigueur for any product-oriented workshop the Cranky Product Manager has led or attended in the past 15 years. So, well done. The Cranky Product Manager is totally jealous. And though she is sniping at you because she is exceedingly immature, the Cranky PM is genuinely thankful that you collected these workshop exercises in a single 150-page primer. Now she can toss the book to junior PMs instead of having them learn purely by doing — a big help.)

Who Organizes the CAG?

Get an admin assistant or Marketing’s event planning people to handle the logistics. PM should recruit the attendees with the help of Sales — if you leave the invitation list up to another function, more than likely you will end up with the WRONG people in attendance. Also, PM should set the agenda, provide guidance to the outside speaker/moderator, and design the above-described product session.

But WAIT there’s more.

There’s a lot more to say on how to get the most out of Customer Advisory Councils. Lots. The CPM could go on and on, but alas she’s getting Carpal Tunnel. So, here’s a few other links you might find interesting. Note that they don’t agree with the CPM on every point (idiots!), but are still worth reading.

———–

1. These people have valuable feedback, but there should be another venue for that: USER GROUPS and your usual customer meetings and conference calls.

{ 9 comments }

Stage 4 Product Proliferation

by The Cranky Product Manager on April 14, 2008

in Customers,Development

Once upon a time, long, long ago, DysfunctoSoft had a simple little price list. It could be described in a paragraph. Buy our server and pay $XX,XXX per machine. Buy our companion client-side tool and pay $YYY per instance. Simple.

And then came the inevitable. Customer A started whining: DysfunctoSoft, we like your product. But it is too full-featured for us. We don’t want to pay for functionality we won’t use.  We want to pay less.

Instead of recognizing the whining as a simple price negotiation tactic, what do you think the big cheeses of DysfunctoSoft decided to do? Did they tell the sales person to do a better job of selling the product that actually existed? Did they attempt "value pricing" or offer Customer A a discount so the price would fit the project’s budget?

No. Of course not. Because those options are just too frakin’ simple. And too cheap. You see, DysfunctoSoft always likes to do things the arcane way.  The expensive way. The way that is most likely to confuse the fuck out of customers and the sales people and pretty much everyone.  The way that is most likely to increase the cost of BOTH sales AND product development by tenfold.

So what did they do?  The big cheeses of DysfunctoSoft ordained that a NEW product be created, a variation on the original.  This NEW product shall have less functionality than the original, and shall be offered at a lower price. 

And it worked. The deal closed.

And then the very next customer, Customer B, said: You know what, we like your stuff, DysfunctoSoft. But the original product is too much for us, and product variation A doesn’t do enough.  We need something in between and we don’t want to pay for functionality we don’t use.

And so the big cheeses met on Mount Olympus yet again. In between sips of ambrosia, they commanded that Yet Another Product be created, against the strenuous objections of the predecessor to the Cranky Product Manager. Product B would have less functionality than the original and more than Product Variant A, and offered at a price in between the two. Customer B liked. And Customer B bought.

And you can see where this is going, right? 

N years later, DysfunctoSoft now has product variations A through ZZZ.  All slight variations of each other.  Each has a moniker meant to distinguish it from the rest, but instead it serves to confuse the frig out of everyone: "Lite", "Starter", "Ultimate", "Standard", "Enterprise", "Developer", "Advanced", "Professional", "Professional Plus", "Basic", "Premier", "Express", "Personal", "On-Demand", "Workgroup", "Home", "Business", "Desktop", "Premium",  "Basic N", "Unlimited", "Datacenter", "Foundation", "Framework",  "Mobile", "Community"…  The list goes on and on.  Naturally, there is no consistency in the naming.  That would make too much sense. What the frig do all these terms  mean anyway?  Especially when the "Unlimited" and "Ultimate" variants aren’t as powerful as the "Enterprise" or "Pro Plus" or whatever. And how the hell are the Lite and Basic and Express and Starter editions different? 

Not only that, each of these products can be licensed in a myriad of ways: per instance, per customer site, per server, per processor, per concurrent user, per named user…  It is difficult to think of a licensing method that DysfunctoSoft does not support. 

Results?

The price list is now enormous, pushing 200 pages or so. No one can understand it. Especially not Sales Droids.  They join DysfunctoSoft and then quit/get fired within a year. And then it’s time to train a new Droid. It takes them MONTHS to finally internalize this nutso product line architecture.  Without their guidance, customers can’t understand what to buy or how much it costs. Forget a consumer sale, a self-service sale, or one driven by website research.

Product Development is getting crushed underneath the weight of all these product variations. Although they all largely use the same code base, there are significant differences that have impact throughout the behavior of the products.

And because the names are hard coded into the products, manuals and marketing collateral, despite a concerted effort NOT to hard code them, it is now impossible to change the names to more sensible alternatives.

The QA effort required to test all these products on all the support platforms has gone through the roof.  It seems that for any new release 60% of the effort goes into making the licensing more intricate and trying to automate this crazy product variation structure via license keys or elaborate build systems.

What else?  Support costs have skyrocketed.  As have documentation and training costs. Marketing costs too. The Cranky Product Manager is sure the effects do not stop there. Oh what joy it must be to handle the accounting for such a needlessly massive product line. Or the financial forecasting. The auditors probably have a grand old time billing DysfunctoSoft after sifting through its cornucopia of transactions attributable to each product and licensing option combination.

The Cranky Product Manager truly, honestly believes that DysfunctoSoft’s latest troubles are primarily due to the explosion of products that are not truly differentiated.  It’s treading water, trying to keep its head above the continually crushing waves of a massive code base.  There is no time to actually create value for your customers when you can barely maintain what you already have. 

The Cranky Product Manager knows that DysfunctoSoft is hardly alone. Even companies like Proctor & Gamble are lured to madness by the siren of product proliferation and endless line extensions, paying dearly in the end for their lack of discipline.  Every software company the CPM has ever worked with has suffered the same illness. But those companies were still in their early years, suffering from Stage 1 or Stage 2 Product Proliferation.  Alas, DysfunctoSoft has an older product line, and is now suffering Stage 4 Product Proliferation: malignant, inoperable and infecting all organs in the body.

Perhaps it is time for the Cranky Product Manager to start working on her resume.

{ 11 comments }

Thanks for Sharing Your Secret Moves

by The Cranky Product Manager on April 18, 2007

in Customers

Obiwanmindtrick Ooooh, our readers have all shared some pretty excellent Secret PM Ninja Moves for dealing with feature demands from customers and from sales.  Check out the comments. Great stuff in there.

The one Secret Move that the Cranky PM does not see listed is the Jedi Mind Trick (“This isn’t the feature you’re looking for…”)  It is one of her favorites.

{ 0 comments }

Share Your Secret Moves

by The Cranky Product Manager on March 31, 2007

in Customers

Just in case you haven't figured it out, the Cranky Product Manager is extraordinarily lazy for someone who works 65 hours per week. She will do whatever she can to get other people to do work for her. It's one of her mad Product Management skillz — foisting work upon others despite having little formal authority to do so.

So, in keeping with her (lack of) "character", the Cranky PM is about to do that crappiest, saddest, most pathetic of blogging moves — she's going to ask you, the reader, to contribute and make this sad little post worth reading.

So… Audience Participation Time. 

Questions for the Cranky Product Manager's crew (and by "crew" she means all you fellow PMs):

1) What's your favorite PM breakdancing move for telling (or avoiding telling) an important customer that his favorite feature is not planned for any of the next 3 releases? 

2) What about for telling the same thing to a sales droid who claims a multi-gazillion dollar deal is going down the toilet because you don't have Feature X? (You know… Feature X.  That's the missing feature the sales droid will blame if he loses the deal.  Of course, if the droid wins the deal because it turned out the product has a superior way of accomplishing the same thing, the win will be credited to the droid's sparkling personality and superior "closing" abilibites, not the product's wicked awesome feature set.)

{ 13 comments }