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

Subscription Pricing vs. Enterprise Pricing

A question was recently posted in a number of Product Management discussion groups. It read (in part):

…I am working on adding a subscription based pricing model for our product. I have read articles that talk about the “rule of 17″ that suggest a monthly payment should be 1/17th of a perpetual license fee.

I have structured the models so that the “crossover” between the License fee model (including maintenance streams) and the subscription model was sometime in the first half of year 2. I have seen 3 year models as well.

What do you use or what have you seen? Have you offered both model for a time and if so what are the conflicts (if any) that arise?

It can sound very tempting to provide a subscription alternative to your own enterprise software, but you need to think beyond simply price, and think through the evaluation model, the sales model, the expense model (you’re now taking on the cost of hosting/operations), and how you go to market, convert leads etc. I’m assuming here that the subscription pricing is for a hosted or SaaS version of you current on premise software?

The approach to take is to start from first principles, and define the value proposition for the end user or customer.

There is a real tendency if you already have an on premise solution to:

1. ensure you don’t cannibalize the revenue coming in from that solution
2. use the pricing of the existing solution to determine the price of the SaaS version

If you go down either path, the subscription solution is likely to fail.

The first one will always put the existing product ahead of the subscription based product. This is what happened with Siebel on Demand. The existing business had to be protected from encroachment or cannibalization by the on demand business and it hampered the on demand business significantly. Your company will really need to shift it’s thinking to manage this well.

The second is tied to the first, but also ignores a really great opportunity you have to define a true value-based and scalable pricing model that could generate more revenue and have significantly higher customer retention than the current pricing model.

Spend some time with the target customers and understand the value proposition from subscription based pricing, and do some price sensitivity testing with them. This should really help you understand how the pricing can provide value. It may also show that there is no appetite for subscription based pricing, but I’m assuming that is not the situation in your case.

One of the interesting things about subscription pricing is that the money will often come out of OpEx budgets in companies whereas for traditional enterprise pricing, it will come from CapEx budgets. Now a dollar is a dollar, usually, but whose budget it comes out of make s a big difference in how people perceive price.

Additionally the pricing model has to take into account the true value delivered by the software. It is very easy to think of per seat per month or per user per month pricing. It certainly worked for SalesForce.com. But the beauty of subscription pricing is that you are not tied into that model or one model for that matter. But whatever you do, keep it simple! Enterprise pricing is ridiculously over complicated. Use the subscription pricing exercise to address that problem.

Figure out what the key units of value are from a customer perspective and use those for the pricing. There may be multiple models based on user scenario. While you don’t want to force existing customers to move to subscription pricing, you’ll have to figure out a transition pricing model to move them over (and possibly back) if needed.

Think of it this way. If one of your competitors came out with a competitive subscription based offering to your current product, would they simply take your pricing and apply the “rule of 17″? No, they’d figure out a compelling value proposition and pricing model and use that as a weapon against you. Get one up on your competition and do it before they do.

Saeed

P.S. Here’s an article on subscription based pricing that may be helpful.

Little features and a lesson for Product Management

Today, while working on a different blog posting (to be posted soon), my browser, Firefox, froze. I use FireFox almost exclusively these days, mostly because it works well, and I really like the tabbed browser-window interface. I do a lot of multi-tasking via the web browser, and the tabbed interface makes it very easy to jump back and forth between contexts as I multi-task. Try that with the other dominant browser.

Yes, I know there is some toolbar or something for IE 6 that will do this and that IE 7 has it built-in, but FireFox has had tabs for a lonnnnng time, so I prefer it. And while the tabbing feature is great, that’s not the only little feature I want to discuss.

Firefox has another new feature, not sure when they added it, that will restore the full prior state of Firefox on the next launch, if it had shutdown unexpectedly.

(click to see the whole dialog)

How awesome is that? Well, let me tell you…earlier this evening I was working on a blog posting, typing right inside the WordPress editor, when, as I often do, I switched to another tab to look for some info. I clicked a link on that other page, and then the browser froze. And I mean froze. After waiting a minute and still not having a responsive browser, I had to kill the process in the Task Manager.

Somewhat annoyed at not having saved my brilliant blog posting, I reminded myself that I needed to regularly save my work.

But, when I relaunched Firefox and clicked the Restore Session button, to my amazement, there was the entire post in the WordPress editor, exactly as I had left it. It was not saved in WordPress, but Firefox had brought it back. Awesome. Saved me a bunch of time and yet another reason to continue using Firefox.

So, what’s the lesson for Product Managers?

Keep the user’s experience front and center!

I’m sure the tabbed interface and the Restore Session features were fairly easy to implement relative to other tasks such as accurate rendering of markup, script execution, addressing security issues, dealing with plug-ins etc. And while those are important things to work on, they are expected “buying features” for users. But the unexpected, particularly the ruthless efficiency of something like Restore Session, is what will clinch the deal with many users.

Yet, these kinds of features are often traded off when negotiating with development.

Do you want the security problems fixed or do you want the restore? We can’t do both.

Granted, an open source product like Firefox doesn’t necessarily have to make those trade offs, but for business software, that is not the case. Get your engineers to understand the value of having the product outperform expectations, and task them to help identify little gems of functionality that can be implemented to make users rave about your products.

Saeed — Raving Firefox fan, starting today.

Forrester on Product Management

I’m quite happy to report that Forrester Research has started a blog covering Product Management:

http://blogs.forrester.com/product_management/

Here’s link to the bio of the analyst writing the blog: http://www.forrester.com/rb/analyst/tom_grant

IMHO, this is a very positive development. Research firms like Forrester, Gartner etc. are typically descriptive vs. prescriptive. i.e. when they start covering a space or a market, it is because it exists and is growing and deserves focus, vs. spending time covering something that has not yet reached a minimum critical mass and may grow in the future.

As an example, I worked for a number of years at Informatica in California. We were a recognized leader in the “ETL” (Extract-Transform-Load) market. But we really saw the market as having moved to what many called “Data Integration“. It wasn’t until several years later that the analyst firms created specific research practices related to Data Integration.

So with Forrester looking at Product Management, this probably means that firms selling products such as Requirements Management tools will be getting more analyst coverage, and perhaps Forrester will host events or conferences related to technology product management. It will be interesting to watch.

So,welcome Forrester, and let’s hope the other research firms see the light.

Saeed

What’s the deal with Personas?

The CrankyPM recently posted a good little rant on personas. It’s drawn some interesting comments from both sides of the persona camp (PCamp? ). BTW, I’m totally jealous as she snagged a great title — Persona non grata — for her post.

I’ve been incubating the following persona related post for a while, and thought now a good time as ever to finish and post it.

There’s been a fair bit of writing related to personas as a tool for better understanding users and their requirements. Adele Revella has The Buyer Persona blog, and Bonnie Rind has her Product Personas blog. And of course, the accredited father of the persona concept for product design is Alan Cooper. Cooper’s firm has a number of persona related articles on their site. Perfecting your Personas by Kim Goodwin provides a good overview for those who are interested in understanding the basics.

She starts:

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.

This makes complete sense and whether one is explicitly familiar with personas or not, it’s what most Product Managers tend to do, some better than others.

Later Kim writes:

There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs.

Thus for a single job — say an administrator — there could be personas representing new administrators who need lots of prompting, and experienced administrators who prefer command lines and know exactly what they need to do. Again, not much to debate here.

Later on Kim writes:

You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours.

Now this is where things get interesting, and this is the issue that Cranky fixates on in her post. And to be honest, it’s really hard to disagree with Cranky. Imagine the look on a bunch of developers faces as you start laying out the persona, describe their environment, their goals, their workflow, and the fact that a sandwich has been sitting on their desk for 3 hours.

Might as well stamp the words — Marketing dweeb — across your forehead and then tell them you’re going to get a soy latte at the brasserie. First of all, I’ve yet to meet a development team that cares about these kinds of details. They don’t want to know that Albert, the community college grad who provides DB2 database administration support likes to watch Ren and Stimpy videos while he waits for nightly database backups to run.

They also don’t want to know that Sachiko, the business analyst, has an MBA from a second-tier Midwestern university, is planning the details of her upcoming marriage, and thus doesn’t have time to conduct proper and formal analyses for the new CRM system that is needed.

These are all completely unnecessary details in the B2B context. For consumer software or products, these details may be very important.

A while back, I worked on a new Administration Console for an enterprise middleware product. The product itself was in widespread use, but there was a real push to make it “enterprise ready”, which meant that things like security and role based permissions were important.

The developers spoke about the target user — “the administrator” — in very vague terms. There was also confusion around the fact that some users of the product could act as both administrators and operators depending on the circumstances.

We needed clarity on this and a way to distinguish who did what, when and why with the product, and who the target would be for the new Administration Console. So, we decided to talk to customers to get some raw data. After a number of customer visits and calls, we determined the following:

• There were four major “administrator” roles within our customer base
  • Network Administrators
  • Infrastructure Administrators
  • Application Administrators
  • Operations Administrator

• These four roles were generally consistent across customers, though responsibilities crossed over between roles in different customers
• Administration teams were structured very differently across organizations
  • Some customers had administration teams with global responsibilities
  • Others had teams with specific geographic focus (e.g. Americas, APAC, EMEA)
  • Others had teams responsible for specific applications

From these and other findings, we came up with specific definitions of the roles. Here’s the definition of the Infrastructure Administrator which we decided was the target user for our Administration Console.

An infrastructure administrator is concerned with a specific set of hardware and software running on that hardware. This set of hardware/software is usually domain specific. I.e. it is assocated with a particular enterprise application, such as Siebel, PeopleSoft, an external web application or some other system.

The infrastructure administrator’s job is to ensure that the particular hardware and services, particularly the services, they are responsible for are operating efficiently and that any general maintenance, such as application data backups, server shutdowns etc. are managed in an efficient way.

In the context of our product, an infrastructure administrator is responsible for starting/stopping repositories, configuring servers, performing repository backups etc. In most cases, but particularly with small to medium installations, the infrastructure administrator also handles inter-repository migration of metadata. i.e. they do the deployment from development to test, and test to production.The infrastructure administrator is the primary user of the Administration Console, though from our discussions it is clear that they do not need to use it everyday.

The developers really understood this description. We had similar ones for the other three types of administrators, and throughout the development of the Administration Console, we regularly referred to these roles, their descriptions and other findings from our research when questions arose as to what should or shouldn’t be part of the console. Notice there is no mention of personalities, habits, level of disorganization on someone’s desk or anything that detracts from the role and it’s focus.

So, what’s deal with Personas? Technically nothing, unless you insist on using them with engineers or other people who just couldn’t give a damn about all that extraneous “marketing fluff”. A big part of Product Management is communication, and speaking in the language of others. If engineers don’t “grok” personas, don’t force them down their throats.

Saeed

Product Manager vs. Product Management (part 6)

In part 5, I showed how you can begin to decompose the areas where teams, particularly Product Management, provide key deliverables to other teams. Here’s what the heat map looked like for Product Management across the stages of the development cycle.

(click to enlarge)

For each colored element in the heat map, a list of deliverables and dependencies for that team at that stage of the cycle must be defined.

One important note here. Even though the chart above lists discrete stages in the development cycle, the stages can and likely will overlap in time. For example, Pre-Beta, Beta and Post-Beta all occur during the Product Development stage. And the Sustaining column is a set of ongoing deliverables that occur throughout all of the other stages and feed into stages such as Product Definition.

So, if one were to take a stab at listing the key deliverables at each stage of the development cycle, it could look something like this.

(click to enlarge)

I say “could look something like”, because it will vary somewhat from company to company, and possibly even from product to product. For example, A hardware product, e.g. an appliance, will have different deliverables at certain stages than a client-based software application. And the client-based software application may have different deliverables from a hosted SaaS application. Having said that, the stages and deliverables listed in the chart are relatively generic and should apply in many circumstances. And finally, some of the items may better fit in other columns depending on the company and the specifics of the situation. e.g. demo creation may take place later in the development cycle, closer to launch, may not even be a Product Management deliverable in certain companies, or may not even be needed at all!

In the context of the Information Supply Chain, when thinking of deliverables, there are upstream dependencies and downstream dependents. Upstream dependencies are any deliverables that must first be completed by yourself or others, in order for you to create your deliverable. For example, a good Product Requirements Document (PRD) might depend on the existence of a Market Requirements Document (PRD). Thus the MRD is an upstream dependency of PRD. Conversely, for every deliverable, the downstream dependents of the deliverable must be identified and documented. e.g. For a PRD, the downstream dependencies can include Functional and Design Specifications created by Engineering and Product Description and Overviews created by Product Marketing.

Now let’s look at the first column and drill down some more.

It has three potential deliverables:

• Statements of Direction
• Market Requirements Document
• Product Roadmap

Each of these needs to be defined and the dependencies (upstream and downstream) need to be identified. Luckily for Product Management, there are very few upstream dependencies in this case. Here’s the text for the Statements of Direction:

Statements of Direction (SODs) These are high level strategic documents, describing a number of characteristics about a new or needed technology or functional area to be added to the product. A typical SOD should be about 2-3 pages in length maximum . i.e. not lengthy.

SODs are typically theme based documents (e.g XML, Web Services, 64-bit Computing etc.) that describe major milestones needed across releases for given themes. A good SOD should include an “elevator pitch” describing the theme, a market or technology overview, including competitive info and market risk if necessary, the case for change and benefits for implementing the change, and a summary roadmap for the theme.

Internal Consumers: Product Management, Product Strategy, Development, Product Marketing External Consumers: Strategic Customers and Partners

Downstream Dependents: A Statement of Direction provides the necessary input for Product Marketing to create a “Point of View” (POV) document. Multiple Statements of Direction, defining objectives for multiple themes provide key input for Product Roadmaps

NOTE: A POV is an external facing document that can be used by Sales to convey product intent on a particular theme to customers/prospects/partners without revealing internally sensitive information

As you can see, this is a clear and succinct definition that describes the intent, general contents and consumers of the document. In this example I’ve added the NOTE to show an explicit downstream dependency of a Statement of Direction.

Here’s the definition of the Market Requirements Document. This should be familiar to most, if not all of you.

Market Requirements Document (MRD) MRDs are quite commonly produced by Product Management and/or Product Marketing. More applicable to new products, MRDs, like SODs, are strategic documents, but typically provide much more detail about the market dynamics and market sizing, the competitive environment, the business case for developing the new product as well as likely go to market strategy options.

In short, the rationale for a new product is thought through and documented. Should the internal or external environment change, the MRD can be reviewed, updated and then reassessed to see if the new product is still justified, or what needs to be changed from a business perspective to continue investment in the new product.

Internal Consumers: Product Management, Product Marketing, Product Strategy and Senior Management. External Consumers: None

Downstream Dependents: Product Requirements Document, Positioning Documents Upstream Dependencies: None

And finally the Product Roadmap:

Product Roadmap Product roadmaps are important tools in many sales situations. Prospects, customers and partners want to know that the vendor has a solid future plan that covers key areas of concern or need.

A roadmap should provide a high level view of key product releases and major functionality over time. Most roadmaps cover 12 to 18 month time frames and at least one major version release into the future. Roadmaps are typically communicated to external parties by Product Managers, Sr. Management and senior members of the sales and sales engineering team. Keep in mind that roadmaps represent a projection of plans into the future, and while one can strive to be honest about those plans, roadmaps do not in any way indicate commitments to deliver any specific functionality in any specific release or by any particular date. This must be conveyed explicitly to those who receive roadmap information

Internal Consumers: Product Management, Senior Management, Sr. Sales and Sales Engineering staff. Others on an as needed basis. External Consumers: Customer, Partners, Prospects

Downstream Dependents: Product Requirements Documents Upstream Dependencies: Statements of Direction

So there you have it. The first column of the Deliverables table is now defined. The task for you is to go and try this on your own for other items in the table. Pick a couple of them and work on the definition, the consumers and the downstream and upstream dependencies. Feel free to to post some of them in comments on contact me if you have some questions.

It’s important to work through this exercise within your own company. Explicitly understanding not only what you need to do, but who you depend on and who depends on you across the stages of the development cycle is a very important exercise. I can almost guarantee that you will find a few surprises and challenges as you work through the process.

Saeed

Related Posts
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)

The End of Infrastructure

Yesterday Amazon announced Amazon SimpleDB, an on-demand database service similar to their EC2 and S3 services. With this final piece of the puzzle, Amazon has put an end to the need to own server infrastructure.

Now, don’t get me wrong, Dell, HP and IBM are hardly about to go out of business. But until now one of the biggest barriers to entry in some types of enterprise software was the capital cost of servers (which was already at a historic low). With this on-demand database service, any web-based product you can think of can be deployed without spending a cent on infrastructure. Regardless of what kind of software you sell, today your competitive differentiation just got a little bit smaller.

Thank you Plaxo: You synchronize my life

For years I have wanted this service. Some promised, but no one delivered. And now along comes Plaxo.

I remember Plaxo a bit in the same way that I remember PointCast. PointCast was really a first generation RSS reader, in that it would go out to various websites and pull down new content, new articles that were published. I don’t recall all the details, and probably never knew them anyway, but I do recall that PointCast went down in a ball of flames, largely because the whole “push” model went down in flames. I was disappointed when the IT director started to block PointCast traffic, and then I realized that it was happening everywhere, and PointCast fell away.

Now of course Plaxo is a much newer service, but in a way, I think the name still carries some “first generation” baggage with it. Plaxo used to be about keeping my address book up to date; it would walk through my contact list and email everyone in there, giving them the option of updating their own information. I liked the idea initially because it pushed the problem out where it belogned … to the owner of the information. You know if your information is up to date, and you can quickly re-enter it for me, thank you.

But soon Plaxo got a bit of a bad reputation. People got sick of receiving the self-updating invitations, and many spam filters started blocking Plaxo traffic. It seemed to many, especially with the upsurge of social networks and free competition from CardScan, that Plaxo would die a slow death, or that it was already dead.

Not so! Plaxo came back a few months ago with a 3.0 beta product that is now central to my life. They have identified out a most difficult problem: synchronization across home and work. So now I have Plaxo running on my MacBook Pro at home, my iMac in my home office, and my Outlook at work. Not only that, but it is connected in wild and wacky ways with my Google GMail account, so now my Google Calendar and Address books are automatically synchronized with my home and work life.

And everything is all good. No longer do I have to wonder whether something I create at home will be sync’d with my work calendar. No longer do I actually have to fire up Outlook or Outlook Web Access to set an appointment from home. I simply enter it anywhere … on my iPhone, on my iMac, on my MacBook Pro, on my Google Calendar, or on my Outlook at work, and it magically appears everywhere else.

It’s missing a few things in my view. For example, its duplicates tool is not good enough to be useful, and I think it needs a sort of audit service. I have 1000 contacts, and I’m sure there have been a few mistakes in sync’ing; I have found some entries that are total nonsense, so I wonder if there may be some bugs. Also, Plaxo does not sync photos from my Mac address book. I know that Outlook doesn’t have photos as an option, but both of my Macs do, and my iPhone does, and I’d like to sync them.

Customer service is also on Plaxo’s radar. I had one inquiry that went well beyond their promised SLA. I emailed their “Customer Advocate” after not getting my response in time, and I got a response pretty quickly.

Notwithstanding these glitches, this is a service that I love. They have overcome their own first generation hurdles and created a new product that solves a big problem for me, and I hope they are successful forever. Amen.

Prioritizing Features does not equal Product Management

I came across this blog post today: How to Outsource Product Management to Customers.

With a title like that, I had to read it. The post starts out well:

Product management is one of the most critical functions for any enterprise software company.

Hard to disagree with that!

But then the author writes:

As a product gets used by more and more customers, requests for new features start to pile up, and the job of a product manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep.

Somehow that doesn’t jive with the first line, particularly if you end up “outsourcing Product Management.” Yes, prioritizing requirements is an important part of a the role of Product Management, but managing customer feature requests is only one small segment of the work Product Management performs.

The post on “outsourcing product management” is about an open source software company, Intalio, and how they fund development of key features in their product.

Their process works something like this:

• Identify which features should be developed by having customers discuss and vote on a public list of candidate features
• Estimate the efforts to develop the top rated features as ranked by the community of customers.
• Solicit bids from customers for the development of the feature
• Close the bidding process and start the actual implementation once enough customers commit to paying for it
• Once a feature is complete, decide how the functionality will be made available to customers

While this process does work for Intalio, it is not really “outsourcing Product Management”, because, and perhaps it needs to be said explicitly:

Wikipedia defines Product Management this way.

Product management is an organizational function within a company dealing with the planning or marketing of a product or products at all stages of the product lifecycle

The emphasis on “at all stages” is mine, but it is key when thinking about the function of Product Management.

Product Management, particularly in technology companies, must be seen as a business optimization function across the product lifecycle, and NOT simply as a technical role in the planning of products.

Let me paraphrase myself from a recent post if I may:

If all a PM does is collect and prioritize requirements, then their job title may as well be “Requirements Boy” or “Requirements Girl”.

That is not the description of a strategic role. Although unfortunately there is no single, widely implemented definition of Product Management, the folks at Pragmatic Marketing have done a great job at succinctly defining areas of focus and roles for the Product Management function. Their famous “grid”

(click to enlarge)

shows a very broad range of activities under three different roles. Now, I don’t necessarily agree with exactly how this grid is laid out, but that is a minor issue. Notice that “feature prioritization” is not even explicitly listed in any of the boxes!

Two of the boxes in the middle column: Market Requirements and Product Roadmap, come closest to the feature prioritization bucket. But also notice that the one box is “Market Requirements” and not “Customer Requirements”.

Customer requirements are a subset of overall Market Requirements, and thus anyone or any company that views the single focus of Product Management as collecting and prioritizing requirements doesn’t understand the need and value of Product Management. It’s like saying that the role of Marketing is to create brochures, or the role of sales is to meet with prospects.

So, I hope I’m not simply preaching to the converted here, but this past week, I’ve come across two separate blog postings (1, 2) about Product Management at Open Source companies, and in both cases, the incumbents at the companies — developers at mySQL and the founder of Intalio — pigeonholed Product Management into the “requirements prioritization” bucket.

Any ideas on how to change this misconception? And soon?

Saeed

Transparency in Product Priorities

Product managers are always looking for better ways to get feedback from customers on which new features are most important. A few companies have embraced the “Web 2.0″ model and are putting their feature candidate lists out there for everyone to see and comment on.

Dell has Dell IdeaStorm where anyone can register and submit their ideas and vote other ideas up or down.

Salesforce has, not surprisingly, creates a SaaS service which they sell to other companies but which they also use themselves. IdeaExchange is viewable by everyone, but only registered Salesforce users can comment or vote on ideas.

Sun has always made their bug (and FR) database for Java publicly available, which was certainly great back in my days as a Java developer.

It’s an interesting idea to implement this for the product I’m currently working on, but is it always appropriate? Just like with roadmaps, it’s not a good idea for small companies to put too much data out in public as it gives too much away to competitors. For companies like Salesforce.com, Sun and Dell, there’s not much here that’s really a secret; it wouldn’t take a competitor very long to figure out the gaps in specific functional areas of Salesforce. But consider your own product - would giving away these details to competitors be a bigger drawback then the greater level of customer engagement you’d get in return?