The software industry, and the high technology industry in general, is so young that sometimes everything about it seems to be brand new. It's a whole new world filled with new products that deal with unfamiliar concepts. For example, Customer Relationship Management (CRM) is already "old hat" when it's a term that was unknown ten ...
The ideal company grows in such a way that it contains a balance of all the various strengths it needs: marketing, sales, technical knowledge, customer service, and management. Each function, such as Marketing, has its inherent strengths and weaknesses. One function's weaknesses are balanced out by strengths from other functions. Well, that's the ideal, anyway. But ...
Something I have seen software companies struggle with again and again is understanding the difference between product development and product launches. In order for a software product to not just work, but succeed, you need not just a product release, but a product launch. The product launch, like Requirements, is one of the very few of ...
This week’s topic is an exciting one: where is the best place to locate Product Management in an organization? Bring it up at your company if you want to spark a lively debate.
It’s a sign of the immaturity of the profession of Software Product Management that there doesn’t seem to be a standard job function where Product Managers report. Companies are all over the map when it comes to which part of the organization is in charge of Product Management.
So often Product Management is not viewed as a vital function at a company, since its purpose and focus is poorly understood. If you read about the management team of a startup, or even a larger software company, you would be shocked if it didn’t include a Finance or CFO function. You’d be pretty surprised if there were no Marketing function. But I’m willing to bet that a large number of experienced venture capitalists and entrepreneurs wouldn’t notice if Product Management weren’t mentioned in the job descriptions of the management team.
And because Product Management for software is as young as it is, you would find very little consensus in the industry about where the Product Management function belongs in the org structure.
Yet if you take a systematic, consistent approach to Product Management, the answer to where the function belongs becomes clear. Read below for a discussion of the various areas where Product Management reports today, with the associated strengths and weaknesses, and where the function belongs in a well run organization.
When it comes to determining where Product Management should be located in an organization, there are a number of issues to consider.
I am a person who worries. That has been the case for as long as I can remember. I’m quite sure I’m not the only one.
Like so much of our psychology that confounds us in modern times, worry had a vital purpose way back when: survival. Every mother who worriedly watches her toddler’s every move is using a trait that was essential when we walked in the forests and a child could get badly hurt at any moment by falling in rough terrain, eating a poisonous plant, or getting attacked by a wild animal.
Worry is the habit that kept us paranoid enough to be ready to run in case we found a bear or wolf or wildcat around the next bend.
Like many other characteristics that helped us out in a very different environment, worry can be pretty counterproductive in these days of plenty of food, general safety and homeowner’s insurance. It is easy to worry needlessly.
These ingrained traits from the past can’t be eliminated, but they can be channeled into useful avenues for today’s world. Since worry is a big part of my personality, I try to put it to productive use at work as a Product Manager.
Read on below for ideas on how to apply worry usefully to prepare your software product to thrive in tough situations that may arise.
When I tell people at parties that I’m a Product Manager at a software company, the response is usually: “Oh, that’s nice … what exactly is a Product Manager?”
That’s only natural, but what’s pretty unusual is that you’re just as likely to get that question from a software company colleague. I suppose this stems from the nature of the product – software, in an industry that is not mature. I don’t think this is the same issue in other, much more mature, industries like household products.
So I find myself explaining what a Product Manager is for, and I try not to launch into an article-length speech. My answer always boils down to something along these lines:
“A Product Manager fills in the gaps between different functions and departments in order to make sure that the product develops and makes progress, with the aim of making the product perform better relative to the competition.”
So what are some of those gaps? Read on for a list of potential gaps you’ll encounter at your company.
In the previous issue, Fits and Starts: Creating Product Management at a Startup, I explained that Product Management is a custom solution every time. While it would be great if you could pick up the established methods and launch cycles that worked so successfully for you at a prior company, and plunk them down ready-made ...
Like so many of the tools used by Product Managers to make the software product successful – the Requirements documents come to mind – the Product Road Map takes many different forms at different companies, and needs to be customized to suit each company. While it may seem that no two of these are alike, in every case the Product Manager struggles to balance the ideal with the real in putting together a road map.
In addition, the Product Road Map deals with information at different levels of detail. And what looks realistic from 30,000 feet may seem a little idealistic once you get down to ground level.
How do you balance the real and the ideal in your product’s road map? Read on for a look at the types of content to include.
We all heard people, during the dot-com era, bypass tried and true business concepts to champion untried - and untrue - concepts such as "The Internet changes everything" and "The company with first mover advantage wins." While there is some truth to these concepts (and I think we will learn where to apply them correctly) ...
Before the testing and bug fixing, before the technical design and product plan, before the business and technical requirements, comes the Product Roadmap. And as we speak, Product Managers are asking themselves the question: "Just what is a Product Roadmap?" It's a good question, one for which I'm not sure there is any single answer to ...