Month: January 2008

A test when hiring Product Managers?

A quick question here, hope some of you out there can help.

When hiring, many departments have tests for their potential hires. I’ve seen this most notably in technical positions such as software development where candidates are asked to either write, debug or explain some code that is presented to them. Another common test is a writing test that is given to candidates, such as in marketing or technical writing, to see if they can actually put a few coherent paragraphs together.

Testing has it’s merits. Aside from all the individual, face-to-face questions that are asked at an interview, having someone spend 30-60 minutes (typically) writing a test can provide some interesting data.

First of all, can the person answer the questions correctly? Do they have the requisite domain knowledge you are looking for? If the test is a long one — in fact one that is intended to take more time than you allot to the candidate — it becomes quite interesting to see how the candidates manage their time.

I’ve both heard and read about companies like Google and Microsoft who give tests to potential candidates. There’s even a Wikipedia entry related to Microsoft interviews that describes some of the questions someone might be asked.

Having said all this, I’m interested in seeing if there are any specific tests that you give to product managers during the interview process, analogous to the kinds of technical tests that are routinely given to technical candidates such as software developers.

I look forward to hearing from you.


Product Manager vs. Product Management (part 5)

In part 4, I discussed processes, and talked about loosely-coupled and tightly-coupled processes. The reason I wanted to introduce those is because when I talk about understanding the Information Supply Chain and defining key Product Management tasks, it is in the context of supporting loosely and tightly coupled processes.

First, let’s define “Supply Chain”

A coordinated system of organizations, people, activities, information and resources involved in moving a product or service in physical or virtual manner from supplier to customer.

This is roughly what Wikipedia says at the beginning of it’s page on the topic. The page needs work, but I like the definition. Note the terms “coordinated”, “people”, “activities” and of course “information”. A supply chain can be a complex entity, and certainly in the physical world, it involves moving physical goods (raw materials, parts, finished products) from place to place, to those who need it, as they need it (just-in-time delivery).

In the software world, and particularly in the context of the software development process, the focus is on delivering high quality information to those who need it as (or before) they need it. One nice thing about information is that there are no inventory or warehouse costs for storing a document that is delivered early. Along with time, information quality is also important. A good requirements document delivered on time is much better than a poor document delivered early.

If you take a step back and look at the product development process, it is fundamentally about information flow and optimizing that flow. Deliver requirements late or poor requirements on time, and extra work must be done to accommodate for that. If requirements are not clear and precise, it can impact the amount of testing that must be done as the implementation of those unclear requirements may be sub-optimal.

Beyond the actual development process, if the requirements aren’t clear or, if they don’t correctly address market needs, then marketing and sales have to do extra work to achieve their goals. I’m not saying that everything is the result of faulty requirements, but simply illustrating the downstream impact of a single deliverable — the PRD. The same is true for every other information transaction that occurs. If the communication is not clear, or delivered in a “language” or with content unsuitable for the target audience, friction ensues.

We’re all familiar with the famous “tire swing” cartoon, which very succinctly illustrates this point.

treecomicbig.jpg (click to enlarge)

The software development process is complex, risky and full of unknowns. It’s really not like building a house, for example, where structural strengths of the materials are well known, the design is well understood, the land around it is suitable, and it’s very unlikely that every year, the ground it’s built on changes consistency. In general, it’s rare that the assumptions that were made in building the house are no longer valid. This is what happens to houses when that occurs.

(click to enlarge)

When this happens to a house, it’s time to get a new house. When this happens in the software world, people call support and expect someone to fix it! But I digress. 🙂

Given the risks in the product development process, it is important to understand who needs what information, when they need it, and for what purpose. One can then identify what role each team, including product management, plays in this information supply chain, and what outputs are needed. I wrote about this topic a bit in a previous post, but its worth repeating here as it is critical to getting down to the definitions of deliverables that are the ultimate goal of this exercise.

If one were to look at all stages of the product development process, and identify all the parties (internal and external) that were involved at each stage, and map the intensity of their activities during those stages, you’d end up with a diagram that looks something like (but not necessarily like) this.

(click to enlarge)

This is a very simple heat map showing (on a scale from 1 to 3), the level of intensity of involvement of each group (shown on the left hand side) during each stage in the development process, from research, through development and out into launch etc.

Looking at the heat map, it’s clear that most of the intensity — and thus activity — is on the right hand side, i.e. the latter stages of product development, launch and release. The majority of the activity on the left hand side is in the top left, and related to product strategy, product management and product development teams.

So the question is, how do you optimally get from the left hand side to the right hand side? Or put another way, what information must flow between the groups, across the stages to ensure that the activities on the right hand side can be performed optimally?

To answer that for the whole diagram would not only be a huge task, but somewhat off topic. This blog is called On Product Management and not On What Everyone Should be Doing in my Software Company. 🙂

So, let’s look at the Product Management line only. Aside from making the task at hand simpler, this is also a good simplifying assumption for the whole supply chain process. The impact of product management on downstream activities is clear. So, if you can get that right, you’ve addressed a big part of the problem of optimizing downstream activities of other teams.

(click to enlarge)

The Product Management team is heavily involved from the early stages right through until almost the end where the intensity of involvement in a release drops off after the release is out in the market. There is still some activity of course, but in reality, when the product is launched, other teams such as Sales and Support are heavily focused on it, and Product Management focuses on upcoming releases.

The task now is to look at each stage, and list out the deliverables that must be created so that other teams can do their jobs in latter stages. Keep in mind that this is not a list of activities at a given stage, such as talking to customers, analyst meetings, win/loss analyses etc, but a list of deliverables that will be passed on down through to other teams so they can complete their work.

For example, a PRD may be the result of things like customer visits, analyst meetings and win/loss analyses, but the deliverable to the development team is what is important in the Information Supply Chain, because without it, they can’t do their job. How you created it is less important (to them). The assumption is, you are doing what you need to do to deliver the right requirements to them.

So, a bit of homework. 🙂

Think about your company, and what deliverables you need to provide to other teams at each stage of the development process. Also think about what others may need to deliver to you so you can get your job done as well.

In the next post, I’ll drill down even further into the specifics of deliverables at each stage and provide examples to help you define a Product Management Information Supply Chain for your company.


The rest of the series
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 6)

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)

pmdeliverables2.jpg(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.

[NOTE (as of June 25, 2011): Please read the rest of this article, but note that the document IS now available at: ]

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.

ISC TOC(click to enlarge)

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.


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

The rest of the series
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 6)

It Pays To Stay Cool

From Wired, on the iPhone development process:

A product manager slammed the door to her office so hard that the handle bent and locked her in; it took colleagues more than an hour and some well-placed whacks with an aluminum bat to free her.

I guess this means I should be happy that I don’t even have a door.