The fallacy of endorsing command and control leadership

I came across this recent HBR blog post “Why Command-and-Control Leadership Is Here to Stay“.  A professor in organizational behavior is advocating command and control leadership backed by no real data.  Her entire assertion is resting on a billboard ad copy at an airport.  Is this how MBA factories are training managers?

Let us set aside that merits of that blog post for a second and inspect this – How often have you as a product manager had direct reports you could autocratically impose and get work done?  How did that go?  How long did they work for you?


The argument that an organization in crisis needs an autocratic leader is a perverse idea propagated by the weak, insecure and incompetent.  Would you suspend the fundamental rights of the citizens of a free nation just because of a ‘situation’?  The glorification of the autocratic leader as some messiah saving the firm from ruin and turning around its fortunes is not backed by a single example.  People cite Steve Jobs at Apple as an example.  That is a complex case.  First, your average executive is no Steve Jobs.  Second, even if your executive is some kind of Steve Jobs, it is highly unlikely he is going to be blessed with or is going to  surround himself with talent like Jobs did.  So let’s leave the obvious exception aside.


Turning to real examples backed by data, in his well researched work Jim Collins cites humility as the recurring Level 5 Leadership attribute in the 11 Good to Great firms that were able to turn around or transform their businesses.  If there is one thing we are learning in the information age about organizational behavior in free labor markets it is this – people organize themselves out of their own free will,  around a cause, a common purpose or objective, and produce goods and services that best serve their collective interests while maximizing on their individual capacities.


If Jim Collins work is about great leadership, modern software organizations are demonstrating new ideas in great organizational design and behavior.  Marc Andreessen famously observed  Why software is eating the world.  There’s a larger truth in that.  Software firms are also teaching organizational  design and behavior to firms entrenched in industrial economics based structure.  Firms like Github and 37 signals are setting the tone for how a collaborative flat meritocracy can be a self governing, profitable firm.  Last week I attended a Lean Software Austin Meet Up for the topic – Self-Determination in Software Development Organizations.  The discussion in the meeting was instructive.  The organizations being discussed were successful because they empowered their rank and file employees to make important decisions that “management” would be normally expected to make.  In fact it was part of their founding ethos to empower all employees.  I’ve been reading Dave Gray’s new book The Connected Company.  He talks about how the best performing firms are hierarchy busting, employee empowering firms and based on a firm design he calls “the podular organization“.


The good news is all of this is nothing new for product managers.  Product managers are already used to working in cross functional organizations with no authority but advocacy.  So skip autocracy and hero worship.  Rally around a purpose and chances are good that a great product will be built.  If you want to build a successful business or transform you business now, hire people with T shaped skills, hire collaborators and definitely hire for culture.  Insecure executives hiding under autocratic decision making are not the choice for leading your organizations.

– Prabhakar Gopalan (@PGopalan)

photo credit: user MHJ

Mind the Product Conference – London – This Friday

If there’s one place I’d love to be this Friday (aside from home with my family!), it would be in London attending the Mind the Product Conference.

Click the link above or that banner to the right.

While I’ve attended a number of ProductCamps (BTW ProductCamp NY is this Saturday)  there are very few larger conferences that focus on Product Development and Innovation.

The speakers in London look great, and it looks like there will be a great turnout.

I’ll follow the conference on Twitter — hopefully attendees tweet extensively (hint hint). And perhaps next year, I’ll be able to attend.

If you are going to be in London on Friday and do attend, send us an update via our Contact page.



Product Demos are like First Dates – Here’s Why

How often do you see a product demo and think, “OK, this is 20 minutes of my life that I’ll never get back.

The fact is, most product demos, particularly those for “technology products” are severely lacking. People, usually a sales consultant, spend far too much time explaining all the wonderful features of their product in excruciating detail with little regard to customer needs– “show up and throw up” is the phrase that comes to mind.

In most cases, you can’t blame the person giving the demo. They’re just doing the job with the tools and training they’ve been provided. So where should we point the finger?

I’ll be honest; the finger should point back at Product Management and Product Marketing, who in all likelihood, have not provided the proper foundation to the people who are giving demos. And so, without the needed information, what else can the sales consultant do, but talk about what they know — i.e. the product.

What’s the point of demos anyway?

Let’s analyze this a little. Product demos are given very early in the sales cycle, when the prospect doesn’t know much about the product and the vendor knows little about the customer’s true intent and needs. They each know a little about each other but there are still a lot of unanswered questions and trust needs to be built before things will go much further.

What does this sound like to you? To me, it sounds like a first date!!

Seriously, think about it.

Obviously one side (the vendor) is looking for a commitment much more aggressively than the other (the buyer).

You’ve got two parties, each with their own objectives, meeting for an initial “get to know you” session before deciding if there is value in moving forward to the next step. . . . . . . a second date!

So, with that in mind, here’s what Product Managers and Marketers should be thinking about when they equip their Sales teams to demo their product.

Understand what the other side is interested in – If there’s anything that will kill a demo (or a date), it’s talking at the other person, vs. talking to them. And the only way you can talk to them is to know what they are interested in, or what their goals are. This is probably the single biggest problem with most demos. The demonstrators have NO IDEA why the prospect needs the product.  Equip your sales teams with clear problem statements your product addresses OR enable them to identify them with the customer.

Listen more than you talk – This is tough, especially when you’re the one who’s supposed to be doing the talking. Arm your sales consultants with key questions to ask as they engage with the prospect. It should NOT be a “demo script” that they blindly follow. This requires consultants who can manage a good conversation and ask insightful questions at the right time. A few well thought through questions can make a huge difference and allow prospects to open up.

Deliver with Confidence – I’ve seen demos where the person giving the demo is nervous or seems to be hesitant about their product. They may know where all the warts and blemishes are in the product, but there’s no reason to let the prospect know (or suspect) that that product is anything but amazing. Ensure that anyone who is giving a demo is confident in what they are talking about. Humming and hawing or sentences spoken in a monotone or robotic manner scream “No Confidence” to the audience.

Watch out for red flags -Sometimes things don’t go as planned. People start looking distracted, pick up their Blackberry, check their email, or simply shut down. You can see their impatience. Learn to read these signals and if you see them, don’t be afraid to stop and ask questions to see what the problems are. What’s worse than a boring demo? A demonstrator that doesn’t realize he’s giving a boring demo!

Don’t reveal too much – Keep the ultimate objective in mind. And it’s not to wow them with the awesome technology you have at your fingertips! It’s to show them you understand their needs and your product will address those needs and make their jobs better. You want them to leave the demo wanting more. Yes, they should leave the meeting excited about your product, seeing value in it, and WANTING to know more about it.

Ask for that follow up meeting – Don’t forget the goal of the demo: to get that follow up meeting. So make sure you ask for it and get their input on what they want. and let them help plan the second date!


Tweet this: Product Demos are like First Dates – Here’s Why #prodmgmt #sales


Roadmap Planning – Bottom Up View

By Rivi Aspler

A product roadmap can be easily compared to an ambitious architectural plan. Very much like a new type of building, the product roadmap should draw a vision that is as useful as innovative. And very much like an architectural plan, achieving the plan is much more challenging than setting the goal.

Challenges are countless… many people are involved, working towards this (hopefully on target and well-defined) goal. Budget is always an issue. Timeline is always an issue and if I had to make a bet, I would put my money on having something go wrong, sometime, somewhere and with someone….


For this post, my assumption is that you already have a structured roadmap plan and you now have to get your hands dirty and start maintaining this intended product strategy.

Bottom up monitoring of the Sprint-Over-Sprint actual investment in each product (that is if you are working with Agile) is one of the must-do actions in order to achieve your ambitious multi-product roadmap plan.


The table below is an example showing the actual investment in each product, compared to the planned investment.

The yellow cells highlight problematic sprints, in which the actual investment is significantly lower than the planned investment, possibly jeopardizing the intended product strategy.

Reasons could be various and are often prosaic. People get sick, take a vacation, quit (or get fired). Alternatively, you may have started the year with a plan to recruit 4 people and you are unable to find them. Another scenario could be that you have found these newcomers but they are not productive yet (2-3 sprints to train a new employee). Many reasons could explain a lower productivity level and that roadmap plan that has to be realized.

No matter the reason, don’t be surprised when R&D supplies less content if it has less coders than required or a lower quality product if it has less QA people sprint-over-sprint.

Want your actual product strategy to be as close as possible to your intended product strategy?! Move people around. This is what Agile is all about. Flexibility. Make sure that your more important products get more R&D power sprint-over-sprint.

Should you wish to use the excel that is explained in both roadmap planning posts, attached please find it (Roadmap_Plan).


Tweet this: Roadmap Planning – Bottom-Up View #prodmgmt #agile #roadmap

Weekend inspiration – a great artist can come from anywhere

I just watched the movie Ratatouille on TV.  Yes, I know.  I am 5 years behind the release date.

It ended with a  reading from one of the characters in the movie – Anton Ego, a food critic.  I am posting the text of it from a blog post that I found Googling:

In many ways, the work of a critic is easy. We risk very little yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face is that, in the grand scheme of things, the average piece of junk is more meaningful than our criticism designating it so. But there are times when a critic truly risks something, and that is in the discovery and defense of the new. Last night, I experienced something new, an extraordinary meal from a singularly unexpected source. To say that both the meal and its maker have challenged my preconceptions is a gross understatement. They have rocked me to my core. In the past, I have made no secret of my disdain for Chef Gusteau’s famous motto: Anyone can cook. But I realize that only now do I truly understand what he meant. Not everyone can become a great artist, but a great artist can come from anywhere. It is difficult to imagine more humble origins than those of the genius now cooking at Gusteau’s, who is, in this critic’s opinion, nothing less than the finest chef in France. I will be returning to Gusteau’s soon, hungry for more.

The writing is simple and profound.  Anyone can cook…a great artist can come from anywhere.

– Prabhakar Gopalan (follow tweets @PGopalan)