Tag Archives: product management

When Three Is Not A Crowd

Some disagreements are actually tentative agreements in disguise. What am I talking about? To explain where I am coming from, here is a true story (which is still playing itself out) that got me thinking about the nature of disagreements.

At work I’ve been witness to a very characteristic (even epic) disagreement between the two senior managers about the strategy for our new product line. Actually the core of the agreement is about whether the product line should exist in the first place.

The disagreement has otherwise been very polite and respectful, with the sides presenting their points that of view to each other and to the powers that be. A typical mild-mannered corporate affair. Business as usual.

I’ve mostly stayed on the sidelines but yesterday I came out of left field (to continue with sports metaphors) with a freakishly long email that offered my take, complete with opinion and facts, on the matter at hand.

Here is the rub. One warring party swiftly declared that they agree with me a 100%. The other followed suit shortly thereafter declaring that they agree with me 80%-90%. It was all in good humor and only half-serious, but it got me thinking.

The only way to these percentages to make sense is for my summary to only address the minor points in the argument (around which there is no disagreement), but ignore the main points of the argument (which would be the core points of contention). This degenerate case would look something like this.

venn diagram

But I don’t believe that I’ve written an email that would fit the green circle. I suspect the real explanation is that the difference between the parties are more personal than mathematical, and I wish I knew how to draw a Venn diagram around that.

On a more serious note, I think it often takes a third-party perspective to highlight how close the two positions in an argument really are.  It also helps to have an intermediary. Another person saying exactly the same thing has a totally different affect on those least expecting to hear it from someone besides their opponent. It gets everyone paying attention again.

And that is exactly what happened!

Advertisements

Pipecleaners – Experiments in Risk Management

Pipecleaners are a powerful metaphor and an interesting approach for managing all sorts of risks. I’ve heard it mentioned by my boss a couple of times, but with the boss filter on I hardly knew what he was referring to or where it could ever be applied. Having launched LinkPeelr (in a completely different category of software from what I launch in my day job), I’ve now come to see a more universal applicability of pipecleaners.

Continue reading

The Strategy-Execution Deadlock

I’ve recently observed a specific product management/product engineering dynamic and I got to thinking that it’s quite common.

Observe: The engineers are clamoring for the product management to provide a roadmap or at least a high-level vision for the existing and future products in the next year or three. The product management is unwilling or unable to provide this information, but wants to know what engineering has been doing recently, i.e. some form of a progress report that they can trade in to top managers to get a green light for the ideas and vision that engineering is asking for.

This deadlock can take any form from very amusing to very dysfunctional, and I’ve personally seen this particular information flow break down on several occasions.

So how can this pattern be defeated? What would it take to break the vicious cycle? Read on to find out…

Continue reading

I am guest posted

For a change I felt like commenting on a topic that is more closely related to what I do in my day job (namely manage a software product), so I sat down and wrote an article on applying agile practices to product management. The folks at On Product Management have kindly posted it on their blog. You can read the article here.

Product Management and “The Other White Meat”

Let’s start with a Wikipedia definition:

Typically, “pork” involves funding for government programs whose economic or service benefits are concentrated in a particular area but whose costs are spread among all taxpayers.

This week (for my day job) I attended a recurring gathering of companies meeting to decide what the next low-power wireless standard is going to be like. The subject of this post has nothing in particular to do with professional conferences or low-power wireless standards. You can go through the exercise and replace ‘companies’ with ‘stakeholders’  and ‘low-power wireless standard’ with ‘feature set’. In fact I want you to go through the exercise since it’s unlikely that low power wireless is of any relevance to you.

The highlight of this gathering was an intense debate about the choice of a particular component. Several alternatives were offered and dissected in nauseating detail. In the end the majority seemed to coalesce around one of the choices. In fact when the vote was taken more than 3/4 of all participants voted for it.  That choice was then committed as a mandatory requirement, i.e. any product implementing the spec would have to implement this particular component.

I would expect that to be the end of it. However, what happened next was that one of the companies suggested that the runner up, which only 1/4 of the companies voted for in the first round, should also be entered in the spec as an optional requirement, i.e. a product implementing the spec could implement the other component, while still implementing the mandatory one.

The argument offered in defense of this addition was that the company had a large customer who insisted on the runner up option, and although said company would have preferred for it to be mandatory, they wouldn’t mind implementing both if they have to. Remarkably a lot of attendees found this line of reasoning convincing and proceeded to vote for adding the second choice as an optional requirement. After all, they already got what they wanted.

The fools! What nobody seemed to notice was the by bloating the spec with optional components that nobody by a few companies cared about, everyone was footing the bill.

Product architecture

Why do I think this seemingly harmless addition qualifies as pork?

  • Bigger spec means bigger test plan and more resources required by all vendors during verification and certification of their products. Likewise, interaction of optional and mandatory features often leads to subtle bugs, increased complexity and everything that follows.
  • We are talking about a wireless protocol spec so optional features tend to affect even those products that don’t implement them because everyone has to at least be aware of all the options.  Ironically enough, one of the most important criteria for the original choice was its small code size, so the optional feature actually devalues the mandatory one.
  • By voting for to make the runner up an option, all vendors effectively assumed the responsibility of  explaining to their customers why their product does not implement it all. The majority has done itself a disservice by automatically putting itself on the defensive.

A product manager’s job is rife with this kind of minority-staged shenanigans. The boss wants to turn all yellow buttons into green ones. A vociferous user wants an arcane API hook. Engineers want it in Ruby. The compromises that we succumb to today may seem innocent enough, but that’s only because we thought about them for the whole of 5 seconds or while still intoxicated with our previous wins. And so on our watch and with our own timid approval, the spec, the requirements document, the backlog, whatever it may be at your organization, starts to get weighted down with pork.

As product managers our job is to optimize the resources to build the greatest possible value for the product that eventually hits the market. In light of this, it’s a no-brainer that every piece of pork should be viewed with extreme caution and as a possible threat to our most important function.

Letting down our guard and giving pork a free passage means that we too sign up to foot somebody else’s bill.

A Thought-provoking Tale of Customer Acquisition

I was thinking about what product I’ve used the longest on a daily (or at least weekly basis), and I realized that in my case this is none other than my trusty  Gillette Mach3 razor. That thing is old and I just haven’t had a chance to replace it, but if I ever get around to it, I will probably go for another Gillette.

Gillette freebie?

I found the razor in the mailbox along with paper spam right around my 18th birthday. I’ve been a satisfied user for 11 years now (I am turning 29 on May 5th, for those wondering about my age), and still I have no idea how Gillette found out that I was turning 18.  However they did it, their customer acquisition kung-fu turned out to be incredibly effective.

I also just learned from Wikipedia that Mach3 was introduced in 1998, so this was a brand new product at the time and it must have been at its promotional peak. The most effective promotion in this case was just to give the razor, which purportedly took some $750 million to develop, away.

As far as I am concerned there is no real product differentiation among razor manufacturers, it’s more of a force of habit — once you go with one, chances are you’ll stay with that one forever. So what better way to acquire customers than to send them a free razor when they are most likely to be making a decision that could spell lifetime loyalty to Gillette brand?

Now let me turn the question around and ask you what products you’ve used the longest and how did you end up sticking with them for so long? I would love to hear your stories.