I have no voice, and I must speak.

A funny thing happened to me on the way to the conference. As I mentioned in a previous post, I’m speaking at the Software Marketing Perspectives conference in Santa Clara this week. So, the funny thing, or perhaps the ironic thing, is that I lost my voice this week.

While it was rough earlier in the week, as I recovered from the flu, it got progressively worse, and today, the day before I’m scheduled to speak, my voice is completely gone. I can whisper, and articulate a few words with a really hoarse, raspy voice, but if I try for more than 30 seconds, I’m done.

So, this puts me in an interesting position. How can I give my talk without the ability to speak? I have a plan B, but I won’t tell you what it is right now.

Tomorrow, after the conference, I’ll let you know the plan and how it went down.

BTW, bragging rights go to the first person who can identify the obscure sci-fi reference in the title of this post.

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

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

How others see Product Managers

So, first off I (Ethan) have started a new job. And I have to admit it: I am no longer a Product Manager. I have taken a job as a Technical Account Manager at a certain large search engine company located in Mountain View (California). So I’m going to be on the front lines for a change, working with large partners to get our products implemented. SVPMA members feel free to drop a line so I can look out for you at the next SVPMA meeting.

But to my real point: I was eating lunch with some of my new co-workers today who are a mixture of pre-sales (SEs) and post-sales (TAMs). One person was complaining about some of our Product Managers. To almost-quote: “he wanted all the glory without having to do any of the hard work.” Another person commented that the PMs often went ahead of started selling features to partners that were somewhere between difficult and impossible to implement. It was the exact opposite of the stereotypical sales situation: here were the sales people telling the PM to shut up and stop overselling.

I protested vehemently, of course, but for the most part I had to agree with them. Worrying about ease of implementation or supportability is often low on the PM’s list of priorities. People want to import data from SAP - well let’s build it! And who cares that it will take fifty people to implement it? That’s Services’ problem. My bonus depends on putting out new features.

So, if you want to be a Good Product Manager, build great new features that customers will use and love. But if you want to be a Great Product Manager, build great new features that your coworkers in services and support can actually deal with. In the fast-paced markets most of us work in the strategy of “Ready, Fire, Aim” builds buzz and can get a lot of press, but does it build a sustainable business? Rarely.

Pragmatic’s Steve Johnson: Strategy is over-rated

I caught up today with Steve Johnson, arguably the world’s foremost, and most entertaining, educator on Product Management. The interview started off calmly, but somewhat off-message, with Steve talking about how sometimes, tactical activities are the most strategic. “I’ve been growing in my appreciation of the people in marcom. They’re such an easy target, but let’s face it, with out them, the office would be pretty boring and ugly. It’s time to recognize the beauty that they bring to the tech company,” Steve said, wistfully recalling his first marcom coordinator, though he wouldn’t mention her by name.

Steve’s employer, Pragmatic Marketing is widely known to offer the “industry standard” training courses on product management, and has recently expanded its offerings to include more advanced topics such as roadmapping, conducting effective customer interviews, and choosing fonts and colors for your company’s brochures.

The company publishes a grid that is both its framework and its company logo. Steve offered the grid as an example of where tactics and strategy are indistinguishable from each other.

As the interview progressed, however, Steve seemed to be heating up, often stratying from the script that he delivers week-in and week-out as part of his courses. “Strategy crapagy”, Steve said in an outburst, “darn it, my opinion is not only relevant and interesting, but my opinion rules!”, seeming to contradict his oft-quoted edict.

“Sometimes, a data point does describe a market”, he raged, seeming frustrated with Product Managers who take his advice too far. “You can’t have a line without a single point!”

“Strategy is over-rated, Alan. Sometimes you have to get in there and just do it! Look at Nike, that’s what they do!”

There you go, straight from the horses mouth.- Alan

April First, 2008
(Updated: April Fools!)

Why is innovation hard for large organizations?

I came across an interesting post on this topic, and I have to say, that I really agree with what the author, Kareem wrote. In it he mentions three key reasons for the general failure of large companies to innovate:

1. They must protect their current business
2. Too much bureaucracy or too many stakeholders in the process
3. They don’t provide the proper financial incentives for innovation.

I’m sure most of us who have worked in larger companies have experienced the first two. I’ve also seen a lot written about the first two points related to big company culture, management practices etc. People today cite Apple as a great example of a company that has figured out how to deal with those two points.

I want to spend the rest of this post talking about point 3, which I think is critically important and of which I have not seen as much writing.

In any general cross-section of employees, there will be a small subset who can be deemed as truly entrepreneurial and innovative. A lot of them probably come from the Product Management and Engineering teams! And most of those people are smart enough to understand the value they can bring to a company as well as to themselves if they can deliver a successful product to market.

The problem is, in a typical large company, the ROI proposition for bringing an idea to market is completely skewed in favour of the company. Kareem says it really well in his article:

People are incredibly quick to learn which behavior is rewarded in any system. If you want to innovate, there are two options: remain in a system that pays out an annual salary and a relatively meager bonus for your awesome product. Or, strike out on your own, and build a product that might have a significant pay off, while living off savings or investment.

Now imagine a large technology company that has set aside a large pool of money for acquisitions. That number could be in the hundreds of millions of dollars or even higher. The company wants to make acquisitions that help bolster it’s current market position as well as take it into new (likely adjacent) markets.

There are probably lots of innovative startups out there, working on new products that are potential acquisition targets. Now as the company is out there evaluating the market and potential targets, and then spending big bucks to acquire those companies (likely making the founders of those companies wealthy), what are the innovators inside that company thinking?

They are thinking:

“Hey, how do I get me some of that?”

Now imagine if the company took, say, 5%-10% of that acquisition pool and used it to create a fund that would invest AND if successful reward new innovative products by employees. The structure of how this would be done would have to be worked out carefully so as to ensure transparency in the process of who got funded, and clarity in how success was measured and rewarded, but in theory it is possible.

I can think of at least one model, where an quasi-independent group would review the ideas and decide how to provide an internal equivalent to angel/seed funding to get the project to a stage where it could be evaluated in detail. This model would be no different than what one would face if they took their idea to an Angel or VC for funding.

Regardless of how it is done, there could be significant advantages for the parent company by doing this.

• It sends a very clear message that existing employees can see significant upside if they are major contributors to success in the company
• It significantly reduces the potential for “brain-drain” in the company, by stopping some of the best innovators from leaving to form new companies outside
• It provides a lower cost option for the company to “acquire” new innovative products than going out to market and paying a premium for “hot” acquisitions.

The return for the employees who go this route would be lower than what they might get if they were to strike out on their own, but then again, the risks they would face would also be lower. They could leverage many of the large company’s resources as well as the large customer base of the company. While some hardcore innovators may not like this situation, I’m pretty sure many others would.

Imagine an incubator, funded by the large company (and possibly by other external investors as well) that would provide the environment for these ventures to develop, grow and ideally graduate and become successful. If the venture is one that the large company wants to acquire, they can do so relatively easily given their stake in the company. If they don’t want to acquire the company, the market can decide the value of the company and like any other VC, they can regain their investment (and much more) by some kind of liquidity event.

What do you think of this? Is it possible for large companies to develop incubators for their own employee’s to create innovative products and companies? Or are there other issues and complexities that would make this concept more likely to fail than succeed?

Saeed

Facebook Developer Terms: Is there a lawyer in the house?

If I asked you whether you were concerned about privacy on facebook, what would come into your mind? Many people are thinking about personal information, and how that information will be collected and used. I won’t wade too deeply into personal information privacy, but I would like to examine another aspect of facebook: Intellectual property protection for application developers.

About a year ago, Facebook released F8, which in many ways is a brilliant step forward: an open, easily accesible platform, with access to 75 million users and growing every month. While ad revenue has not met with high expectations (econ, wsj), Facebook has done a good job of the revenue sharing concept, whereby you can essentially keep most if not all of the ad revenue generated by impressions and clicks on a Facebook app that you build and host. If they wanted an ecosystem, they got it. Hats off to them for this.

What’s troubling me though are a few paragraphs in the Developer Terms of Service:

Section 4. Ownership and Licenses
As between you and Facebook: (a) you retain all right, title and interest in and to, and Facebook obtains no rights of any kind (other than the rights and licenses expressly granted in this Agreement) in, Facebook Platform Applications you create and in the Facebook Platform Application Content, and all associated Intellectual Property Rights (subject to Facebook’s underlying rights in Facebook Platform and Facebook Site);

(emphasis is mine)

This all makes sense so far. So if I write an app, I own the app. But then a couple of phrases in the next paragraph are a little harder to interpret:

By accessing Facebook Platform, or submitting any Facebook Platform Application to us to be hosted by us, you are directing us to store copies of that Facebook Platform Application (if applicable) and any and all Facebook Platform Application Content provided through any Facebook Platform Application on our servers. You hereby grant us a worldwide, perpetual, irrevocable, non-exclusive right and license, with the right to sublicense, to: (a) access, reproduce, display, distribute, perform, and store on our servers your Facebook Platform Application and any Facebook Platform Application Content, and to create derivative works of Facebook Platform Application Content, as may be necessary or desirable to make such Facebook Platform Application and Facebook Platform Application Content available to Facebook Users in accordance with the terms of this Agreement and the Facebook Platform Documentation and the Facebook Platform Application Guidelines; and (b) otherwise access, use and analyze any Facebook Platform Application Content for our internal business purposes (e.g., for the purposes of targeting delivery of advertisements or other content to persons who have viewed particular types of Facebook Platform Application Content). You understand and agree that Facebook Platform Application Content that is displayed on the Facebook Site may continue to appear on the Facebook Site, even after you have terminated access to your Facebook Platform Application or terminated this Agreement, as such Facebook Platform Application Content may have been incorporated into user profiles, news feeds or other features, and that such usage may continue indefinitely.

So let’s see… if iLike, an app that allows me to share my favorite music and artists with my friends, collects a whole bunch of data about what music is enjoyed by which friends, who owns the data (Facebook Application Content)? By the first paragraph, the iLike publishers should own the data, but later on, Facebook retains the right to use such content for its purposes, including targeted advertisements or other content.

So, dear reader, what is the real incentive to iLike, or Slide and RockYou, to collect this data, only for it to be used by Facebook? I will be investigating this issue more closely, but I would welcome your input! Am I reading this right? What am I missing? How would you feel about Facebook grabbing your data?

And more to the point, are investors concerned? You know, the ones who put up $50M for a company that writes an application that, um, is a better, um, , no, more fun, or super, yes, a more super wall than the um, plain old regular wall in facebook?

Alan (alan AT eigenpartners DOT com) 

GeneTree … are you serious?

A couple of things up front:

• I’m not a privacy bigot. You can find me on facebook, LinkedIn, Plaxo, multiple blogs, flickr, my own personal website, and my corporate bio page. I post fairly liberally about myself online.
• I probably have the best existing genealogical records for my family. I’ve spend HOURS formally interviewing my oldest living relatives, writing down their thoughts, touring grave yards, going to family farm land that my family lost during the great depression. I’m fairly interested in the topic.

So as I’ve started to think more about social networking, I became interested in the possibility of social networks to make genealogy work in the large. It makes intuitive sense to me that social networking is an ideal way to build a genealogical graph. The information is distributed and hard for one person to collect, but not so hard when each person contributes a node and a few branches.

Then I stumbled on Genetree. This company uses genetic testing to automatically build family trees, or at least to connect distant relatives.

OK, sorry, you lost me there. I have to submit my genetic material to a testing lab, have it encoded and stored in your data center, so that you can broker connections between me and my long-lost relatives in Scotland and Alsace-Lorraine?

Yeah, no. No thanks. Let me know how that goes for you. By the way, congratulations on getting funded. Can I speak with your investors?