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

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.

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

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

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.

Goodbye File menu, hello throbbing Orb

We recently upgraded from Microsoft Office 2003 to Microsoft Office 2007 at work. Clearly Microsoft has put a lot of effort into upgrading the UI in the various components of Office 2007. For those who have not seen Office 2007, this is a snippet from MS Word 2007.

So, gone are the various formatting, editing etc. toolbars that have been a mainstay in the UI for several releases. They have been replaced by “The Ribbon“, which in reality is just one big honkin’ set of toolbars accessed using the Home, Insert, Page Layout etc. menu titles.

Gone too is what has been probably the single most consistent interface element of GUIs, traceable back to the original Macintosh:

Original Macintosh interface

and the Apple Lisa:

Apple Lisa interface

So what was that interface element? It was the File/Edit menu structure. You can see it’s origins in the Lisa interface. Pretty much every general purpose GUI application since the advent of the Macintosh, and certainly from the time that Windows 1.0 came out, had that. That was over 20 years of UI consistency.

Windows 1.0 screenshot

In Office 2007, Microsoft decided to remove it. I have no issue with changing something like the File/Edit menu structure, IF they found a better paradigm or mechanism to replace it with. But the reality is that they’ve simply replaced the File Menu with the “Throbbing Orb”, or should I say the “Microsoft Office Button“.

I refer to it as throbbing, or perhaps pulsating may be a more appropriate adjective, because when I first launched Word 2007, that button was pulsating. I actually ignored it for several minutes, looking for the “File” menu. I wanted to open a document. How difficult should that be? I clicked on all the headers of the Ribbon — Home, Insert, Page Layout etc. — but couldn’t find the thing I needed most — File->Open.

Now I’ve been using software for a very long time. The first Word Processor I ever used was on a Wang 2200 computer. I’ve used WordStar (on CP/M and DOS), Multimate (I’m embarrassed to admit), Wordperfect on DOS (and unfortunately also on Windows — what a horrible product that was), as well as many versions of Word. So, when I sat there dumbfounded unable to find the equivalent of File->Open, I asked one of my coworkers for help. He came over and said, “Click that thing”, pointing at the Office button in the top left of the screen. This is what happens in Word when you click that button:

I immediately thought “What the *&@#?” Why would they do that?

It actually makes no sense to me to design something like this. Why not simply create a File title as part of the Ribbon and put the icons for all these things there? I have to guess there was some internal push by the marketing team to create the Office button for some sort of branding purposes, or perhaps there is some particular IP issue being addressed.

I don’t know, but I really wonder who made such a design decision and why? It’s completely inconsistent with the rest of the interface, confusing for new users, and yet so deliberate in it’s implementation that I’m sure there must have been heavy debates in the Office UI team when deciding to implement it.

There is evidence in the Word (and other Office tools) GUI that the toolbar/no toolbar debate happened within the UI team. After using the Office button, I noticed the little toolbar right at the top of Window with several of the “old” icons such as Save, Undo, Redo etc. Seems like a clear “hack” to appease the more traditionalist camp that insisted on toolbars, or perhaps a clear realization that users needed an easy way to perform basic tasks. I think the folks at Microsoft should remember one of the key axioms of Product Management:

Change is a process, not an event.

Anyone have any insights into the Office 2007 design process at Microsoft ? If so, please share.

Saeed

P.S. Apparently there is enough of a market opportunity for the “old” Office interface, that a 3rd party company has created a product to give that to users.

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)

Product Manager vs. Product Management (part 4)

I received a number of requests for the “20 page document” mentioned in part 3 of this series, that defines the activities in the Product Management Deliverables grid. (see below)

(click to enlarge)

After some thought, I’ve decided not to simply post that document in the blog or email it out to people. It is a document that represents the implementation of the product management function at a particular company where I used to work. Looking through the document, it would take me a couple of hours to clean it up, remove any company specific content and make it presentable to a general audience.

While I could do that, I’ve decided to share parts of the document, and provide all readers with enough detail that should enable you to create a similar document particular to the Product Management function in your company. i.e. teach you to fish vs. give you a fish.

For starters, here’s a portion of the table of contents of the document.

(click to enlarge)

Processes
I begin by discussing the concept of tightly-coupled and loosely-coupled processes.

Tightly-coupled processes are the type one typically associates with product development; ones with numerous dependent tasks, specific schedules, and resource allocations requiring ongoing status meetings to coordinate and execute. Examples of tightly-coupled processes include software development schedules and product launch activities.

Loosely-coupled processes are very different from tightly-coupled ones. In a loosely-coupled process, individual tasks are not as temporally dependent on one another as in tightly-coupled processes. Yes, the linkages and connections are there between tasks, but direct blocking issues are less frequent, and less ongoing coordination is needed than with tightly-coupled processes. But, this does not mean there aren’t dependencies. Think about how Product Management and Product Marketing must work together during a product release. Each have their own activities and deliverables, but there is also a dependency between them. The same is strue for how Product Marketing and Sales must work together.

A loosely-coupled process may consist of multiple teams of people working mostly independently on various tasks or projects. In fact, in many cases, a loosely-coupled process may consist of a number of individual tightly-coupled processes working more or less in parallel towards the same goal.

Most companies are well versed in managing and completing tightly-coupled processes. This is because the individual tasks can be clearly defined, dependencies identified, and significant ambiguity removed. There is also significant transparency into the activities of other teams. This transparency is a necessity when working in tightly coupled groups.

But, when it comes to loosely-coupled processes, companies have a lot of trouble managing them. The reasons for this are many, but in general it is because the interfaces between loosely coupled processes are poorly defined, the groups may have divergent short term goals, or that specific owners with both the responsibility and authority to ensure tasks crossover smoothly are not present. There is also little transparency in the tasks across groups, so the dependencies of tasks across groups is harder to track. In reality only the interface points, i.e. the truly dependent deliverables between the groups need to be identified and tracked.

Within the product development process, Product Management plays a key role in delivering (producing) key information to other teams (to consume) so those loosely coupled processes execute effectively.

Thus, clearly defining each Product Management deliverable , when it needs to be delivered, what it needs to contain, and who will use (consume) that deliverable is the first step in creating an effective product management process.

In my next installment, I’ll continue describing the contents of the document. I’ll introduce the concept of an Information Supply Chain, and how that drives the definition of the Product Management function.

Saeed

P.S. If you want to “read ahead”, watch or listen to this webinar I gave in 2007 about the Information Supply Chain.

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 5)
Product Manager vs. Product Management (part 6)

How different people handle change

As a Product Manager, you are required to deal with all parts of the company, from marketing to development to finance to operations to the executive team; you need to be able to work with all of them. Furthermore, you are often an agent of change in the organization. You need to sift through massive amounts of information, find the relevant bits, assemble them, synthesize, and make an argument for changes. In fact, if you’re not changing something at your company today, just what are you doing?

It’s worthwhile, then, to think a little bit about change and the ways that different people handle change. A lot has been written on this topic and I do not pretend to offer an exhaustive or even a properly distilled treatment on it. But I do have some suggestions. This whole issue came up for me tonight in a totally unrelated context, but one where the issue was just so clearly visible, almost a microcosm of situations I’ve faced dozens of times in work and social environments.

A little story then.

When I lived in the SF bay area, I used to attend an East/West meditation evening at the Mercy Center in Burlingame. Normally I would go for Sushi afterwards, and if you get the chance, you must try Sakae on Park Road in Burlingame just across from the Apple Store. And after a Zen meditation session, one should take in a little sushi. But I digress.

Tonight as I am visiting the bay area on vacation, I attended another meditation session. After the meditation, the teacher, Father Greg Mayers SJ, introduced a new aid to meditation that he will be using at the upcoming Zen Sesshin in November. The aid was called a kyosaku, a finely crafted wooden stick that is used in Zen meditation. One of the attendants walks around, and when the meditating person invites the kyosaku, the attendant smacks the meditator on specific pressure points between the shoulder and the neck on the upper back. Each side gets two smacks. The smacks are not painful. Rather, because of the construction of the kyosaku, the technique used, and the pressure points used, the smacks help to clarify the mind and also help release certain muscles that can become sore and tight during long sitting meditation sesshins.

Why is this relevant? Well, after the teacher had his student demonstrate the technique on him, he began to describe the purpose of it. The reaction from the room of meditators was quite fascinating:

• One woman began by saying that she was very offended by the presence of the stick in the peaceful meditation room. It reminded her of the stick that nuns used to use to punish catholic school kids. She said that she would not attend the retreat if that stick was to be used.
• Another chimed in that she agreed. She said that the symbol of a person hitting another, regardless of whether it was helpful or hurtful, the symbol itself was simply intolerable.
• The teacher welcomed the comments. He reaffirmed though that the kyosaku was going to be used at the Zen Sesshin, not in the regular meditations, but it would be used on that weekend. It was a liberating aid to meditation, and that it would only be offered to those who requested it, and that no harm would come to anyone.
• One person reflected on her experience of receiving the kyosaku unexpectedly during a Sesshin in Toronto. She said that although she was unaware of what she was receiving, it was a tremendously clarifying aid to her meditation, and that she was glad to have received it. She said that there was no pain involved, on the contrary, it relieved some muscle tension.
• Others suggested that perhaps another method should be used, such as gentle touch.
• Later in the discussion, others chimed in.
  • One person said that he had been coming to these sessions for several years and had never heard of the kyosaku. He did not like the idea of changing anything.
  • Another said that he had been on a Zen path for five years, had never heard of the kyosaku, but after the explanation, he was opened to the idea. Initially he might have thought it negative, but was now open to it.

I was quite amazed by all of these reactions, and my own reaction. Initially I was very intrigued by this instrument and I found the idea of such a clarifying aid to be quite exciting. As I saw it demonstrated, I was even more intrigued. I was hoping they would call for volunteers right there!

When the discussion got underway, I found myself quite stirred by it. I felt angry, but was probably just quite upset that such a promising aid was dismissed without understanding. I perceived that fear and people with stuck, fixed ideas, were trying to shut down something that could be quite beneficial. I expressed this to the group. I also suggested that these feelings of fear could be seeds of further meditation, and that perhaps the very fear they were experiencing was itself a teacher for them. They weren’t buying it, but I did hear some positive feedback about that idea after the discussion.

Why have I spent so much time describing this situation? And how is this relevant to you as a product manager? Different people have different attitudes to change. You need to learn how to read peoples’ styles and do your best to adapt to their style. If you can’t adapt, you won’t get very far with those people. If those people hold crucial power or are responsible for crucial activities, you’ll be left with big holes in any plan you hatch.

How can you adapt? I have certainly hit my own pitfalls and have failed to adapt in many situations. In some situations I’ve managed to work with others with very different styles. Here are some things I’ve learned, and I’m interested to hear from you about your own experiences, especially links to articles that would be helpful. We will repost them in our article list.

OK, so here are my ideas:

1. Relationships are important. If you develop relationships with people, they will have a larger context with you, and you will have the ability to approach them even when you are blocked on a particular issue. If you are only dealing with a person with a very different style and you have no relationship, you’re going to have a very hard time getting anywhere. This means that you need to take time to get to know people and really care about them. You can’t fake this, it has to be real. I have worked with people very different than me but have also worked hard to find the things about them that makes them effective and even likable, and try to notice when that comes through. I try to tell them about it and share my positive thoughts about them, with them.
2. Figure out what kind of information people will accept as decision-making criteria. Some people need data, others need personal connection, others need to talk things out. Whatever they need, you need to try to furnish it. If a discussion is what a person needs, spend time with them, preferably over a meal. If they like data, provide the data. A lot of people need to understand how the change will affect them, particularly if their own position will change or be threatened by something you want to implement. Work with them to find a solution, or flag the issue for HR and upper management. Ask HR to work with you on the issue.
3. Focus on defining the problem first, and gaining agreement on the problem to be solved. This is 80% of the battle. If people agree with you on the problem definition, on what is wrong with the current state of affairs, they are much more likely to be open to solving it. They also need to believe that the problem you describe is relevant and significant; it can’t just exist, because there are a lot of problems and we can only fix some of them. They need to know why the problem matters to the company and to them personally.
   Some people need to be involved in problem definition, and you may need to redefine the problem if someone provides information that might change the problem definition. In any case, a robust, believable, complete, and true problem statement needs to be agreed on before any change will be made.
4. Once the problem is defined, try to get people involved in creating their part of the solution. This is tricky because some people aren’t able to generate solutions, and some simply don’t have time or are not interested. These people need to be provided with a menu of options or even a very specific set of directions. Ask the question “how independent, how competent, and how involved is this person?” The more independent, competent, and involved, the more they need to have a hand in the solution design. In fact if you are a generalist product manager, or even someone with limited time (!), you NEED THEM to create the solution. Try to get buy-in from their management for them to help you solve the problem. For this, their management will need to buy in to the problem statement.
5. Get management support. Sell management on the problem and the need for a solution. Share with them the degree to which you need or want help in designing the solution, and gain the commitment of their resources.

For some of this thinking, I am indebted to Interaction Associates, a collaboration consulting and training company in Boston and San Francisco. They have models for creating a “path to action” that describe the problem, vision, constraints, and solution approaches. I recommend checking out their classes on collaboration and facilitation; they’ve really helped me. They have a solution design model that I can’t find on the web and my copy can’t be redistributed. But really, check them out.

Again, I would love to hear from you about your ideas here and relevant articles.
Alan