What’s the deal with Software Product Management?

OK…this one has been bubbling inside me for a while, and tonight I decided to lay it out and see what feedback comes in. I’ll put on the flame proof suit now.

In our little world, we (Product Managers) think we are all that. We view ourselves as a critical component of the software development process.

How would developers know what to do if we weren’t around to provide market and product requirements?

How would the “sales droids” make their quotas without the help of Product Managers on those big deals?

Who else could define a coherent product strategy that is both aggressive in the market but achievable with limited resources?

Who else has the ability to be as technical as the engineers, as sales-savvy as the sales team and as hip and aware as the marketing team?

We are so dynamic, we can think strategically when needed, but can switch into tactical mode as the inevitable fires need dousing.

Yup, we’re definitely cut from a special stone.

Perhaps we are what we think we are and have the impact that we think we have in companies.

If that is the case, then let’s look at ourselves honestly and ask:

• Why is it so hard to find a standard or generally agreed upon definition of what Software Product Management is across the industry?

• Why are there really no formalized education programs for Product Management?

• How can a 3 day training course even begin to prepare someone to be a product manager?

• Why are our blogs and books filled with an endless supply of “tips and tricks”, as if that is the route to success?

• Why do people think that a smart sales engineer will automatically make a good product manager?

• Why do so many senior managers think that hiring lots of engineers is more important than hiring a few more product managers?

• Why are so many PM consulting firms selling templates and spreadsheets that are both “comprehensive”, yet “fully-customizable” and that enable you to “increase your professionalism”? Really? Is that what will make us successful?
  

If we take a step back and look at our profession, there are many other questions like this that are left unanswered. I wrote a bit about this topic previously in Product Management Maturity and If we’re so smart.

Think I’m being hard or unreasonable? I don’t think so. I’ve been in Product Management for over 10 years and I’m not looking to jump ship yet. I want to see if we can accelerate the process of maturing this field and helping those who are looking to become product managers avoid the struggles we “veterans” have faced.

What have we done in the last 10 years to make our lot better? And I don’t just mean incrementally better. I mean significantly better.

Software Engineering has really evolved in the last decade. The latest greatest things right now seems to be Agile/Scrum methodologies and mature development management tools. Sales and marketing both have matured as well.

Certainly marketing has taken a big leap forward given the integration of the Web and. in particular, hard analytics into the marketing process. Branding, positioning and other traditional marketing activities are still important, but the potential sophistication of marketing today is an order of magnitude above where it was a decade ago.

Selling still retains a lot of it’s old characteristics. Certainly there is no electronic replacement for a good relationship with a buyer or prospect. But sales automation has improved and there are a lot of mature and time tested sales methodologies to choose from.

And then we come to product management. What have we done in the last 10 years to really improve our profession and define ourselves to those around us? Given that there still isn’t some well understood definition of what we do, I’d say we haven’t done enough.

Instead of getting all hot and heavy about the latest development methodology, let’s develop our own well defined, clearly beneficial and easily understood models for product management. No one else is going to do it for us.

And a few years from now, if I’m still writing this blog, I’d hate to have to look back at this post and say, gee, not much has changed has it.

Saeed

What’s the deal with Product Roadmaps?

As a product manager, I’m sure you’ve had to create a roadmap or two to convey future plans or, at minimum, as a sales tool so the sales people can talk somewhat convincingly about a purely hypothetical future.

Product roadmaps are meant to be a tools that are used to provide a high level view of product direction over a number of release cycles. They are used for both internal and external communication, and should present a reasonable or likely predication of the future of a product.

But in reality, roadmaps are more often aspirational rather than acheivable. What other documents do you produce the regularly require massive disclaimers and Safe Harbour clauses on the very first slide?

Roadmaps too often represent the dreams or hopes of the PM, created without needed analysis of effort and resources. It’s very easy to create a roadmap that lays out a great story, with all the good stuff people want, being delivered 9-18 months out. Seems reasonable doesn’t it. There’s a lot of stuff that can be done in a year and a half, if we start thinking and planning for it now. Correct?

Funny how those plans quickly go awry. The reality is that most product roadmaps seem to have been created over coffee in the company cafeteria. They typically show aggressive development plans and signficant deliverables over a short period of time. All of this sounds great and enables the PM to make impressive presentations to wide audiences.

And therein lies the problem. While the individual has to hold some responsibility, the majority of the problem lies with PowerPoint, the preferred medium for describing roadmaps. Yes, you heard it here:

This medium corrupts the message!

People want to see the roadmap on a single slide. Now how much information can one actually put on a single slide and make it look “great” and “worth the wait”? If each release is about 6 months, then you’re likely to have about 2 years worth of roadmap projections displayed on that one slide. It’s all great, until someone tries to define what Dev has to do to build and deliver to the roadmap. At that point, the roadmap might as well be tissue paper, as it has little substance.

Now, we all know that well analysed development plans for a single release often significantly underestimate the amount of work and time needed to complete. We all know it, because we’ve all experienced it first hand in at least one company where we worked. And if that is the case, then how would it be possible that a 2 year roadmap built on high level bullets with little detailed effort and scoping analysis could actually bear any semblance to reality.

At one company where I worked, the PM team was well aware of this problem, and if a capability was “on the roadmap” (nudge nudge, wink wink), it meant it had an almost 0% chance of being released in the next 24 months.

Sales people want product roadmaps to be set in stone once defined. This helps them make firm commitments to customers who need some pending functionality. On the other hand, sales people also want PMs and Dev to react quickly when a “big deal” is on the table and closing it requires “a few enhancements” to the product.

In the end, the roadmap is simply one of several documents that can be used to communicate future plans to potential customers. For consumer software, this is rarely an issue. But for B2B or Enterprise Software, the best thing to do is define a clear and regular method of communicating the roadmap and any changes in it to key members of the sales and marketing teams, to ensure they can position and communicate the future plans to their audiences as confidently as possible.

Saeed

What’s the deal with BizDev?

I’ve worked in a few companies that had a role called “Business Development”. I have to say, this is probably one of the most poorly defined and managed roles I’ve seen in any of these companies. Usually “Business Development” means “Strategic Alliances”. Now what does that mean?