The point of contention in the debate is whether Product Mangers should be using tools like Balsamiq (of which I am also a big fan) to produce mock-ups. Cranky and Roger have gone back and forth on this and I think they are talking past one another. I’m guessing that they actually share a great deal of common ground on the subject, so am going to do my best Mother Teresa and attempt to demonstrate that common ground here.

Roger’s spot-on that too many companies don’t appreciate the value that an interaction designer can provide, and as stated in his Feb ‘08 blog post that critical role is all too often filled with someone with the best of intentions, but the wrong skill set.

Cranky, too, is correct in her assertion that there’s nothing wrong with a Product Manager picking-up a design tool in order to communicate a product concept with a mock-up - a picture being worth a thousand words and all that.

It seems to me that the critical issue here is the intent of the mock-up. I use mock-ups frequently myself, because I am a visual person and so communicate more easily and effectively with a picture than a wordy document (never know if from this blog would you). I know that I’m not an interaction designer and don’t want anyone mistaking my attempt to communicate a concept as an attempt to specify a design. So, I am very careful to include the following disclaimer on every mock-up I produce: “…the UI is intentionally low-fidelity and serves only as a narrative – this is not a UI design artifact”. I also call my mock-ups storyboards and accompany them with a little textual narrative as this helps to drive-home the point.

The open-ended discussion that mock-ups stimulate are critical in the very early stages of product design. Just as important, however, is the need for professional interaction design; there are few things more important to a successful software product than nailing the user experience and an interaction designer is key to achieving that goal.

I hope I’ve helped to move the conversation forward, because it’s an important one.

I was recently asked to make this case in writing and was pleasantly surprised at the results. I feel like I’ve stated the case for Scrum - or something quite close - with legitimate business reasons. Following is an excerpt from a product charter document on the subject of project management:

This project will be executed under a somewhat unique set of circumstances. Selection of a project management process that supports these circumstances is critical to the success of the project. It is the responsibility of The Team (Executive, Product, and Development) to select a project management process that will be used for the lifetime of the project. Following is a discussion of the circumstances of the project along with indications for the project management process.

This project is not being fulfilled for a single customer. We are building to where we believe the market will be in one year’s time - our perception of where exactly that is will very likely change over the next 12 months. For this reason we must follow a project management process that allows for continuous adaptation of the project deliverables.

The company has a rather small team of highly qualified and experienced software developers who have worked together for many years. Such a team will not be helped by a heavyweight process, but more likely hindered by it; clearly this is not desirable. Therefore a second requirement on the project management process is that it be “lightweight”. In other words the artifacts of the process must be few and straightforward, requiring minimal documentation and creating little process overhead.

Accountability for product strategy lies with the SVP Product & Strategy. In practice, however, the responsibility for defining product strategy is shared across multiple organizational disciplines including Executive, Development, and Sales. An additional requirement on the project management process then, is that it must provide transparency to in-flight development in order to facilitate shared responsibility for product strategy.

Finally, we anticipate a great deal of interest in this project from existing customers, prospects, board members, prospective investors, and press. To maintain credibility, we cannot afford to have discrepancies between reports on project status. We must speak to all external stakeholders with a single accurate voice. A final requirement on the project management process is that it must allow for measurement of progress towards goals and milestones.

I’m curious how the selection of methodology/process is decided at your shop. Does PM prescribe it, do they even have a voice? Also curious what you think of my argument above.

How Big?
Market/opportunity size will typically be the number one concern for a new venture. A new product should make it the same. Find a way to quantify the opportunity and present it in a way that makes sense to someone not familiar with the market.

Why Us?
Carl covered “why me” - I’d like to see some statement that explains why your company is poised to succeed at this new venture.

• Do you have favorable relations with the buyers?
• Do you own technology or other IP that you can leverage to exploit the opportunity?
• Do you have a partnership network that puts you in a unique position?
• Are you able to leverage a unique geographical presence?
• Is your brand readily transferred to the space?

Whatever the reason, spell it out. Why is your company uniquely positioned to succeed in this endeavor?

Who Else?
Who else is likely to attack the opportunity. While the opportunity size defines the size of the pie, the answer to this question helps to define the size of your slice (given the answer to “why us” above). Under most circumstances, a small slice of a small pie is not an interesting proposition regardless of the answers to the other questions.

Why Now?
If you’ve ever been involved with a start-up, you know just how important timing can be. Some might say that it is the most important consideration - though it’s nearly impossible to predict “perfect” timing”. It’s important to explain why this is the right time to solve the problem for your target market. What makes today an important time for the market?

Then What?
Like any good start-up, a new product should have an exit strategy. What’s the long-term vision. Do you integrate with other parts of your portfolio? Does this establish the beginning of a new portfolio? Does the product get spun-off as a new business or acquired by a competitor. This isn’t a “burn the ships at the shore” statement of strategy, but it’s important to have some idea of the potential outcomes as they will drive long-term strategy.

Nice list Carl, thanks for carrying the conversation forward.

Having more than a little cooking experience, quite a bit of product management experience, and much less baking experience; I’d rephrase the title to say that being a product manager is more like being a Sous Chef than being an Executive Chef. If you haven’t worked in the F&B industry before the difference may escape you - follow me here, I think it’s worth the effort.

Executive Chefs provide vision. They start with a general direction, an idea of the dish they want to serve and a knowledge of the ingredients on-hand. They turn themselves over to the creative process, relying heavily on past experience and gut feel, and voila! they turn-out a plate. The success or failure of the effort will depend upon the skill of the chef, the quality of ingredients, and also rely a good bit on fortune. Many a chef has ruined a dish while learning something that later helps him to prepare a real gem of a meal. This is the software equivalent to R&D.

Sous Chefs, on the other hand, are professional managers. Their primary job is to productize a creation dreamed-up by the Executive Chef. While the Executive Chef has only to create the one dish, one time, and take as much time as she requires to finish it; the Sous Chef must crank out that dish a hundred times a night, with limited resources, while maintaining consistent quality. To be successful it’s got to be more science than art at this stage.

Which brings me back to the point of Charlie’s post. When you are cooking with someone else’s money, it’s time to hire a Sous Chef. Someone who can bring transparency, predictability, and repeatability to the process of taking new products to market.

Note that this does not mean, as some of the comments to Charlie’s post have implied, that the creative process ends when a professional Product Manager takes the reins. Nor does it mean that you are now following a waterfall process where the product goes into the oven and you are stuck with what comes out. As Charlie rightly points out, measurement tools are a critical component to the long-term success of the product. Going back to the analogy, the Sous Chef will monitor key performance metrics such as the amount of time it takes to prepare and serve a dish, what the temperature of the dish is when it leaves the kitchen, the number of dishes ordered per restaurant guest, and overall guest satisfaction. By monitoring these important indicators, the chef can course correct if things start to go awry. The same is obviously true for the product manager.

If your product is ready to leave the test kitchen and get out into the real world, take a big step towards repeatable, predictable success and hire an experienced, professional Product Manager.

If you are a product manager, you’ve likely internalized the tenets embodied by Steve Johnson’s quote, “your opinion, while interesting, is irrelevant.” The best product managers say “no” to every new feature request and to keep saying “no” until the case for the feature is made. The case for the feature is made by data. But the product manager’s job is not done when the feature is added to the backlog and prioritized. It’s important to communicate the need to stakeholders inside and outside the organization. Use data; turn it in to a story; indicate the trend and the opportunity. Explain to all stakeholders why you want to do something - not just what you want to do.

Budget. David & Joshua mention this, but I want to call more attention to the subject. As a new PM you will want to travel. Well, you may not want to, but you’ll need to. You need to hit the road with the sales team, listen to existing customers and prospects, attend trade shows, and get a feel for the market. Depending on the product you may want to visit production or service delivery locations. You’ll often have the need to purchase tools. You may need to fill in gaps by outsourcing important functions like win/loss analysis if no one is doing it today. All of these activities are critical to your success and you’re being set-up for failure if you aren’t going to be able to get the necessary budget.

Product Development. This may seem like a silly question to ask, but it’s an important one. Does the company make their own products or do they resell? Your job as PM for a VAR will be about portfolio management, service delivery, and partner relations. Is this your thing? If it’s not, then you’ll want to get with a company that is developing their own products.

Innovation. David & Joshua talk about idea generation, but I’d like to focus on a slightly different aspect - is the company committed to innovation? Lots of companies aren’t and it’s not a requirement for financial success. But it might be a requirement for your happiness. If it’s important to you - ask the question.

People vs. Process. This could be a sub-header under “culture”. Does executive management put its faith in people or process? It’s not a fair question, as the answer is likely both, but where is the emphasis. If you are a Six Sigma-type, you might be fine with an organization that believes in process over people. If you are the highly creative, color-outside-the-lines-type, maybe not so much. Fortunately salary is a pretty good indicator of the value a company places on talent. If they are paying below market they probably don’t feel like they need the cream of the crop to be successful.

I was previously considering the product naming exercise from the point of view of a start-up. A catchy name works for a start-up because start-ups are building a brand around the product. The game changes considerably for larger companies. Imagine a company the size of IBM with 5,000 products in its portfolio, all with cutesy names like Wizzi. Discussing the portfolio with customers would go from comical to ridiculous in a hurry.

Companies with large product portfolios and well established brands will want to leverage the brand and provide descriptive, functional names for new products. Recall that in our example, the product detected marketing-speak in presentations. Let’s add to the example the fact that the product is marketed by a large, well-known software company - ByteCo. Rather than use a catchy name, ByteCo would be better served to name the product “ByteCo Presentation Cleanser”, “ByteCo Gobbledygook Cleanser”, or something of the sort. Doing so would allow the company to leverage their brand and would allow the product to describe itself to potential buyers browsing the existing product portfolio.

A similar approach is to develop a brand around a suite of products (in addition to the company brand). Microsoft has done this well with the Office suite of products. Having the Office brand applied to a product immediately tells consumers much about the product: it’s for desktop use, productivity related, integrated with Outlook, Word, etc. IBM has been similarly successful with the WebSphere name.

Note the examples above also indicate that descriptive names aren’t necessarily verbose. These kinds of semi-descriptive names are another great option for start-ups. NetFlix, for example, is both catchy and descriptive at the same time.

I’m a fan of names that have no semantics attached (Kleenex), very generic meaning (Apple), or very esoteric semantics (Google). I also go for names that are easily remembered and easily pronounced in all major languages.

For different flavors of products I like to take two tacks:

1. generic packages with generic (standard & advanced) or non-sensical (XE, ES) names
2. solution-based names aimed at a particular use case / segment.

So let’s assume we have a cool new product that will scan your powerpoint presentations for the detection of marketing-speak; inspired by David Meerman Scott’s “Gobbledygook Manifesto“. We decide to call it Wizzi. There will be a free version called Wizzi Basic that will only scan 10 slides a day. The full version will be Wizzi Pro. There is a package aimed at medical marketing companies which adds common phrases determined to be bullshit in this industry (the medical marketing add-on), we’ll call it Wizzi Pro - Medical Marketing Version.

Seems so easy in the abstract. Why is it so hard in practice?

I recently started a new job, so I’m a little late picking up this conversation . It’s such an interesting topic that I just have to chime in.

Saeed from On Product Management asked if Product Managers and Product Marketing Managers in technical companies should be a part of a single “Products Organization.” The overwhelming response from his readers was yes. Saeed has pitched this idea in several previous posts, so he’s had me thinking about it for a while. He’s suggested in the past that engineering should report in to Product Management as part of this “Products Organization.” Saeed’s a smart, experienced guy whom I respect greatly, and the questions he’s asking here are poignant. Many tech companies have severely dysfunctional organizational structures and it damages their ability to compete and stay profitable.

In short, Saeed has suggested that:
1) PMMs and PM should both report in to a singular Products Organization
2) Engineering should report in to Product Management as part of a Products Organization

I’ll address each point separately, then try to wrap-up my thoughts.

Regarding Saeed’s first point, PMMs and PMs should absolutely report into the same organization. And this organization is the Marketing organization, under leadership of the CMO. Why? Because Marketing is about the Four P’s. And no P is more important than Product. I know, I know, this is 40 year-old business school erudition; surely it can’t be relevant in a Web 2.0 world? Despite the greatly exaggerated rumors of their death, the Four P’s are alive and well today in “Big-M” Marketing.

As a refresher, the original Four P’s of Marketing as put forth by Dr. E. Jerome McCarthy, Ph.D. are:
1)Product - the thing that solves the market problem - your company’s offering
2)Pricing - quantifying the value of the offering
3)Placement - how the offering gets to the customer
4)Promotion - marketing communications

Clearly the world has changed since Dr. McCarthy first wrote about these ideas, and the P’s need a little make-over. For instance, placement needs to include positioning in the consumer’s mind as much as on the shelf; promotion needs to include all aspects of Groundswell Marketing and the need to tell a story; but at the end of the day, this is what marketing is about & it’s what successful marketers do (including David Meerman Scott who recently wrote an excellent post on the death of the P’s). Back to the point…. if you are going to create a functional org structure, you’d be well served to place the market-facing members of your product group in marketing.

To address Saeed’s second proposition, that Engineering should report in to Product Management as part of this Products Organization, I say absolutely not. While the market facing members of your product group should be in the marketing organization, the technology facing members of this group should be in an engineering organization. The most important reason for this structure is that the skill sets required to be good at building a product are very different than the skill sets required to be good at Marketing; and nowhere is this more true than in a tech company. Technologists needs to be focused on technology - they must have command of a wide range of tools and they need to keep up with an ever changing technical landscape. Marketers need to be focused on the market and they need to stay abreast of all of the tools of their trade. It’s rare for anyone to have exceptional skills in both engineering and marketing. If you want an exceptional marketing organization and an exceptional engineering organization, you will almost certainly need to have them led by different individuals.

Another reason for this structure is that there should be healthy conflict between marketers and engineers. I’m not convinced that this can happen if both teams are part of the same functional group.

All this said, the Product Management function is critical to the success of a tech company. The org structure should be crafted in a way that allows product managers to run their products like a business within the business. In a large organization it certainly makes sense to have a VP or Director level position running a “products team,” of which Product Management is a part. I don’t think folks that are responsible for MarCom activities should be part of that team though, again because of the vastly different skill sets required. So, while the PM and the PMM should ultimately report into the CMO, as part of the “Big-M” Marketing organization, they should not have the same direct supervisor. The PMMs should be part of the “little-m” marketing/marcom organization.
All of this discussion is around direct reporting structure. While “belonging to” the Marketing organization, Product Managers should lead a cross-functional team as part of a matrix structure. This team should include empowered members from MarCom, Sales, Account Management, Customer Support, Billing, Fulfillment, and Development at a minimum. Depending upon your product and organization, more folks may be needed.

Let me end with a couple of caveats. Caveat 1: I’m talking about larger companies here (200+ people). In business, as in physics, the governing laws of the very small scale and those of the very large scale don’t always agree. Caveat 2: “it depends” was my knee-jerk reaction to Saeed’s questions. Organizational structure is a function of the people in the organization, not the other way around. The org chart should be created to allow the folks that work in the organization to succeed. It should be created with full knowledge of the strengths and weaknesses of your people, as well as an understanding of the intricacies of your finances and operations. So, it’s impossible to provide a stock organizational structure. However, I’m didn’t feel that I was going to further this important discussion with this answer, so I’ve assumed here that your company is not constrained in any way and you’ve decided that the organization will be best served by a traditional functional org structure.

Before the many tactical activities of Product Management can begin, Product Managers must identify the people in the market for who the company’s product will create value. They must identify and articulate the specific problems the company’s products will solve for these customers. They must validate the many assumptions made in the business plan about the market size, application of technology, cost of production, and the profit potential of the product. From here, the more tactical activities discussed in Derick’s post flow naturally. If the Product Manager is not involved in the strategic activities I mention above they are performing project management - not product management.

In many organizations, this role may be titled “Director of Product Management” or possibly “Director of Product Strategy” rather than “Product Manager,” but regardless of the title, this is the complete scope of Product Management in my opinion. I believe that more companies are embracing this complete view of Product Management because it creates clear accountability for the success or failure of the product. Product Management is ultimately the “one throat to choke” and Executive Management tends to like such an arrangement.