We’re running a business, not a technology company

One thing I always try to remind myself of, is that in the end, my job is to make the business successful. Product Management is a business optimization function. In short: get the most valuable products to market with a limited set of development resources to generate enough revenue to meet or exceed the business goals.

Now, given we work in technology, there is a lot of pressure to “innovate”, to create new technological differentiation against competitors, to develop the next “big thing”, or produce a new or novel offering that can be positioned uniquely in the market.

And, while there is nothing wrong with any of that, it is important to remember that although those things may be important, they are not paramount. The most important thing to do is address market needs more effectively than anyone else. This could mean doing the more mundane things like playing well in their existing environment, or providing platform support, or creating command line tools, or making sure the products are easy to use.

None of those things may seem all that exciting or novel, but they are important to customers who must use these products to meet their business objectives. There is no point creating a unique product showcasing great technology that few people want to buy.

Keep in mind that technology changes much faster than many people’s abilities to accept that change, and one of the best things you can do for customers is to actually help them mitigate that change where possible.

Case in point. Back in the early days of Java, I was product manager for a line of Java components. Java was growing and changing quickly and Sun was deprecating APIs regularly. One of the things we did was to provide consistent APIs to our customers so that as they moved from Java (1) to Java 2, they didn’t need worry about those changes from Sun. In short, we provided them a layer of insulation from the underlying technology changes. This was hugely valuable to customers and helped our business as well as our reputation as a company that delivered real value to them.

In the end, optimizing for the business success, and NOT simply technological leadership, should be the goal of every product manager.

Saeed

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

Agile/Scrum Software Development and Product Management

I think ours is the only Product Management blog in the entire blogosphere that has not yet had at least one post on Agile/Scrum software development. That is….until now.

I’m not so sure it was a conscious decision on any of our parts. There is so much other good and relevant stuff to write about, like iPhones and iPods for example.

But seriously, I don’t think we have written about Agile because, and I’ll speak for the 3 of us, it’s not that critical to product management. There I said it!

NOTE: where I use “Agile”, it implies a combination of Agile/Scrum

If you are not familiar with Agile or Scrum software development, you can read more in many locations on the web. A good starting point is, as expected, Wikipedia. Read up on both Agile and Scrum methodologies. While quite distinct in many ways, it’s important to understand both Agile and Scrum and how they are inter-related in practice. In fact, the first line of the Wikipedia entry on Scrum reads:

Scrum is an iterative incremental process of software development commonly used with Agile software development.

While not an absolute definition, and clearly some may argue, I view Agile as more of a culture or approach to software development, whereas Scrum is more truly a methodology, with specific roles, practices etc. that can be implemented. In many cases, when people say Agile, they imply Scrum as well.

As mentioned earlier, Scrum defines a set of roles. One of the key roles in Scrum is the Product Owner. That role is defined as:

The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.

Now, this would most likely map to the Product Manager in most software companies. While true at a high level, another key element of Scrum is the daily scrum meeting where every member of the team, including the Product Owner attends.

Now, imagine if you as a Product Manager had to attend a development meeting every day. When would you get out of the office? When would you meet with customers, partners, prospects etc.?

One big mistake a lot of people make is assuming that the Product Owner has to be the Product Manager. While conceptually that may be true, the Product Manager cannot, and in my opinion, should not attend these daily scrum meetings. I’ve worked in PM role in two previous companies that used Agile/Scrum development methodologies, and I think I attended one Scrum meeting. We still had regular communication with the development teams and regular product reviews etc. but we weren’t embedded into the development process the way some people might think we should be.

Other roles such as Product Designer need to be defined to take that day to day decision making role and act as the Product Owner, or at minimum, be the proxy for the Product Owner (if that is the PM) so that the PM doesn’t get bogged down by daily scrum meetings.

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 marshalling the product from development through marketing, sales etc.

Here’s an analogy. Sales teams invariably follow some kind of sales methodology. It could be strategic selling, solution selling, or conceptual selling. It could be some other model, or even none at all. If the sales team decides to adopt or change their sales methodology, do other related teams like Marketing or Product Management have to change how they work?

The answer is NO. So, then why should those changes happen to Product Management if the development team adopts Agile/Scrum? Our job remains the same. Understand the market, customers, competitors, merge that in with business objectives etc. define what needs to be built and move that through all the stages of development/launch/post launch to enable product success.

If in a few years, some better development methodology comes along, and is adopted by the engineering teams, will that change what Product Management does?

NO.

Development methodologies should be a grey box for Product Management. We should have an understanding of them, but we don’t need to become an “embedded” part of their implementation. It’s all about loose coupling and clear lines of communication. We have our objectives, and Development has theirs, and when we need to interface, we do so in an efficient and mutually convenient manner.

Let me put it this way, and pardon the analogy if it is a bit inappropriate. Product Management and Development don’t need to be married to each other to be efficient. The relationship needs to be more like a “friends with benefits” arrangement. i.e. the two hook up on a regular or as needed basis.

Saeed

I’m speaking at Software Marketing Perspectives

Just wanted to do a bit of self-promotion and let you know, I’ve been chosen as one of the keynote speakers at the Software Marketing Perspectives conference, next month in Santa Clara.

My topic — on Friday May 9th — is called:

Information Supply Chain: Aligning Diverse Teams to Minimize Time-to-Revenue for High-Tech Products

I actually spoke on this topic last year at the SMP conference in Boston, but had a terrible time slot. Last session on the last day. On the bright side, I know that the people who came to my talk really wanted to be at the talk!

I guess they liked the topic and asked that I present it again as a keynote. I’ve blogged about this topic a bit in this series of articles, but the topic really deserves a lot more focus and detail and in fact, over the past year, as I’ve thought more about it, I’ve realized that this is something that could help solve a big problem I’ve observed in growing companies.

When companies are small — from startup to about 50 people — information flows very well. People can stay synchronized with each other simply because they work closely together and there are tight working relationships between groups. Also teams are very small, so the personal relationships of individuals help strengthen the communication flow all around.

But, as companies grow, say from 50 to 150 people (and beyond), problems start creeping in. Everyone no longer knows everyone else. Team sizes start to grow. The personal relationships across teams get weaker. Hierarchy and bureaucracy starts setting in. Roles and duties get redefined and gaps start appearing in the information flow.

What worked with 50 people doesn’t work with 150 people. The company is growing but processes cannot be put in place to keep communication flowing properly. If you’ve worked in such a growing company, I’m sure you’ve heard someone say something like this:

How come we seemed to get so much more done in less time when we were smaller?

If an Information Supply Chain is defined for those critical cross-team junction points, a lot of the communication problems can be eliminated. Everyone doesn’t have to know everyone else to be successful, they just need to who depends on them and what information is needed when.

That structure, of mapping and addressing dependencies can scale, regardless of who is on each team or even where they are located. I’ll leave it there for now, and I’ll report back once I return from the conference.

Hope to see some of you there.

Saeed

Survey says….

Last week I asked the question, How much revenue for each PM in your company? with a link to a survey. The survey was intended as a “quick and dirty” sampling of data to get some numbers related to revenue ratios for Product Managers. Truly a more analytic survey would be in order to get more broad-based industry wide data. Perhaps our friends at Pragmatic Marketing or Forrester can take this task on.

The survey asked the following questions:

1. What kind of company do you work for?

• Public
• Private

2. How many product managers are there in your company (or division of the company in which you work)?

3. What is the annual revenue (in millions of $) of your company (or division of the company in which you work)?

4. Which of the following best describes the type of technology your company (or division in which you work) primarily provides?

• Software
• Software as a Service (or hosted applications)
• Hardware (e.g. servers, routers etc.)
• Software and Hardware (e.g. hardware appliances)
• Other

5. Which of the following best describes the main target customers for your company’s products or for the product of the division in which you work?

• Consumers
• Businesses
• Government
• Other

6. If you answered Other in question 5, please specify the type of business.

7. Do you have any questions or comments about this survey?

And here are the results. Thanks to all those of you who responded. Note that I’ve rounded all revenue numbers to the nearest million.

Total Number of Respondents: 67

Break out by Company Type

• Number of Public Companies 26
• Number of Private Companies 41

Number of Companies by Technology Focus

• Software: 29
• Hardware: 3
• Software and Hardware: 17
• SaaS/Hosted: 15
• Other: 3

Number of Companies by Customer Focus

• Business:50
• Consumer: 12
• Government: 4
• Other: 1

Annual Revenue Range for Public Companies:

• Smallest: $10 Million
• Largest:$1.5 Billion
• Average: $341 Million

Annual Revenue Range for Private Companies:

• Smallest: $0-1 Million
• Largest: $1 Billion
• Average: $58 Million

Average Annual Revenue (in $millions) by Company Type

Average Revenue	Private	Public	All
Hardware	30	250	177
Software	28	310	135
SW and HW	79	283	187
Saas/Hosted	19	600	174
Other	338	–	3

All

58

341

168

NOTE: The “All” column/row is the overall average for that column/row. e.g. 177 represents the average revenue for ALL hardware companies.

There is significant breadth in the data here. If we exclude the “Other” row, the Public companies have revenues roughly 10 times that of the Private companies.

Average number of Product Managers by Company Type:

Ave. # of PMs	Private	Public	All
Hardware	1.0	3.8	2.8
Software	3.4	13.1	7.1
SW and HW	5.4	9.1	7.4
SaaS/Hosted	3.5	11.0	5.5
Other	4.7	–	4.7
All	3.8	10.7	6.5

Even though the Public companies had roughly 10x the revenues of the private companies, the number of product managers in Public companies is only about 3x that of Private companies. While I don’t have data to support this conclusion, my own experience having worked in both public and private software companies is that these numbers are not far from reality.

Average Annual Revenue (in $millions) per PM by Company Type: (Calc 1)

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0	66.7	62.4
Software	8.3	23.7	19.1
SW and HW	14.7	31.1	25.5
SaaS/Hosted	5.4	54.5	31.8
Other	72.4	–	72.4
All	15.2	31.9	25.8

NOTE: Averages were calculated as overall average. i.e. sum of all revenue per category divided by sum of product managers for those companies.

Average Annual Revenue (in $millions) per PM by Company Type: (Calc 2)

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0	55.0	46.7
Software	9.5	22.9	14.6
SW and HW	9.7	44.2	28.0
SaaS/Hosted	5.1	75.3	23.8
Other	32.1	–	32.1
All	10.5	40.8	22.2

NOTE: Averages were calculated as average of ratios. i.e. each company’s revenue/PM ratio was calculated and an average was taken of all companies falling into each bucket above.

Comparing Calc1 and Calc2

As you can see that while there are some similarities in the numbers between Calc1 and Calc2, there are also some significant differences. For example, while the corresponding Software numbers are close to each other across the tables, the Private-Other numbers are very different (72.4 vs. 32.1). This is because Calc1 will skew the data if there are large outliers in the data. e.g. The Private-Other only has 3 data points and they vary widely in revenue, thus skewing the Rev/PM.

Calc2, takes an average of ratios, so that widely ranging revenue (or PM) numbers aren’t going to skew the data as much. I’ve combined those two tables into the following table that gives a range for each bucket.

Ave. Rev. Per PM	Private	Public	All
Hardware	30.0 - 30.0	55.0 - 66.7	46.7 - 62.4
Software	8.3 - 9.5	22.9 - 23.7	14.6 - 19.1
SW and HW	9.7 - 14.7	31.1 - 44.2	25.5 - 28.0
SaaS/Hosted	5.1 - 5.4	54.5 - 75.3	23.8 - 31.8
Other	32.1 - 72.4	–	32.1 – 72.4
All	10.5 - 15.2	31.9 - 40.8	22.2 – 25.8

So, how do these numbers compare to the situation in your company? Drop us a line…

Disclaimer: Take the data for what it’s worth. I’m not a statistician. The data set is small (67 completed surveys) and when subdivided by Public/Private and Software/Hardware/SaaS/SW+HW etc. the numbers of data points in each bucket can be quite small and thus the error bars around any calculations can be significant. Don’t blame me if you use this data and bad things happen to you. But if good comes from using the data, drop me a line and send some of that good karma my way. If you do use this data in any presentations or other publications, please reference the blog. Remember, even on the Web, plagarism still means stealing someone else’s ideas and presenting them as your own.

Saeed

RACI

Paul over at Product Beautiful had a great post about RACI- a way to breakdown deliverables by the people who are:

• Responsible
• Accountable
• Consulted
• Informed

for each deliverable. It’s very similar to Saeed’s concept of the Information Supply Chain except that it just focuses on the people and not when or how the activities take place. But as a simple planning tool it’s a great, clear approach.

How much revenue for each PM in your company?

Someone asked me a question recently and I couldn’t find an answer on the Web, so I decided to ask all of you for help.

After reading my article, “You can never have too many Product Managers“, the person asked me whether I knew of any published numbers that provide guidelines for the number of product managers a company should have relative to it’s revenue.

The answer is, unfortunately: it depends.

It depends of the stage in the lifecycle of the product, the market, the kind of customers etc.

To get data, I need your help. In return for 30 seconds of your time — that’s all it will take I promise — I’ll collect the data and share it back with all of you in a future post.

Survey is closed. Click here for the results.

Thanks.

Saeed

Product Management versus Marketing and Development

Some good comments on product management from former colleague Cadman Chui over at Red Canary. From some followup comments by Cadman:

I believe Product Management should reside neither in Marketing, or Development. If a product manager falls under marketing, they end up being biased into doing a lot of communications style work. If a product manager falls under development, many times they end up project managing release schedules at too much of a tactical level.

I think most readers of this blog would agree.

New Software, now with blue dots!

You know, sometimes I wonder why I’m not working in consumer products. Not consumer software, but consumer products.

I’ve joked about this with my software product management friends before. Life would be a lot easier it seems. Forget about all the detailed technical work, and all the efforts to keep pace or leap frog the competition, and all the tedium of ensuring compatibility with 3rd party products. Just make the packaging bigger, or smaller, or add a nice lemony scent, or blue dots or something else, and launch a big new campaign to get customers!

One recent consumer campaign, at least here in Canada, has just got me laughing. Ah, if life in the technology industry was only that easy. Take a look and tell me what you think? And if you have any ideas about how to achieve something similar (and meaningful) in the tech industry, please share.

While clearly these two videos are tongue in cheek, the campaign is quite real. Here’s a link to the home page.

Clearly this is a publicity campaign, and the fact that I’m actually writing about it shows it has some impact, but does it make me or want to go and buy Shreddies? Nope, I think I’ll stick with Muffets.

Saeed

Product Managers need time to breathe…

I’m going to make an assertion here, and please correct me if I’m wrong.

I believe that the vast majority of software product managers are running full tilt in their jobs, caught between the short term tactical cross-functional activities (working with Dev, Sales, Marketing etc) that are thrust upon us, and the important long term market research, business and product planning activities that are fundamental to managing successful products.

Do you agree? Disagree?

Companies want Product Managers to innovate, take bold steps, define new products, enter new markets, yet at the same time deal with all the day to day operational issues that arise and need to be dealt with. I’m surprised more product managers don’t burn out after a few years. Or perhaps they do, and like the trees in the forest, we’re not there to witness them fall.

There’s an interesting post on Innovation at IdeaChampions.com. Entitled, INNOVATION is an INSIDE JOB, the article makes several good points, but the key one is:

Organizations do not innovate. People innovate. Inspired people. Fascinated people. Creative people. Committed people. That’s where innovation begins. On the inside. The organization’s role — just like the individual manager’s role — is to get out of the way.

I couldn’t agree more. A lot of companies want to be innovative, but unintentionally put barriers in front of those best suited for the job by never really getting out of the way. It’s difficult to be inspired, fascinated and creative, if you are constantly required to focus on the short term needs of other teams. How can one extricate themselves so they can get out and learn and think and postulate and research and conclude and innovate?

One solution which I wholeheartedly support is to create Product Management teams who are responsible for delivering the goods. The teams can be structured in different ways. You could combine business focussed PMs with technically focussed PMs or you could split the PM responsibilities across functional areas of larger products. There are likely other ways to split up the responsibilities.

But the goal is to get to a level where the teams can work in a pipeline or leapfrog manner. i.e. while one team (team A) is focussed on bringing a release X to market, another team (team B) is out researching release X+1. Once release X is GA, team A can focus on researching release X+2, and team B is working to get release X+1 developed and out the door.

Now, before you start thinking — hold on a minute, how many product managers are we talking about here? — ask yourself a couple of questions:

• What impact does Product Management have on your company?
• Could it have a higher impact on optimizing Development, Marketing and Sales with a small increase in headcount?
• How well could your company execute if you had deep market knowledge, clear understanding of user AND buyer needs, through competitive information and requirements that were complete, accurate and timely?

If you answered, “Significant”, “Yes” and “Much better than we are now” to those questions respectively, then think about defining product management teams in your company. Give them the time and tools they need to do a first-rate job, and then hold them responsible for it.

Challenge the teams to leapfrog each other in functionality, performance, scalability etc. The teams should view each other in a competitive manner. Why? Because your competitors are looking at you this way. They are trying to leapfrog you. They are looking at your weaknesses and trying to exploit them. They are going to try to out market and out sell you. Why not look at yourself the way your competitors look at you and beat them at their own game?

This may sound a bit unconventional but it works. Intel did this for several generations of their microprocessor chips. They had parallel teams working on successive generations of chips. Each new generation of CPUs (e.g. 286, 386 etc.) was to eclipse the previous generation. Not only did Intel make significant performance gains from one generation to the next, they kept upstart competitors like AMD playing a constant game of catch up.

Both AMD and Intel are successful companies, but which would you rather be? Why not take a lesson from an industry giant like Intel and apply it to your company?

Saeed