PM Rant

What are some common misapplications of A/B testing?

Over the years, I've seen A/B testing used a multitude of ways, sometimes well but more often inappropriately. Here are some examples of how A/B testing should not be used and why:

Using A/B testing as a substitute for innovation or design. A/B testing won't produce an iPhone! All A/B testing can do is optimize around a local maximum.

Trying to find a subtle difference with a sample size that's too small. You need some level of statistical significance, and the smaller the difference in performance, the more users you'll need in your study to find it.

Continuing to test after you're close enough to the local maximum. Some companies go nuts with A/B testing trying to find minute performance improvements when they should instead spend their time developing a next-generation solution (trying to find a new global maximum).

Trying to get an immediate result. A/B tests are sometimes used on existing customers, who are used to a different experience than the one you are testing. So, if you see a difference in performance between test and control, you can't tell if it's attributable to difference in design (which is what you are trying to test) or whether it's attributable to the element of surprise. In the case of changing search algorithms, almost every tweak generates a lift... but only temporarily. It's not that the new algoirthm is better, it's that it's new. So, you need to run the test long enough that this "newness effect" is accounted for.

Measuring the wrong variable. A/B tests are often used to improve completion rates of multi-step flows. For example, creating a new account, filling out a questionaire, completing a survey, etc. Let's say you're trying to generate mortgage leads by showing a banner ad, followed by a landing page, followed by a questionaire, follwed by an explicit agreement to be contacted by a sales rep. If you run A/B tests on the banner ad, you can't just measure the impact on click-through rate - you have to measure the impact on the final completion rate (through the rest of the funnel). As an extreme example, you could probably double the click-through rate by putting a racy picture of a woman on the banner, but whatever users you pick up with the new ad were never going to complete the form in the first place, and you just alienated (and are no longer getting clicks from) your target demographic of professional females. The racy ad looks better if you measure click-through rates but is clearly much worse if you measure the real target variable of quality leads.

Transplanting into a fragile system. You can wreak havoc by transplanting a new component into an otherwise interdependent system. This happens in biological systems all the time. Transplant an organ that works far better than the failing one, but the immune system goes haywire. Introduce a new species that feeds on a pest, and they destroy entire ecosystems. This can happen with A/B testing as well. You might substitute one module for another, see good performance metrics, but throw off users' mental model. You might acquire more users but change your demographic completely. Measure the potential side effects and don't commit to a modified product design based on the outcome of your A/B test until you're confident you haven't thrown your system into disarray.

What is the one business article or interview that all Product Managers should read?

For me, it has to be "The Institutional Yes", which is an interview with Jeff Bezos, CEO of Amazon, published by the Harvard Business Review in October 2007. I admit that much of my own thoughts on product strategy were formed by reading this interview.

It covers a lot of things, but a few in particular:

• Bezos encouraged his executives to develop a long-term strategy that was based on whatwouldn't change in the future. Almost everyone gets this wrong. Consider for yourself, what it is about your customers' needs that you can count on being the same year after year? For Amazon, it was that customers want wide selection, low prices, and fast & reliable delivery.
• Bezos made decisions that would have seemed heretical at the time, such as showing side-by-side identical yet lower-cost buying options for Amazon's own merchandise. He was willing to challenge the status quo and place big bets that external customers were more important than internal stakeholders. He couldn't have been more right - especially in a large organization. Never allow the organizational structure of your company dictate what your development focus should be.
• Bezos said "Eventually we have to choose just a couple of things...and make bets." And they made big bets at Amazon: expansion outside of books, outside or media, supporting third party sellers, taking on their fulfillment, building the Kindle, and creating a developer-facing business. What are your long-term bets and are you betting big enough to ensure that their potential will be realized?

These are lessons that every Product Manager could stand to learn from. But, the reason this interview had so much of an affect on me is because I found myself on the losing end (with close to the opposite strategy) while at eBay from 2001-2005. eBay did exceedingly well in that time, and yet was getting its ass kicked. The success fueled by new user regsitration masked the underlying reality that Amazon was stripping away eBay's higest-value buyers with a more convenient shopping experience, and this was finally exposed in later quarters when eBay's stock declined by over 50% (and that was before the stock market crash in '08). (If interested, you can read more on this in an interview with me conducted by my friend and former eBay colleague, Rob Go.)

I always wanted to know what the winning consumer product strategy looked like from the top down. If you want to know, too, you should read "The Insitutional Yes".

How many design flaws can you find in this microwave's UI?

This is a true disaster. There are so many things wrong, I don't even know where to start. Perhaps I should tell the story of my first attempt to use it.

I grabbed a can of soup from the pantry, dumped it in a bowl, threw the bowl in the microwave, and... and... uh. Hold on. Hm.

The can said heat between 2:30 and 3:00, so I was thinking 2:40. Well, there were no numbers. I guessed the bigger button was a knob, despite having no markings. So, I tried turning it clockwise to add time. No dice. Nothing happened.

Maybe I had to start by clicking Start. I tried that, and again, nothing happened.

Next, I thought, well, sometimes, there's a "time cook" or "cook" button you have to hit before you can get started. So, I scanned for it and found it in the lower right hand corner. I pressed Cook, and it brought up a menu of which only part of it was legible in the display window at the top. I didn't want a menu. I just wanted some warm soup.

I found Off/Clear in the upper right hand corner and hit that button. Good, menu gone.

Then I noticed that below the knob there was a power button. Maybe the whole thing was powered off or something? I pressed it and still nothing happened. Wow. This thing is killing me.

I stood there for a sec, stunned I couldn't get a microwave to work. Then I remembered that the namelss knob was a little wobbly. Maybe I had to press it to start. Well, it turns out it is a pressable button, but it also does nothing. Finally, I resolved to actually read every individual button, and I finally saw Time Cook on the left side. I pushed that and then rotated the knob, which added time in 15-second increments. I then pushed Time Cook again to confirm and start. Nothing. So, I pushed the button/knob. It beeped but didn't start cooking. I scanned the buttons above and saw Start (only after dismissing it originally because it was also labled as Pause). Finally, I pushed Start and heated the soup for 2:45.

It might have been easier to cook it over a campfire.

So, what's wrong with this piece of shit. I could count at least ten independent things, almost all of which are noticeable just by looking it, and I'm sure there are many more build into the actual interaction.

Here are the flaws I found:

1. No number pad. If I learn it takes 2:35 to boil a cup of water, that should be easy to do over and over again. Punch 2-3-5-Start. Done.
2. Labels between buttons. If you glance at the left column, you can't tell which button corresponds to the Defrost label. You have to read the other labels before you can tell that labels are above buttons rather than below. Placing labels closer to their corresponding buttons would help.
3. No context for Combination. The word "Combination" is a poor button label without context: combination of what? I guess it's a mix of convection cooking and standard nuking. This could be clarified by the relative position of the button, but at the top of the list, you just can't tell.
4. Missing toggle indicator for Convection. I can hit Convection, then add time, but there's no indicator that it's actually on convection mode. A simple light embedded in the button would suffice.
5. Floating Power button. I assume microwaves are always in "standby" mode, so it's probably not the same kind of "power button" my DVD player has. Changing the label to "Power Level" would resolve the confusion.
6. Cook, not Time Cook. Obviously, you're cooking it for some amount of time, so what's the difference between Time Cook and Cook? Cook is a Sensor Cooking option so is a variable amount of time, but unless you also see that there's a separate Time Cook option you wouldn't know that.
7. No label for the big knob. Other than sticking out farther, there's no indication it's actually rotates. Afer you turn it, there's no indication you can push it, which you can (or what pushing it would even do).
8. Applicability of Sensor Cooking. Is the Options button inside or outside the Sensor Cooking section? It's not obvious, and yet would probably influence the user's expectations when clicking the button, perhaps even the context of the menu items listed after it's clicked.
9. Defrost isn't Sensor Cooking. It turns out that Defrost is both a sensor and timed option. So, why does it not show up in the Sensor Cooking section? Once you push this button, you can push it again to toggle between sensor and timed options. So why is there one button with  toggle for "defrosting" but two separate buttons for the corresponding "cooking" options? Jeez.
10. Misplaced Clock and Timer buttons. Almost all microwaves are guilty of this. Why not put them next to the actual clock? I mean, I see the time. I also see it's wrong. I want to update it. The first button I see should be the one I need to push.

I thought I'd spend 15m taking a stab at an improved version of the interface without actually changing any of the functionality, settings, options, etc. Better? You tell me... but, God, I sure hope so.

 

What's the recipe for invention?

If you give a plant water, sunlight, and nutrients, it will grow fruit. And, if you mix sugar, flour, and butter and then add heat, you get cookies. So, what's the recipe for a team of technologists to continuously develop new product ideas?

First of all, thanks to the commenters for their interesting points of view. I particularly liked "challenging the status quo" and striving for "clarity on constraints and goals".

Here's my formula for driving invention in a tech company.

1. Know your full range of capabilities.

It's great to know the constraints to a problem, and constraints create necessity which is (sometimes) the impetus for innovation. Just ask NASA or the military. But I argue it's even more important to learn what are not constraints. What data do you have that you didn't even know about? What white label applications are available? What academic research is already compiled? Know what's out there.

2. Understand the fundamental business problems.

You can tinker with technology 'til the cows come home. You can also get distracted by working on surface-level business problems that don't really matter. Why did your customers buy your product? Why made the customers of your competitors choose something else? What constraints do they have that you could make go away?

3. Share information!!!

This is the most important ingredient. If some people are away of the capabilities (#1 above) and other are aware of the opportunities (#2 above), but no single person knows both, then you're screwed. There's only one way to fix it, which is to share information the other party doesn't know they should be asking about. The best example: Product Managers should talk to Developers about what they're trying to do. Engineers should talk to Product Managers about what has their hands dirty. This is best done informally, in small groups, with conversation and without PowerPoint.

4. Be methodically imaginative.

Over time, it's easy to take constraints for granted. Remove one single constraint. Then try to solve it again. If that solution looks a whole lot better, then figure out how to eliminate the constraint. Keep doing this one at a time until you've cycled through all your key constraints. You may realize some are holding you back enormously and others very little. If one of your hypothetical solutions looks substantially different - and radically better (or easier) - then you know where to focus. So, think. What if your privacy policy changed? What if your cost to serve was $0? Challenge the conventional wisdom specifically because it's just that... conventional.

5. Develop a culture of "yes".

"No" is not a complete answer; a complete answer is, "yes, if only we had <fill in the blank>". You'd be amazed how often simply stating what would make things easier can do... for relationships, for earning trust, for identifying root issues, and most importantly for driving innovation. Also make a point that good ideas can originate from anywhere. Then take those ideas seriously when they're presented. And recognize that ideas you hear (as a Product Manager) are typically shorthand for problems and solutions. Usually, with a little abstraction, you'll discover some real nuggets.

6. Finaly, provide "the spark".

Invention is like a chemical reaction that requires activation energy. You can mix all these ingredients and they can become volatile, but they still need that extra "kick". So provide it. Give people time to break away from their "normal" routine. Give them room to run with an idea. Let them down-prioritize something else. Pay for lunch. Get offsite. Visit a client. Listen in on fiery customer service calls for an hour. Establish your own version of Innovation Day.

To all you "people managers" out there: if all you push on is efficiency, that's all you'll ever get!

Should Product Management and Engineering use the same KPIs?

Yes.

Now, most companies separate the KPIs between the two teams. They are right that Product and Engineering are fundamentally different roles, but those companies are wrong to measure their respective performance independently. When operating properly, Product Management and Engineering are two halves of a whole: Product Development. And they should be measured as such. 

Here's what you gain by using a common set of KPIs:

• Complete alignment between the two groups
• Engineering caring about what they're building as much as they care about how it's built (value focus instead of technology focus)
• Product Management orientation around real delivery vs. unrealistic pipe dreams of monolithic product modules

And here's what you can avoid:

• Finger pointing, rather than constructive problem solving, as a result of failure
• Arguments about whether a customer concern is a feature request or a bug
• (Often unintentional) Gaming of metrics, making one's own group look good at the expense of the other (and thus hiding root causes from management)

Consider the parallel between how Product Management and Engineering work together and how a football team is organized. The offenses and defenses have totally discrete functions: the offense puts points on the board; the defense keeps the opponent from doing so. And each "side of the ball" is comprised of different players; in fact, offensive and defensive players hardly ever play together. But together, they win or lose football games.

On the surface, it seems like the head coach could "manage" each side of the ball independently. If the offense always put up more than 24 points and the defense never allowed 24 points, they'd win every game. But by managing the offenses and defenses against those measurements, he'd probably end up losing every game. The offense would never punt the ball. They'd just keep robotically going for it on 4th down no matter their position on the field. They'd never bleed the clock when winning. Defenders would never risk allowing a big play to get a turnover. It would be a disaster.

Offensive and defensive strategy must align around a single cohesive binary metric: whether the team wins or loses. It's not to say they can't also track other statistics specific to offense or defense. (Football has plenty of statistics floating around these days.) But tracking them and managing against them are very different. Similarly, I recommend that Product Management and Engineering track metrics that are specific to their own groups, but used primarily for diagnosis rather than performance grading.

So, why don't more companies set the same performance metrics for Product Management and Engineering? I think it's for a set of sad reasons from both the top-down and bottoms-up directions:

• CEOs generally prefer to have exactly one VP accountable for each function so they can focus directional guidance and coaching - and so they know who to fire when guidance and coaching don't work.
• And, Product and Engineering VPs tend to avoid signing up for metrics that are outside of their direct control so they don't get the blame when they individually "do well" but collectively fail.

Basically, the CEOs are being lazy and the heads of Product and Engineering are scared for their jobs.

Don't be scared for your job! Put your ass on the line. Sign up to accomplish things that you don't necessarily have direct control over, like code quality of the next release or making a delivery date. Ask Engineers to do the same - they should sign up for metrics like higher opt-in rates, lower retention, or beating your top competitor to win the next 5 deals. Then work together to meet your common goals.

What are the best methods for gathering requirements?

At first, I thought this question was lame. Why not just ask them what they want and then build that?

One of my earlier blog posts was entitled Stop Listening to Your Customers. The point was not that you should ignore your customers, but that simply asking them what you shoudl build in the next version of the product is counter-productive. Customers suck at telling you product requirements: they quickly get confused between the problem space and the solution space, and ideas for how their needs can be met without considering the 10 new problems they create along the way.

Requirements gathering is all about forcing your audience to tell you what's actually important based on what they're actually knowledgeable about.  Here are 10 successful methods to gather requirements - and note that they are not all based on direct interviews of customers.

1. Attend a usability study. Watch actual users actually use your product. Have them say what they're thinking as they use it. There's no substitute.
2. Play the Product Box "Innovation Game", pioneered by Luke Hohmann. Luke knows what he's talking about. In this exercise, you ask a would-be customer to create a box for an on-the-shelf version of your product and then have them present an infomercial back to you.  Pay attention to what your customers do and don't say.
3. Rank the essentials. Once you have a working (and successful) product, don't ignore the essential components - you'll need to keep investing in them. Doing so would be the equivalent of an auto manufacturer ignoring the engine and focusing exclusively on new exterior paint colors and body shapes. Don't know what the essential elements are? Ask yourself what parts of the product, if broken, would have the most detrimental impact on the business. Then, make those better. I learned this one from Leonard Speiser.
4. Analyze your losses. Too many product managers focus on the needs of their existing users or clients. You existing customers already selected you, and by talking to them, you'r just drinking the Kool Aid. To get more customers, talk to the ones who decided not to buy/use your product. Find out their rationale for why they didn't, then address those problems.
5. Compare features. Offer your customers an option between two features and have them select which is more important. But don't stop there. Ask them why they would choose one feature over the other. It's the answer to the question of "why" that tells you everything you need to know.
6. Role-play with the Sales team. If you're selling into enterprises, have a salesperson on your team sell an idealized version of the product to you. They get to pretend that the product does everything they wish it did. Now, you play the role of the naysayer at the prospective client, and then take notes on how the salesperson attempts to address your concerns. Whatever the salesperson fabricates is what you need to build.
7. Innovate upstream. Engage the Engineering and BD teams. Find out what data, algorithms, relationships, technology, etc. you have that your competitors don't. Then identify ways to exploit the hell out of them. Finally run them through a filter of business sensibility, and choose the best opportunities.
8. Interview yourself. Pretend you (or the Marketing head) is on CNN Money 3 years from now being interviewed about how your company made it so big so fast. What would you answer be? What's the story of how you parlayed one accomplishment into another to achieve market dominance? Great, now you have your marketing requirement set. Thanks to Ogi Kavazovic for this one.
9. Trade one solution for another. Ask each person who gives you a requirement what they'd be willing to sacrifice it for. For example, assume an internal customer requests a bug fix for a tool that is used to set a manual configuration. Ask what they'd rather have R&D do than make the bug fix. They may recommend automating the manual process. Now, you can take the conversation from there.
10. Get an outside perspective. Customers tend to be bad at suggesting specific product enhancements. Other Product Managers tend to be good at it. Take strong Product minds from your network out to dinner. Bring an iPad. Describe your challenge to them and see what ideas they come up with. Then run with their ideas: validate recommendations with your customers. You'd be amazed how an outside perspective can make all the difference.

I'm sure there are even better ideas out there for identifying requirements and priorities. What are yours?

What's the difference between a platform and an application?

These days, everyone is talking about the new technology "platform" they're creating. At least half of these are not actual platforms. It's beginning to piss me off. It's not that hard, is it? an application is an application, and a platform is something that applications can be built on or run on.

Uh oh, I just defined "application" using the word "application". Maybe this isn't as easy as I thought. How about this? A platform serves no direct purpose to end users itself. It does provide infrastructure for one or more applications (which do serve a direct purpose to end users).

But, hold on a sec, can't you build a standalone application? Sure. So, why do you need a platform? The answer is, you don't... But it's a whole lot easier when one is already in place. That's what platforms do: they make application development easier.

People usually think of it in terms of the amount of necessary technology already in place. Imagine building a desktop app without an operating system - you'd have to reinvente everything, even the cursor!

But there's more to it than just that: platforms don't just provide valuable functions like cursor movement or clipboard copy and paste. Many modern platforms are all about making useful data available for external application development.

It's important to understand the two and choose your strategy: the word "platform" generates all sorts of buzz, but are you really trying to build a platform, or are you really building an application? Being clear on this with the higher-ups is essential for a product manager because it should influence your vision, your strategy, and even your day-to-day operations.

For example, the definition of the "customer" is radically different between application and platform.

• For an application, the customer is the end user, or the buyer.
• For the platform, it's the software developer whose problem you're solving. So, go talk to them. Understand what developers will pay for, or what will encourage them to build their applications in such a way that they have a technology dependency on you, then figure out how to extract value from it.

Ideally, your strategy will include both: application and platform. The application can draw in data and to work as a proof point for your platform capabilities. (If you can build this application, then consider all the other ones you could build on top of it as well.) Once the application is in place, generalize its back end into a true platform.

Some shining star examples:

• Salesforce.com perfected this strategy of building an awesome app  then enabling other applications to be built using APIs to access configurable domain models and workflows.
• Facebook is a great example of an application and a platform. The application element is the killer app that most of us know and love, post our pictures to, connect with friends. The platform element is the exposure of the social graph to external applications which enable a different set of use cases.

Stay on the lookout for more similar strategies to emerge.

What's the scariest thing for a product manger?

The scariest thing that can happen is to find yourself dead in the water - unable to innovate or unable to develop your product. That means you've already achieved whatever upward potential you had and there's no direction to go but down.

No matter what other issue you may face, it's possible to dig yourself out of it with smart product development. Don't have data? Go acquire it. Have a bug? Go fix it. Missing network effects? Go social. But an inability to develop means you're managing a "dead product walking". It's just a matter of time before you lose.

This can happen for a number of reasons:

• You're drowning in technical debt.
• Your release process is hopelessly broken.
• The development team is burnt out or or frustrated or laid off.
• Neither the company values nor the development process allow for taking risks.

Being a local in Washington, DC, I can't help but draw the analogy to politics. The USA faces many issues, but is still clearly on top of the world economically, militarily, and in at least some ways socially. That's great, but it's merely a matter of time before it falls behind. The government is stalled because of systemic issues that prevent it from moving forward at the same pace as the rest of the world. Partisan politics guiding all decisions, complex tax law with thousands of loopholes, filibusters, etc. all contribute to a government that cannot adapt. There are far more ways of stopping something from happening than there are to make new things happen.

Some incredible new politician could come along tomorrow and be perfect in every way. But if the system remains as is, it would nullfiy his/her natural abilities and prevent any substantial influence whatsoever.

This effect can take place in the corporate world, too, and in fact, it frequently does. Multiple business units all with veto power over any new product enhancement will slow innovation to a crawl. A values system oriented toward preventing mistakes will establish a culture of fear.  Relentless focus on poorly defined performance metrics that can easily be "gamed" will misguide everyone.

If you are a product manager working in an environment like this, the first thing you need to do is fix it. You could come up with 100 brilliant new product ideas, but they're all doomed if the approval process is overly cumbersome or the development is inept or the architecture is fundamentally broken.

That's the scariest scenario for a product manager.

What are the fundamentals of a successful social app?

I would love to gripe about most social apps sucking, but the truth is they don't.  Why is it that there are so many crappy apps out there in general, but most well-known social apps are actually pretty good?  Because social apps are a product of natural selection.  They have to be good to survive.

There are two success measures of social apps:

• Growth.  Social apps need to grow organically.  The critical success metric: organic growth rate.  How many friends will a new registrant encourage to sign up, as well?  If one person signing up is worth another 1+ additional new accounts, then the user base will grow exponentially.  If < 1, then the population will grow slowly and fizzle over time.
• Engagement.  Users need reasons to maintain a high level of engagement.

 

The recipe for growth

• Provide reasons for signing up.  It's not just to create an account, but to do something fun or satisfy curiosity.
• Provide a reason to encourage someone else to sign up.  How does the user's own experience get better with more friends?
• Avoid the spamming effect.  People won't invite their friends if it might be perceived as rude to clutter their inbox with it.  This is hard to get right but critically important.
• Utilize existing affiliations to grow the user base through offline networks.  For example, allowing people to associate their activity with an organization such as a church means they're more likely to invite the rest of their congregation.
• Make it painfully easy for him/her to sign up.  A 20% dropoff rate could be the difference between a weekly organic growth rate of 1.1 and 0.9.  Unacceptable!

One of the best examples of a growth recipes I've seen is cubeduel.com where co-workers can anonymously rate one another.  You can't see your own rank until you've rated enough co-workers.  Unfortunately, they miss on engagement.

 

The recipe for engagement

• Keep it fun! (This one's obvious in theory, but difficult in practice.)
• Allow people to express themselves in creative and varied ways.  Ratings are simple, but open text or photo upload makes everyone's experience more personalized and compelling.
• Give users ways to impress their friends.  Give friends ways to show their approval.  
• Hide information!  When emailing an update, provide enough information to spark curiosity.  Hide enough information so it's left unsatisfied until they click to the web site and ideally perform some action that results in new triggers for their friends.
• Smartly market new features.  Novel functionality gives new reasons for old users to come online.

A great example of an engaging product feature is Facebook's photo tagging.  When you get tagged in a photo, Facebook emails you telling you you're in someone else's picture, but they don't show the picture to you.  What if that's not me?  What if it looks weird?  Oh my god, wait, what if it was that one picture from the bachelor party?  Curiosity.  Unsatisfied.

My New Blog Format... and a Personal Request

So, like it or not, I've decided to go with a new format for my blog.  The previous format has been a series of weekly "rants" about Product Management and User Experience Design.  I hope they're full of valuable insights and interesting ideas.  But I also think they're stale.  The format going forward will hopefull be utilize a more interactive and (hopefully) engaging structure.

Every other week, I'll toss out a new question intended to challenge the status quo.  I'll aim to get a few followers to chime in with their thoughts.  Then, on the alternate weeks, I'll offer my "rant" on the topic.

The spirit of the blog remains the stame.  From day one, the blog's title has been "PM Rant: Straight talk about Product Management.  Plenty of opinions and NO apologies."  And I'm sticking with it.

Just like before, the topics will range from broad to narrow; and, just like before, they'll be aimed at offering some new insight... plus, hopefully create a little (mostly) healthy controversy along the way.  Unlike before, my answers will be shorter and sweeter.

For those following my blog, I have three requests.  Yeah, I know, it's a lot.

1. Please accept my apology in advance.  I'm going to take vacation the next two weeks, so the next blog post won't be until 10/17/2011.  (I've heard a rumor that Vermont is nice in the fall, and could use a little love following hurricane Irene.)
2. Please do me the favor of helping kick this new format off successfully by providing comments based on your answers to whatever questions are posed.  The more collective content, the more stirring of the pot, the more learning, the better.
3. Don't be a wimp.  Don't hesitate to say something you're not 100% sure is right or might not be popular with other readers, or even me.  Who knows?  Maybe there are others out there who strongly agree with you.  Or better yet, ones who disagree and can coherently explain why.  I say, "to hell with conventional wisdom!"

Rant on, my friends.