Month: February 2009

Just a quick note. I’m speaking on a panel this evening at the Toronto Product Managers Association (TPMA). The topic is Career Smarts for Product Managers. The meeting is in the usual location at Metro Hall in downtown Toronto. It starts at 6:15.

On the panel with me are David McJannet of Microsoft Canada and Lois Ellsworth of Compuware.

Without question, being successful at Product Management can be viewed as a balancing act. This is true for any business function, but given the number of cross-team dependencies for Product Management, it’s incredibly important for Product Managers to be aware of this. Over time, balancing the needs of sales, marketing, development, support etc. are all critical to success.

A plan is only as good as those who see it through

It’s actually very easy to make plans. All it takes is a set of objectives and some optimism. But as everyone knows, creating a plan and executing a plan are very different things. Every company has limit on it’s ability to execute a plan. The size, background, existing workload, dedication, difficulty of the task and many other factors play parts in the company’s ability to execute. When defining plans, make sure your goals are feasible and within the limits of the teams that will have to carry out those plans.

Say “No”, for only then does “Yes” have meaning

Saying “Yes” to a customer or Executive request is easy. It’s the expected answer, but it’s meaningless if it is the only answer you give. Product Managers cannot be bobbleheads, nodding yes to every request. Saying “No” to a customer or executive is also easy, IF you can clearly articulate why it is the right answer. Saying No the first time is the most difficult, but it is also very empowering. After all, part of what everyone expects of Product Managers is their judgment in making good decisions.

Earned over time credibility is, but in a moment lost it can be

Building strong cross-team relationships is critical for success….take time and effort to understand what other teams need from you, and what you need from them. Information and power will flow in both directions easily if you gain credibility with others. Without that credibility, and the associated trust that comes with it, your path to success will be difficult regardless of how much effort you put into the job.

Inspire greatness in others, all great leaders do

There is a lot of talk about Product Management and leadership. But what does it mean to be a leader of product or of a cross-functional team? Leaders are only leaders as long as they have followers. But the best leaders gain followers by setting an example for them and, in fact, helping the followers achieve their goals. To be a great leader, show your team members you can help them be successful, in whatever definition of “success” is meaningful to them.

Ignore you instincts at your own peril you do

Logic and reason are incredibly valuable tools, that unfortunately can be in short supply in many companies. But, logic works best when you know all the facts for any given situation. Remove some key facts and where will logic lead you? While we don’t understand how it works, instinct is a critical tool for decision-making, for leadership and for success. Don’t ignore your instincts if you are troubled about a decision. In the end, after all the data is crunched and the insight gleaned, decisions are made in our brain before we even consciously know that we’ve decided something. Sounds a bit like instinct don’t you think?

First off, great title. No burying the lede here. You can read the post on Adam’s site, here’s the key point he makes:

My belief has always been, product management doesn’t change that much regardless of whether you are in tech (B2B or B2C), consumer products (like soap or fabric softener), cars, electronics, etc… Essentially it all boils down to the exact same things: you have a market, and they have a problem. You are charged with crafting the most ideal way to solve that problem, and then making that vision a reality.

Regardless of HOW those charged with executing that vision (or building the requirements) choose to do that, your paradigm doesn’t change. Developers can be working in waterfall, or they can be working in agile. You, as a product manager, shouldn’t care.

This is really interesting, as I wrote the following in one of my first posts on Agile:

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

But, in the end, it is still a development methodology. It should have minimal impact on Product Management’s job as a cross-functional leader marshaling the product from development through marketing, sales etc.

Now the remarkable thing about Adam’s post was the sheer number of comments generated; almost as many as a Failblog post! There was also a lot of passion evident in many of the comments. I even got into the act with a few choice comments myself! (here and here).

I know both Adam and the team at Enthiosys personally. I like and respect them all, but I’m going to have to take sides here, as this issue of Agile (or agile) and Product Management is something that I’ve blogged on quite extensively.

First off, the title of the Enthiosys post comes across like an ad hominem attack on Adam. Maybe it wasn’t meant that way but it sure sounded like it to me.

The author of the post states:

I’d reframe his question (“Are agile PMs Baloney?”) into something meatier: “Do radically different ways of building software radically change how software product managers do their job, and how does this change our thinking about delivering value to the market?”

So, that’s actually a very different and rather pointed question, not simply reframing the original question.

I also think that the reframed question implicitly pigeonholes the focus of product management into something far less than it actually is.

Let’s start with an analogy

The Enthiosys post continues with the following example:

Suppose I was an industrial designer working in the early 1950’s. My job? Creating new tools for machine shops. My tools? Pencil and paper. Clay and wood prototypes. My development process? Relatively slow. Feedback loops? Long. To compensate, I work as much experimentation into my process as I could, but, let’s face it: there was only so much experimentation that I could try.

Fast forward to today. I’m still an industrial designer making tools for machine shops. Except now I’m not using pencil and paper, I’m using a sophisticated CAD-CAM system. I might be using wood and clay, but chances are good that I’m printing my prototypes. My development process? Fast. Feedback loops? Short. My ability to experiment with alternatives, and to use experiments with customers, is so easy that I find myself naturally collaborating throughout my process.

Now, ask yourself: Has the job of the industrial designer changed?

My response…Darayush’s words

First an answer to the question. I’ll quote from one of the comments on the Enthiosys post left by Darayush Mistry:

The job of an industrial engineer hasn’t changed. The tools have. An industrial engineer with good fundamental skills would be just as effective in the 1950’s as today. A good cook will be just as effective regardless of the tools, cause cooking is all about understand the fundamentals of how ingredients mix/blend/cook at various temperatures rather than the hi-tech gas range and ovens.

I fully agree with Darayush on this point.

My response…my words

Second, the analogy of the industrial designer is not a good one. The difference between Agile development and previous development methods and their relationship to Product Management is not the same as the difference between pen/paper/wood/clay and CAD/CAM systems and the relationship to an industrial engineer.

Why? The industrial engineer is NOT analogous to a product manager. The engineer will build a prototype or tool based on requirements or specifications provided to him/her. Someone had to decide and define what new tools were needed, what purpose they’d serve etc. If it was the industrial engineer, he/she would have done this BEFORE creating anything in pen/paper/wood/clay or using CAD/CAM.

Once the engineer has those requirements or specifications, they can certainly create prototypes and designs faster with CAD/CAM tools, but at that point, they’re functioning in a role more like a product designer or a developer.

Third, and I think this is really important, the product management relationship with product development is only one aspect of the role. Product Managers must be focused on the business success of their product, not simply the “manufacturing” of it.

Finally, I think it’s very important that Product Managers in the high-tech community understand that they have a critical business role to play in the success of their companies. There are a lot of obstacles in the paths of these Product Managers. The profession is still young and not well understood. There are few if any good preparatory programs to equip Product Managers with the tools and skill sets they need to be successful. Power politics in companies weigh heavily on the success of Product Managers. With these and other obstacles in the way, the last thing Product Managers should be doing is attaching potentially confusing or misleading terms such as “agile” or “Agile” to themselves.

What happens a few years from now when the focus on “Agile/agile” diminishes in the Development community? What happens when the next new and innovative and hyper-efficient software development model comes out? Will a new adjective need to be attached to the title “Product Manager”?

And finally…really!

Product Management needs to be defined on it’s own terms. We as a community need to take that responsibility on ourselves. Tying our profession to what is fundamentally a software development methodology, no matter how potentially applicable it’s core principles may be to other domains, is not the right thing to do. It will not bring clarity of the purpose and full value of Product Management to others.

I argue (quite successfully I must say :-)) in this post, that Product Management has always been agile and that it is Development that is finally understanding the value of being nimble, adaptable to change, not tied into rigid methodologies etc. The Agile Manifesto was a call for change in the Software Development community, not the Product Management community. Let’s keep that clearly in mind.

While far from scientific, I was quite surprised to see how skewed the results were in favour of this union between the two teams.

Given the readership of this blog, mostly Product Managers, with a mix of marketing, product marketing, engineering and others, I thought the numbers would be far more balanced in terms of joining together.

From the comments on the post, it’s clear that there is a gulf between these two groups in terms of information and communication. Here’s a sampling of some of the comments:

Derrick Workman:
“Both product marketing and product management have responsibility for the overall product success or Profit/Loss….I think in many organizations rolling these two groups into one makes sense, as long as we distinguish product marketing from marketing communications.”

Byron Workman:
I recently visited with one company similar to the one Saeed mentions in the 10:01pm comment. It was a big problem that the Product Management team was way too development centric and the Product Marketing team was way off in never-never land. … The gulf of information was huge, and it was extremely difficult to get a new release that was market focused, because each group had its own idea of what the release should do, and each one even had a different idea of what the release did.

Darayush Mitry:
For me having Product Managers doing both inbound (traditional PM) and outbound (PMM like) activities with a shared PMM (pure play) resource all reporting into the same VP .. aligned and executing on the same strategy works best.

Tabita:
I defintely think they should be in the same department. The overlap in knowledge and skillset is great and in a smaller company, the ability to leverage a core group of people for all product-related activities provides the greatest amount of flexibility.

Vish:
Having product management and product marketing report into organizational head who has responsibility for P&L for a particular product line makes a lot of sense (Whether it is VP of products or CPO).

While several people did clarify their positions and specify how they saw benefit in these two groups being part of one organization, one person left comments that argued for keeping them separate. I’ve reproduced his entire comment below.

David Daniels:
Saeed, we have to start with what we expect from the PM and PMM roles. We know that titles are a mess and don’t always represent the roles. While PMs should be the messengers of the market, they often are sucked into Development hell, rarely to be seen again. I’ve seen this happen with “products” groups that start out with the best of intentions but magically get taken over by the VP of Development at some point, returning to hell again. Product marketing managers should be the experts on buyers, the buying process and buying criteria first and then the product second. For that reason I prefer PMMs be part of the Marketing organization (big “M” of marketing not the little “m” of marketing as in coffee mugs and t-shirts).

I’ll leave the topic with the following points:

There is no absolute here WRT organization, but there are problems that need to be addressed in software and technology companies. Keep in mind that the software industry is still very young. If this were the auto industry, I’d say we are somewhere in the 1930s or 1940s. i.e. lots of innovation, lots of focus on technology (how many horsepower and CCs is that engine?) and lots of opportunity for improvement. The equivalent of the Toyota Production System has not been created for software, so there’s a lot of potential improvement in how these companies can structure, organize and execute.

Thinking about information flow and it’s value within a company, and the clear overlap of skills and knowledge that exists in Product Management and Product Marketing (not Marcom!). Aligning these two groups intimately, so they share a common foundation of knowledge, and then take that throughout the organization and beyond will only benefit companies.

If that is not done, then the gulfs between these two groups will remain and not only reduce their individual effectiveness, but put an unnecessary burden on a company in executing optimally.

Given the focus of her blog, the article describes some simple ways to analyse website traffic and conversion for a hypothetical ‘sock-matching service‘. Yes, that sock-matching service!

Cindy takes a straight forward approach at audience breakdown and provides some good advice and links to useful online tools to help address the problem.

While many product managers aren’t charged with specific focus on usability, when thinking about user loss and conversion ratios on the Web, there is a clear business case that can be made on the impacts (positive and negative) of good or bad usability respectively.