- Why Sales Bitches About Product Management & What to Do About It

You’ve heard that old chestnut. You’ve seen it in a million articles. The big advice Sales Droids offer to Product Management is “Don’t just talk about features.  Tie the features to problems.”

And whenever the Cranky Product Manager sees Yet Another Article offering this advice, she thinks, “Doesn’t every product manager already know this stuff? Duh? How is the Cranky Product Manager going to create a blog post from this nugget of obvious non-wisdom?”

But then the Cranky Product Manager thought about it.  Then she had a nice glass of Chardonnay. Then more thinking. And then mentally watching the game film from all the customer presentations she’s ever given or watched another Product Manager give, and from her years of observing Sales Engineers and Sales Droids interact with the customers.

And here’s what the Cranky Product Manager came up with.

When It’s Good (kind of like the finale of Dancing with the Stars)

There are times when the Sales Droid-Product Manager-Customer interaction is wicked awesome: everyone is in sync, everyone is providing what the others need at exactly the time they need it, and everyone leaves happy.

It does happen sometimes.

When It’s Bad (kind of like a Middle School Dance)

But more often, it is a clumsy, inept dance, with everyone thinking he’s/she’s giving what the others need but completely missing the mark.

In these cases, the Cranky Product Manager will bet ONE MILLION DOLLARS that the Product Manager in question truly believes she is tying each feature to customer benefits, all while the Sales Engineer/Account Rep thinks the Product Manager is just blathering on and on about features.

The Disconnect

How can this happen?  Because there are several steps between the “we added Warp Drive in release 2.0″ Product Manager-ish statement and the “Warp Drive increases your revenues AND decreases your costs” Sales-ish statement.

Using this example, the Product Manager would probably say “We added Warp Drive in release 2.0.  That makes our rocket ships now go faster than the speed of light, which means space travel will take one bajillionth of the time it currently does.” And the Product Manager often leaves it there, believing she successfully tied feature to customer benefit.

Meanwhile, the Droids think the Product Manager left out the business benefit.  After all, she did not tie the warp drive feature to either “saving money” or “making more money” (the only two customer benefits some Droids can understand).

Thus the schism.

To most Product Managers, it is OBVIOUS that faster space travel means people will spend more time working instead traveling, and will thus become more efficient, saving money.  And that with Warp Drive we’ll be able to reach more of the galaxy and thereby increase the number of customers we can reach, increasing revenue.  blah, blah, blah.

In fact, it seems SO obvious that many Product Managers worry they’ll insult the customers’ intelligence or annoy them if the Product Manager explains how each and every feature ultimately saves money or increases revenue.

Truth is, the customers probably need a bit more hand-holding.  As Product Managers we are genetically engineered for our superior feature-X-yields-benefit-Y perception. We forget that not everyone thinks like that.

But on the OTHER hand, the Sales Droid who can only talk about “saving money” or “making more money,” (aka “lower TCO” and “increased ROI”), often seems like a huge dumbass to the customer. Trust the Cranky Product Manager on this, she once was a customer.

An Obvious Tactic That Often Works

**So, for Product Managers, here’s a technique that sometimes works: **

  1. Before demo-ing or presenting the roadmap or whatever, ask the customer about his/her problems and the benefits that he/she is seeking from your software.  
  2. NOTE THE EXACT WORDING THE CUSTOMER USES TO DESCRIBE THE SOUGHT-AFTER BENEFITS.  
  3. During your demo/presentation, tie the features back to the specific benefits the customer seeks, using EXACTLY the same wording.

Of course, this technique only works if you are able to talk to this customer one-on-one beforehand; it works less well if you are presenting to a huge crowd at a conference.  Also, this technique does not guarantee that the Sales Droid will be happy, only the customer.  After all, the Sales Droid might not understand the benefits the customer seeks – they might be too “low level” for a Droid to possibly comprehend.

This concludes the Cranky Product Manager’s “Obvious Lesson of the Day.”

No doubt, huge swaths of Product Managers are out there saying* “Isn’t this advice obvious?  Doesn’t every product manager already know this?”*  Hopefully, most of you do.  But for those who don’t, or who occasionally forget, hopefully this advise is more specific and more actionable than that “Tie features to benefits” platitude.

– OLD The Brain of a Sales Droid – A Visual Guide

- OLD: Death of a Product Manager

– Guest Post from A. Working Coder: The Five Stages of Debugging

In her previous post, the Cranky Product Manager unloaded on Code Boys & Grils who don’t fix their damn bugs.  She got all riled up.  Needed to run 10 or 12 miles just to settle down and work.

This post is the flip side. The developer’s point of view when faced with a nasty bug.  And it’s an extremely well-written piece by an engineer who is  a reader of this humble and cantakerous blog.

This post is required reading for product managers. And the developers will probably like it too.

——————-

The Five Stages of Debugging

by A. Working Coder

Being confronted with a serious and difficult-to-diagnose bug can be one of the most traumatic and stressful experiences of a professional programmer’s career. Those who have been through such an ordeal rate the stress as on a par with that accompanying serious injury, divorce, or the death of a family member.

Researchers who have studied the psychology of computer programming have lately constructed a framework to understand the stages through which the programmer’s mind progresses as she/he works through the difficult process of resolving a bug. These stages are similar in concept to the well-known Kübler-Ross Stages of Grief, and for similar reasons. Like death and its attendant grief, fixing a bug is a process initiated by an event, at first unbelievable, which causes great anguish in the affected mind. However, this event must eventually be grappled with, endured, and brought to a satisfactory conclusion. Understanding the stages of bug fixing will make us better prepared to survive, persevere, and eventually bring closure … to our bug queues.

STAGE 1: RESISTANCE

How you’re feeling: Skeptical. Offended. Petulant.

1. Ignore it.

Maybe it’ll go away.

2. Mark it as “Works for Me”.

Maybe it was user error, or a local configuration problem. Yes, I’m sure that’s what it was. It’ll just go away.

3. Call it a Glitch.

I think it was just a weird one-off that nobody will ever see again. There’s no point in figuring out what went wrong. The {database/network/browser/something} hiccuped and that’s all this was. It won’t come back, I’m sure.

4. Hide.

I’m taking a couple of days’ sick leave. Maybe they’ll assign the bug to somebody else.

5. Mark it as “Working per Spec”.

Hey, look, I just implemented what was spec’d. If they want to change the behavior, UI will have to update the spec. Maybe they’ll decide they can live with it as-is.

6. Demand More Information.

I can’t do a thing with this bug until and unless I see the error logs for this particular exception scenario.

7. Assign it to another team member.

I was getting badly-formatted data from that other module, that’s the problem. Give it to the guy who maintains that module. I could check for that one weird corner case in my module, but the proper fix is for that other guy to make his code correct. He’s offshore anyway, so I’ll never have to face him.

STAGE 2: ACCEPTANCE

How you’re feeling: Resigned. Defeated. Annoyed.

1. Accept it.

All right, all right, all right! It’s my bug. I’ll fix it.

2. Put it on the bottom of your queue.

Maybe I can find another job before I’ll have to fix this bug.

3. Bargain with your manager.

OK, look: I could fix it the right way, and that will take a month. On the other hand, I could apply a band-aid to the problem, which won’t really solve it, but it’ll make it go away as far as the end-user is concerned. And that will take a couple of days.

4. Mark the bug with an outrageously padded estimate.

God, I hope that’s enough time.

STAGE 3: ENGAGEMENT AND DEPRESSION

How you’re feeling: Giddy. Light-headed. Nauseous.

1. Initial Research.

I can do this. I can do this! All it takes is a little organization, a little focus, a lot of caffeine, and a little time. I can do this.

2. Befuddlement.

Shit. This is unbelievable. I can’t make heads or tails of this code. It’s a mess. It’s a mystery to me how this code could even compile, let alone work. What chance do I have to figure out how it can fail?

3. Hide Again.

Look. I’m sorry. I had to have my appendix removed. Again. Yes, now that you mention it, I did used to have two. Now I don’t have any. Happy now?

4. Bitching.

Well, what did they expect, anyway? Trying to do this without so much as a decent debugger. What am I, clairvoyant? I had better debugging tools on my Commodore 64!

5. Spitballing.

What if I try … this? Nah, that doesn’t work. How about … that? Nope. How about … that? Shit, that makes things worse.

6. Despair.

I’ll never fix this bug. I’m a lousy coder. I’m stupid. What am I doing here, in a place full of smart people? Sooner or later they’re gonna catch on, and then I am finished around here.

7. Humiliation.

My manager asked me why I’ve taken the better part of a month to fix a bug I’d spec’d out as taking a couple of days’ worth of work. I don’t know how to read the logs and I broke my own build scripts. Now I’m afraid to ask for help because it’ll just make me look stupider than I already do.

8. Panic!

This thing is way more complicated than I thought it would be! The parts I thought would be really hard turned out to be really easy … and the parts I thought would be easy turned out to be a complete rewrite of about a half a dozen classes. Why did I ever tell my manager I could do this?

9. All-Nighter(s). Withdrawl from friends and family.

(incoherent mumbling, punctuated by bursts of loud profanity.)

STAGE 4. POSSIBLY FOOLISH EUPHORIA

How You’re Feeling: Grateful. Relieved. Awfully Impressed with Yourself.

1. Revelation.

Oh! Now I see how to do this…

2. Write the correct code.

I am so good. I am a coding machine!

3. Test it.

Yes! It passes that test. Yes! It passed that test. Boo! It fails that test. And I have no idea why…

4. Hide the test failures.

It’s a totally unrealistic corner case anyway. Nobody will ever see that in the field. It was really a pointless test.

5. Check it in.

I’m awesome. Is there pie in the kitchen?

6. Close the bug.

I heard there was pie in the kitchen.

STAGE 5. GRAPPLING WITH THE DEFINITION OF “DONE”

How You’re Feeling: Twitchy. Nervous. Superstitious.

1. They’ve Reopened the bug.

Really? They found another way to break it? Shit – it’s that corner case I swore would never come up.

2. Fix the fix.

Yes, I’m even checking cases where the employee age is an imaginary number, just to be sure.

3. Close the bug.

Yeah, bitch. You’re closed. Once and for all. Now stay dead!

4. Vow to never take on such a task ever again.

5. Realization that you are now considered the expert on that module.

Oh no! Now I’ve got three new bugs on that module.

At this point, you are expected to GOTO: Stage 1.

Furthermore, as a working coder, you will DO_UNTIL: Death, retirement, or promotion into management.

–That Code Boy Hath No Shame

The Cranky PM has been pretty happy at work lately.  Thus, the drought of new cranky blog content.

So, you should all thank SugarSync for irritating the Cranky Product Manager enough that she shall now post.

Some background…SugarSync is a cloud backup service that the Cranky PM pays for. She uses it at home to keep her 3 computers backed up and in sync. Cool in concept, but not so cool in reality. A few months after subscribing, instead of just backing up her files, SugarSync decided to duplicate over 10,000 files – eating up all her hard disks and cloud storage. The Cranky PM then spent lots of time using 3rd party tools to remove the duplicates. The end result was a lot of lost time and at least a few lost files.

Irritating, to be sure. But the Cranky Product Manager is nothing if not forgiving of buggy newish products. It’s what SHE DOES, after all.  So, reassured by the SugarSync Support that this was a one-off situation related to their latest upgrade, the Cranky Product Manager carried on and continued to use their service.

And then a month later it happened again.  Argh! This time the Cranky Product Manager searched the SugarSync Forums for answers and found multiple threads related to this duplicate file issue.  The most enlightening was this: http://sugarsync.hivelive.com/posts/c6fb6fb9db

This thread reminds the Cranky Product Manager about everything that is frustrating about dealing with a certain type of Code Boy:

1. Despite overwhelming evidence in its own forums that MANY customers experience this mass-duplication of files, the SugarSync CodeBoy(s?) (username “admin”) insists that this problem is a “corner case” and never really happens.

(We can tell that it is an actual code-slinging CodeBoy in the forum, because no self-respecting Customer Support Engineer would ever take this kind of attitude with a customer).

2. The SugarSync CodeBoy then pushes the burden of the bug onto the customer — insisting that they open support tickets, collect and mail in logs, etc…

3. The customer doesn’t send the logs in because:

*  They are busy manually cleaning up the duplicate file mess and don’t have time to also help debug SugarSync’s software, and

* From the tone of the previous messages it is OBVIOUS to the customer that SugarSync does not recognize this as a genuine problem, and realizes it will be an uphill battle to convince SugarSync otherwise.

4. The SugarSync CodeBoy declares victory:  “The customer won’t cooperate with me in reproducing this bug!  I can’t do anything!  So, this bug must not really exist!” Plus, I AM RIGHT! HAH!

……………………

Excuse the Cranky Product Manager while she strangles a voodoo doll that she created of this CodeBoy….

…OK, feeling better now.

Gotta say, it’s kinda rare to see this type of exchange played out in a public forum like this. Usually the Support people rightly prevent this type of unempathetic, obnoxious Code Boy from interacting with customers and others outside the company.

But within the company, who in Product Management has not encountered almost the exact same crap from a CodeBoy/Girl, at least once a release cycle?  It is ABSOLUTELY MADDENING!

To have someone deny that a problem exists when MULTIPLE people have encountered it?  To be told that the problem you are clearly experiencing  is a “corner case” that doesn’t ever really happen?  To be told its somehow your fault – some kind of user error situation?  To have the Code Boys & Girls demand that YOU do THEIR effing jobs by spending ungodly amounts of time reproducing their damn bugs and verifying their alleged “fixes”?!?

AS IF product managers don’t have ENOUGH to do near release-end (market launch, get pricing proposed and approved, collateral & product training, and running beta programs, not to mention being neck-deep in planning the next release….the list goes on and on.), but now they have to be QA engineers as well?

All because some frigtard CodeBoy/Girl thinks it impossible that his/her code has bugs in it??!!  Enough that s/he is completely denying the situation despite a preponderance of evidence?

WTF!!!!!!

BUT THEN, serendipitously, the Cranky Product Manager received a Truly Awesome article from a Code Boy who reads this blog.  It’s about the process an Engineer goes through when faced with a thorny bug.

And now the Cranky Product Manager understands just a little bit better.  She still wants to keep her voodoo doll collection of CodeBoys close at hand, but at least she’ll feel a bit more empathetic when sticking it with pins.

Read the guest post from Code Boy Extraordinaire in the next article (coming in a few minutes). It’s required reading for any product manager who has ever had a bug s/he reported marked as “not reproducible.”

–The High Cost of Product Line Complexity (plus Proof the Cranky Product Manager is Female)

Every now and then the Cranky Product Manager learns that some member of the Crankerati is theorizing that she is not really a woman, but is in fact a hot dog and beans totin’ Dude. After all, what better way to be a spineless wuss than by hiding behind an anonymous persona of the opposite gender?

Well, this post (coupled with the recent few about sexism in software), should debunk that theory once and for all.  No way you’ll think the Cranky Product Manager is a “Dude” after this.

Let’s set the scene.  A few weeks ago, the Cranky Product Manager went to the pharmacy to purchase the most womanly of accoutrements. Yep, you guessed it, maxipads.  Now, even women who LIVE to shop don’t like to shopping for “feminine protection,” but alas it must be done now and then.

Anyway, the Cranky Product Manager walked into the store aisle dedicated to such matters. And, as usual, she was confronted with an overwhelming morass of confusing product choices.

The below photo does not do the scene justice – it covers only about 20% of the entire product selection and only shows about 1/3 the shelf space dedicated to the Always brand. Over 50 product varieties, 20+ from Always alone.

IMG00380-20091009-1137

The Cranky Product Manager has to tell you that when she saw this, well, she was frackin’ PISSED.  Again. Cuz it was the same way last time she bought pads too.

WARNING TO MALE READERS: you may skip the following paragraph.  Yes, you men are all so tough and manly and have copious hair on your chests. Plus you can HUNT DOWN PREY and kill stuff, WATCH sports, use POWER tools, and belch like beer pong champions.  But alas, despite the awesomitude that your Y chromosomes have collectively bestowed upon you, your delicate ears simply cannot handle maxipad talk, much as you cannot function when you have a cold.  So, squeamish males, please skip the next paragraph and recommence reading after the italicized text.

OK, ladies, believe me when I say this product assortment made no frackin’ sense. As far as the Cranky Product Manager could tell, she was dealing with at least 6 different variables — wings/none, absorbency, thinness, length, width, odorless/”fresh”  — and each box on display had a different combination. PLUS each box had a different number of pads, which made price comparisons nearly impossible. From what little she was able to discern, the pricing made no sense, with the less desirable combos costing as much or more than the more desirable ones (who on earth is going to buy super-thick, minimally absorbent pads without wings anyway?).  And then there were the “marketing nonsense” features, where they claim something is “Infinity” and charge more but don’t explain wtf “Infinity” is or why it’s worth more.  (Also, someone please let the Always people know that NO ONE wants a period that lasts until “Infinity.”)  To further add to the confusion,  there are multiple brands, plus the damn CVS brand which THEY INTENTIONALLY package to look just like the manufacturer brands, just to eff with your head.

Yes. The Cranky Product Manager was pissed at this ridiculous cornucopia of choices. Why?

1. It made the purchase take WAY too long. The Cranky Product Manager wanted to spend 10 seconds on this purchase, not 5 minutes.

2. She realized NO WONDER her Darling Husband (the household’s designated grocery shopper) always came home with the wrong frackin’ pads!   Those jerks made the purchase process so complicated that it couldn’t be delegated.

But even more annoying were #3 and #4…

3. She felt she was being tricked.  WHY put out a ridiculous product assortment like that, with pricing that looked randomly generated, unless they were trying to confuse consumers into buying something less desirable for too much money? After all, they deliberately made it impossible to compare features and prices, plus there was that marketing nonsense talk about Infinity “features” that have no apparent benefit. It just felt dishonest.

4.  She felt that the perpetrators of this crime against products did not respect or understand the purchase process of long-time repeat customers. Sure, they might have understood how she USED the product and provided great products to meet those needs.  But they did not respect how she wanted to BUY the product.  As in, I DON’T want to learn about your new features and packaging options while I am AT the store! Don’t make me the weirdo who hangs out for long lengths of time (or takes photos) in the feminine hygiene aisle!

The Cranky Product Manager was highly annoyed. Stupid retailers & manufacturers!  Idiots!

But then she thought about the byzantine nature of most software companies’ product and price lists. And how nearly every good, simple product inevitably decays into a labyrinth of derivative products/options with dubious differentiation and cryptic pricing.

Seems that we software product managers and marketers are not so different than those maxipad people.  In fact, we are way worse.  If a software company has shipped product for more than 5 years, the product/package/price list probably has 100+ lines, each with its own method of calculating price and with multiple dependencies between items.

And we are thereby annoying the heck our customers. The complexity of our product lines:

  1. Forces repeat customers to spend time they don’t have researching purchases for products that they already know quite well
  2. Increases customers’ workload, by preventing them from delegating the purchase
  3. Makes customers feel like they’re being taken advantage of
  4. Makes customers feel like they’re not being respected or understood.

This situation is not at all what Product Managers intend when they decide to make that new feature only available as an add-on option. Or when they introduce that new technology in a bunch of completely new products, while letting existing customers to carry on with upgrades to the old products.

Alas, it only takes a few of these well-meaning decisions to make product line complexity explode. Watch as your efforts to make customers happy completely and utterly backfire, and as your sales, support, development, marketing, and overhead costs simultaneously skyrocket.

–Product Management Haiku, Redux

 

In their spare time, the Product Management Crankerati just LOVE writing haikus.

Check it: here (Pivotal PM), and here (previous Cranky PM post), and here (Product Management Meets Pop Culture), and here (Tyner Blain), and here (On Product Management), and here (Spatially Relevant).

The fun just never ends.

Anyway, here’s some brand, spankin’ new haiku from the Cranky PM.  From her sleep-deprived, addled brain. (Too many products to manage, too many kids to parent – at home and at work.)

As always, submit your own Product Management Haiku in the comments!


Feemium product
has too many great features.
No one upgrades. Crap.

CTO sees the
bright shiny object du jour.
Development stops.

Virtual dev teams.
Half of meetings are now spent
debugging A/V.

Agile dev process
moves bottleneck from Dev to
Product Management.

Product Manager
who cannot use his product
should be fired. Now.

The new Architect
always demands rewrite of
every line of code.

Hey, Support Martyr,
some enhancement requests won’t
get done ever! Chill!

Sales Droids always bitch.
Unless they can do no work,
but still collect checks.

The Agile stand-up
should be 10 minutes, not hours.
My feet really hurt.

– How to Be a Jackass Product Manager in Nine Easy Steps

1. Don’t visit customers. If customers want to talk to you, ask that instead they put their list of enhancement requests in an email or a spreadsheet. Take said list and cut/paste it into Jira. Don’t bother to find out WHY the customer wants any of this stuff.  If the execs pressure you to do talk to more customers to validate your plans, send  out a 300 question survey. If no customers respond, it must means they all agree with everything you plan.

2. Don’t learn how to use your product, ‘cuz you’re too consumed with being a blathering “visionary” (albeit a visionary who never defines and articulates a true product vision) to be concerned with such details. Plus you’re far too elegant a gentleman/lady to eat your own dog food. Disgusting!

3. Become an email router.  Insist that the field write you emails (no phone calls!) whenever they have technical  product questions.  Forward those emails directly to selected developers.  When they answer, forward the email directly to the original asker.

But BE CAREFUL. For this to work correctly, you MUST insist that the sales folk NEVER EVER contact developers directly, and vice versa.  YOU must always be the intermediary, even though you’re just an email router.  Take care NOT to add any value to the exchange, such as translating detailed techno-blah-blah speak into Sales-friendly English.

ADVANCED MOVE: Remove the email headers and other indentifying info prior to forwarding emails, so that the sales reps can’t wise up and contact developers directly. This move makes it look like YOU were the one who actually answered the questions! Congrats!  Also, make sure you don’t send all your questions to the same developer, or soon he/she will be on to your little scheme.

4. Overengineer a small part of your job and do it to the hilt, ignoring every thing else. For example, spend at LEAST 150 hours developing product training for Sales.  And then schedule at least NINE different 2-hour time slots to give the training, so that each sales rep can pick and choose his/her favorite time slot from the nine. This will make training completely occupy your time for almost 2 months, giving you an excuse for never getting around to your product strategy.  And — best of all — you get to bitch n’ moan about being SO overworked!

5. Decide what features are in and out of a release based on one overly simplistic measure, like the number of customers requesting X in the bug tracking system. Don’t worry about whether the request is actually an implementation-level detail and a kludge at that. Don’t worry about whether your product is actually solving the underlying problems that the customer has.  Don’t worry about whether the feature has broad applicability to your target markets.  Because that would require you actually know what your target markets are, and you’re too busy being a Jackass Product Manager to find that out, right?

6. Whenever you are forced to get customer feedback, call that one geeky customer who thinks _everything_ your company shits out is a gold nugget, because his resume is so wrapped around your company’s technology that he would have serious career problems if you changed course.  He’s so TOTALLY representative of your customer base, as well as your future target markets, right?  And thus he is a wicked awesome source of unvarnished feedback, validation, and advice.

7. Get into a swinging dick contest with a technology analyst.  Get out the rulers and start measuring. Cheat, if you must, to make sure yours appears bigger. Talk down to the analyst and disagree with everything he/she says.  Because those Gardeners and Forest Rangers just LOVE it when you downplay their expertise.  They are such an ego-free bunch that they’ll actually appreciate your product EVEN MORE if you call them idiots to their faces.

8. Go around saying stuff like “explain this technical concept to me as if I were a 5-year old,”  ‘cuz that’s the way to get the respect of Development.  They don’t mind _at all_ if the person laying out the future direction for their _child_ (aka their product)  seems to have the mental capacity of Paris Hilton.

9. Be a complete jerk to your fellow product managers.  Monopolize team meetings with your concerns.  Don’t let anyone else speak.  Pontificate at length – have fun with it! Undermine the broader product line vision in order to elevate your product at the expense of the others. Blame as much stuff as you can on the other PMs. Undermine their credibility in front of Development, and later in front of Marketing and Sales.  They’ll respect you for it. Really. But watch out if one of them becomes your boss one day.

–Sexism in the Software Industry, as Encountered by the Cranky Product Manager

Following up on the previous post about the deepening dearth of women in the software industry, here are some incidents of outright sexism that the Cranky Product Manager has encountered in this industry.

Admittedly, most of these are pretty mild.  After all, she doesn’t feel she was every denied a promotion or made less salary because she was female. She was never pressured to “do” anyone.  And she honestly believes that the overwhelming majority of men she has worked with really WANT to see more women in technical and product roles, and to see them advance.

But still.

And no, The Cranky Product Manager never reported any of these incidents to HR.  Maybe she should have, but – let’s face it – it probably wouldn’t have changed things anyway.

(From here on, I’m changing to writing in the first person, away from the official “Cranky Product Manager third person,”  in order to help emphasize that these things REALLY happened to me.)

1. Being one of the 4 engineers in an R&D group of 20 that were not invited to the big industry tradeshow in Vegas. Three of the four of the “left behinds” were women, and all 16 that attended were guys. The excuse was that we women would not have had fun, and they didn’t think we’d want to attend anyway since most of what they did was go to strip clubs. (The group came back from Vegas with lots of awesome research project ideas, triggered by their conference experiences. Experiences that we women missed out on.)

2. Booth babes at trade shows. Every year. And having people assume that the  _I_ am a know-nothing booth babe who doesn’t know HTML from NoSQL.

3. Account managers asking me to please flirt with a prospect’s tech guys on sales calls and referring to me as “Nerd Bait.” Because “those guys get off on geeky chicks.”

4. Attending a Sales Kick-Off party where the CEO hired an “actress/comedienne” to perform / strip for the company. (You see, she only got down to her bra and panties, so it was “okay.”)

5. Scantily clad women (no men!) dancing in cages (and sometimes in bathtubs)  and groping each other, at the “big party” every year at the Annual User’s Conference for customers and partners.

6. Having the skeevy, drunk Division GM, dressed as Santa Claus, basically force me to sit on his lap during the Christmas party. For an excrutiatingly long three minutes.

7. At one of my first jobs, being referred to as the “Build Mistress.”  This isn’t bad in itself, because I was indeed the Build Master/Mistress.  But the dominatrix jokes (and white board doodlings) stopped being funny after the 25th repetition.

8. As an engineer at an early-stage startup, being sent home to change and scrub the makeup off my face prior to a meeting with prospective Venture Capitalists.  Because the VCs would never believe that I was a serious engineer if I wore a skirt.

9. Having every visitor to my startup’s office assume I was the office manager just because I was the nearest female to the door, even though you had to walk past 6 or 7 men to get to me.

10. When interviewing at a startup with no female employees, I attended a “company meeting” to get a feel for the culture.  The VP of Engineering dropped the F-bomb and a few other swears (big deal!). But THEN the speaker turned to me and said, “Excuse me! I didn’t realize we were in MIXED company.” Later he made a blow job joke and said “Oops! I keep forgetting we’re in MIXED company!”

Way to make a girl feel at home! Keep pointing out she’s different than everyone else, under the guise of “politeness.”   And PLEASE, I drop more F-bombs before breakfast than that douchebag does in a week.  (this is not a good thing, but it is what it is.)  Needless to say, I did not join this company.

Software Sisters, add your own experiences in the comments!

–Biz of Software 2010, Women In Software & Frat House “Culture”

The Cranky Product Manager had the pleasure of attending Business of Software 2010 last week.  Yes, she was there, but incognito.  It was a fascinating conference, chock full of interesting speakers and lots of learning.  Seth Godin was there.  He’s wicked awesome!

The attendees were mostly technical founders of small software companies.  Many were pre-venture financing, but many (most?) had no interest in venture financing and were bootstrapping. All were interested in learning how to build a thriving software business – whether the goal be building the next Microsoft, getting acquired, or just having a thriving business that funds a great lifestyle.

The Cranky Product Manager has a lot to write about this conference – it triggered a lot of new thinking for her.  Hopefully, there will be a few more blog posts.  (Let’s see if she gets around to it.)

But here’s an observation that struck her, powerfully, as soon as she arrived:

White Dudes Everywhere, As Far As The Eye Could See

About 85% of the ~300 attendees were white guys of all ages. Of the remaining 15%, about half were non-white guys, and half were women.

Where were all the NON-WHITE guys? 

In Silicon Valley, the Cranky Product Manager is used to working with a LOT more Asian guys and Indian guys, in both technical and business roles. In fact, at many companies in this area, she’s often found herself to be the only white one in the room.

Is this ridiculous skew an artifact of the conference being in Boston?  Or, well, ….what other explanations are there? The Cranky Product Manager is truly puzzled.  In this respect, she does not believe the demographics of this crowd reflect the racial makeup of most software startups.

Where were all the WOMEN? 

The Cranky Product Manager has truly NEVER been in such an overwhelmingly male crowd.  Seriously.  She even went to a Random Institute of Technology in the 90s, majored in Computer Science, took Physics, and was in Army ROTC.  Yet she has never experienced such a sausage-fest.  The line for the men’s room snaked down the hall, while the women’s room had copious empty stalls!

The Cranky Product Manager was again puzzled, and tempted to dismiss this as an aberration – not reflective of the true demographics of our industry.

But then she thought again and realized that in her experience at software companies, the percentage of women has been declining for years now. In fact, she suspects that the highest percentage of women in the software industry was probably around 2001 and has been on a downhill slide ever since.  Her suspicions are further confirmed by the National Science Foundation, who found that the proportion of women studying computer science has decreased from 37 percent in 1985 to 19 percent today.   A huge drop of nearly 50%!

Fascinating, however, was the absolute conviction of many conference attendees (especially the younger guys) that there were far more women in the software field today than 10 years ago. This just ain’t so, but perhaps each generation’s default assumption is that they are more socially equitable than the previous generation. (kids today, tsk tsk…)

All this got the Cranky Product Manager thinking: what happened to all the women?  Why is it getting worse?

The Typical “Why So Few Women” Theories

TechCrunch has been publishing a lot of articles that theorize on why so few software startups are founded by women.  Many apply these theories to software in general – startup or not. The typical reasons given for women’s poor representation include the following:

  1. Women prefer to focus on family & children instead of career, and software startups are too demanding to do both adequately
  2. There aren’t enough women majoring in computer science fields in college
  3. Parents, and society as a whole, discourage their daughters from studying computer science.
  4. And the often-thought-but-infrequently-verbalized-because-the-speaker-would-be-evicerated idea that women are just not as smart as men when it comes to computers.

A lot of these theories just don’t hold together from the Cranky Product Manager’s point of view, especially when you consider that there are now fewer women in software than ten years ago.  Something changed.

For #1 “Focus on families over career”  – Has the situation for women really changed so much in the past 10 years?  Are we really accepting a statement that far less women are interested in their careers today than 10 years ago?  Further, this statement would seem to affect any demanding field, not just tech.  Yet, the percentage of doctors and lawyers (extremely demanding professions) that are female has increased substantially in the same time.

For #4 “Women aren’t as good at tech” –  The Cranky Product Manager isn’t going to step in that one. It might be true for all she knows, but she still thinks it is obvious that the most brilliant women will bring more to the software field than average men.  Mean ability might differ, but the ability distribution within each gender are wide, and the gender curves overlap mightily.

For #2 “Not enough female CS majors” – Is this a cause or an effect?  Is it related to #3? If the opportunities for women in tech are not that great, then it stands to reason that the number of women majoring in it would decrease over time.

For #3 “Parental & societal discouragement” – Well, maybe this is the real culprit: that parents and society at large discourage our girls.  The Cranky Product Manager believes that there is something here. But as a parent herself, she doubts that is because parents assume that their girls are too dumb for software, or that software is too unfeminine.  Instead, her intuition (no stats to back this) is that parents might discourage girls from the software business because, well, it just isn’t that hospitable to women.

Now, the Cranky Product Manager hadn’t really thought about this “inherent inhospitable-ish-ness-ity” before. It’s not something that the Cranky Product Manager necessarily feels as she works day-to-day in this industry.  Virtually all of the men she’s ever worked with are open-minded, are committed to equality in the workplace, and very much want to harness the intellect of top-performing women for their own gain.

(Not that the Cranky Product Manager hasn’t experienced some outright sexism. She has. Maybe in a future post she’ll tell some stories.)

But maybe there is something else that makes this industry inhospitable to women — something more structural than personal in nature.

The Cranky Product Manager admits her thoughts are only partially formed on this point, and she hopes to consider it more fully and post on it later.  But here is one (maybe minor) idea about “systemic inhospitability” to women in the software industry: the prevalence of “frat house culture.”

Frat House “Culture”

Too many software start-ups attempt to develop a so-called “corporate culture” based on frat house living.  Beer bashes, video games, foos-ball tables, pickup basketball teams, free soda, fantasy sport leagues, mandatory scavenger hunts and team-building nonsense (inevitably on the weekend), etc.   Oh yeah, did we mention the beer?  FREE BEER!   Now THAT’S a WICKED AWESOME COMPANY CULTURE!

The dude from Atlassian, Scott Farquhar, spent a lot of time at Biz of Software describing how awesome their culture was because of all these “perks” or whatever.  No thanks.  (This is not meant to bash Scott: he raised many other interesting points about starting successful software companies.)

From the Cranky Product Manager’s female (and older) vantage point, this all seems so stunted and sad.  Like a geeky 11-year-old boy’s idea of paradise.  She knows that many women don’t fit into such “cultures” (they were never meant to, after all) and never quite feel at home in them.  The Cranky Product Manager knows she never really did, although she played along.

Maybe if instead of aspiring to this type of immature fantasy, software companies could attract and retain more top-performing women with better support for families and for having a life outside of work? Just an idea.

How about more equitable parental leave policies – not just for pregnant women, but also for Dads and adoptive parents?  If you improve Dads’ ability to contribute at home, you will TOTALLY improve lives for the professional women who married them. Or maybe offer more help with finding and paying for quality childcare?  Especially options for childcare when the kid is sick, or if you want us (Moms and Dads alike) to travel out of town at the last minute.

Conclusion

Hah!  Fooled you.  There is no conclusion here. The Cranky Product Manager has no ground-breaking ideas or anything.  It occurs to her that the few ideas she proposed are very mom-centric, and don’t explain how to attract and retain the women without kids.

Maybe you have some better ideas?  Please contribute them in the comments!  (Hopefully, they are ideas that are not out of reach for startup companies.)

And this post doesn’t explore whether it is even essential to attract and retain top-quality women anyway.   Maybe it isn’t. The software industry as a whole (plus that douchebag Michael Arrington) certainly acts like it isn’t much of a priority. The Cranky Product Manager intuitively thinks it is important, but aside from her own self-interest she doesn’t really have a lot of proof.

What do you think?