Tag Archives: Product manager

Why Product Managers are worth their weight in gold

Why Product Managers are worth their weight in gold

Part 1: Product Managers Gold Series – Setting Strategic Direction

This is Part 1 of a series of articles we will publish on the role of the Product Manager within the new product development process.

A Product Manager plays one of the most valuable roles within your organization: managing the ongoing profitability and viability of their product/category. This very broad and critical charge requires attention to specific responsibilities requiring specific skills and talents. This article will focus on the responsibilities as they relate to new product development.

The driving force of a product/category is its strategic direction and framework.  For your company’s innovation/new product development efforts this includes the set of Product, Platform, Market and Technology strategies, as well as Product and Technology Roadmaps.   These elements focus resources on activities that translate into innovative, differentiated and profitable products. A Product Manager that defines and executes appropriate strategies that yield a sustainably profitable product/category is truly worth their weight in gold.

Before your Product Manager gets started

In order for your Product Managers to develop the appropriate strategic framework, they first need clearly stated and communicated business and innovation strategies defined by senior management.

The business strategy defines the long-term direction, or mission, of the organization, how the organization will achieve that mission, and what measurements will allow the organization to identify progress against or achievement of that mission.

The innovation strategy defines in what ways and to what extent the organization will use innovation to execute its business strategy. This boils down to defining what resources and the extent of resources to be allocated to innovation, and the types of innovations or levels of risk the organization will undertake in the pursuit of innovation.

Why is strategy so important? We’ve worked in organizations that have clearly stated strategies and those that don’t.   The difference between the two is like night and day.  If I had to choose two words to describe the company with strategies, and those without it would be ‘clarity’ vs. ‘chaos’.

The organizations with strategies provided clarity to the team and organization.  The strategies provided direction on where the organization was going, and how it was going to get there.  Everyone had their marching orders, they knew what to do and their efforts were aligned.  It was not uncommon to see the Product Managers continually referring to these strategy documents because they provided a framework and an understanding of the resources and constraints they have to work with.

In contrast, in organizations without clearly stated business and innovation strategies we’ve seen a lot of valuable time wasted by product managers forced to develop their product/category strategies in a vacuum, trying to  infer the direction of the organization or worse, setting direction without regard to the mission of the larger organization.  This situation creates chaos for the entire organization as the various functions try to cope with different agendas, different resource requirements and different priorities.

It takes effort and time on the part of senior management to develop business and innovation strategies, but the payoff is tremendous.   Ensure that your Product Managers are well-equipped with the strategic direction of your organization.  They will then be able to develop appropriate and aligned strategies for their products/categories.

The Product Manager’s role in defining new product development strategy

The following content provides an overview of the five key strategy documents that Product Managers should consider when developing their product/category strategy framework for guiding new product development.

Product Strategies

Product strategies help guide your organization in the development and evolution of categories, product lines and products.  The product strategy includes the goals for new product development within each category ( e.g. market share, revenue, new markets), the arenas of strategic focus (the markets, technologies, product types to be focused on), spending/resource allocation for each arena and a  timeline showing the planned new product introductions.

Platform Strategies

Platforms enable your organization to create new products faster and more efficiently by bundling together elements that can be common across multiple product lines.  A platform strategy guides your organization in the development of platforms and derivative products.  The important elements of the platform strategy are defining the capabilities and limitations of the platform, as well as creating the platform’s point of differentiation.  The platform strategy is also an integral part of developing product and technology roadmaps.

Market Strategies

Market strategies guide your firm in the development of markets and distribution channels.  The market strategy defines who the target customer is, what segments will be served, what is the value proposition or point of differentiation when compared to the competition, and what distribution channels are needed to reach the customer.

Technology Strategies

Technology strategies guide your organization in the acquisition, development and application of technology to gain a competitive advantage.   The elements of the technology strategy include identification of the source of technology, as well as the timing of implementation to support the product strategy timeline.

Product and Technology Roadmaps

Product and Technology Roadmaps provide the graphical representation of the current and planned evolution of products and platforms that match market need to specific technologies.   They basically illustrate the portfolio of projects that the organization needs to work on in order to achieve its business strategy and be successful.  It especially helps the organization with forecasting required technology and the skills that need to be acquired.

Communicating the New Product Development Strategy

To be effective, these strategies must be agreed to and supported by senior management, and clearly communicated to everyone involved in new product development. Progress against these strategies needs to be openly and continually monitored, with adjustments made to react to changing market, industry and technology conditions. We recommend monthly new product development portfolio review meetings and quarterly strategy meetings with the Product Managers presenting their findings to the senior management team.

Product Managers have the ability to make a real difference for your bottom-line.   You will quickly realize that they’re worth their weight in gold by 1) Ensuring your product managers have access to business and innovation strategies created by senior management, 2) Ensuring your product managers have the time to create and update their product strategies on an on-going basis, 3) Communicating the new product development strategies to senior management and the project teams, and regularly monitoring progress.

Leave a comment

Posted by on December 28, 2011 in Product Management, Product Marketing


Tags: , , , , ,

Product Opportunities Assessment

Opportunities for new products exist all around us, in every market, even mature markets. This is because what is possible is always changing. New technologies are constantly emerging, new people with new talents join your company, and competitors come and go. The product manager must be able to quickly evaluate opportunities to decide which are promising and which are not, and for the ones that look appealing, which ones should be pursued, which are best left for others, and which ideas are not yet ready for productization.

In many companies, it just comes down from above that we really need to do this product. In other companies, the marketing organization determines what products are needed.

In either case, too often the process of deciding whether or not to build a product is left to intuition (or worse, a large customer will offer to fund a “special” and this becomes the basis for a product effort).

Typically someone on the business side or in marketing will create some form of a Market Requirements Document (MRD) that is intended to describe the problem to be solved, and usually includes a business justification as well. The purpose of the MRD is to describe the opportunity, not the solution. At least that’s the theory. In practice, many companies don’t really do MRD’s, or if they do, they’re essentially product specs that are called MRD’s. When true MRD’s are done, they suffer many of the same problems as PRD’s – they take too long to write, they aren’t read, and they often don’t answer the key questions they need to.

The result is that many product managers ignore the MRD. But the problem with not doing anything and just jumping right into the product is that it is generally a good idea to look before you leap. The challenge is to do this in a quick, lightweight, yet effective manner.

I consider this “Product Opportunity Assessment,” as I prefer to call it, an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.

Fortunately, it’s really not that hard to do a useful product opportunity assessment. I ask product managers to answer ten fundamental questions:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

The hardest question to answer is usually the first, which surprises people because it sounds like the easiest. But ask most product managers what problem their product is intended to solve, and you usually get a rambling list of features and capabilities, rather than the a crisp, clear and compelling statement of exactly the problem that’s solved.

Another difficult problem can be in assessing the size of the opportunity. You can get thoughts on this from industry analysts, trade associations, your finance staff, and from your own bottom up calculations. This is a topic in itself, but for now just remember to be conservative and realize that not every opportunity needs to be a billion dollar market.

The “go-to-market” strategy is especially important as that describes how this product would be sold, which can have very significant impact on the product requirements.

The solution requirements refer to any special needs or requirements that were identified during the investigation. Again, we’re not describing the product here but rather making clear any dependencies or constraints. For example, if this is a product that will be sold through system integrators, then these types of partners have requirements around extensibility of the products they deliver. Similarly, there may be branding or partnership requirements.

A product organization is all about pursuing good opportunities and providing great product solutions. Opportunities for new products are everywhere, and it is important that the product manager be able to effectively evaluate new opportunities and identify those that have the most potential for the company. It is just as important that bad product ideas get identified at this stage, before significant time and cost is lost chasing them. Choosing the right set of products to pursue is among the most important decisions a company will make.

It is important that the results of the product opportunity assessment be presented and discussed with senior management, and that the company make a clear go or no-go decision on whether to pursue a product to meet this opportunity. If you do decide to proceed, you will be much better informed as to what you are getting yourself into and what it will take to succeed.

So what do you do if the CEO tells you that this is what we’re doing, so just get to work on the product? First, realize that there are sometimes strategic reasons for doing a product, so you might need to pursue a product even when it’s unlikely to succeed in the market. That said, I have found that doing this lightweight, quick product opportunity assessment is still valuable in that I become much better informed about what this product involves. It is possible that what you learn will change your CEO’s opinion, but more likely it is a good opportunity, and your CEO was right to want to pursue it, but at least now you know what you’re up against if you are to succeed.

Leave a comment

Posted by on November 25, 2011 in Product Management, Uncategorized


Tags: , , , ,

Everything is a Product Management

The basis of the post is this: Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

The same techniques and skills you use to manage product development can be applied to your startup, your business plans—and you, yourself.

It’s about compromises and resources and time. It’s about ship dates. It’s about controlling feature creep. It’s about making go/no go decisions. It doesn’t matter whether you’re an engineer, marketing, management, or sales. In the startup world, everything is a product management problem.

With that in mind…

Everything is a product management problem

Now, I’m no expert in product management.

I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?

  • Meeting #1: Me: “When are we scheduled to launch? What’s the date?”
  • Meeting #2-#999999: Me: “Does that affect the launch date? Is the launch date slipping?”

Yes, vital component. That’s me.

But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.

And here’s where the worm begins to turn.

So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.

How so? Well, let me outline some of the high points of product management.

  • Timeline / Road map / Lifecycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life. And every change that is made is reflected here. All the new features, all the slips, all the last minute requests, all the executive force ins. Not only is interesting and vital to managing the process, it’s one hell of a document for the post mortem. And it’s the polar opposite of our next item.
  • Trade offs and compromises. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
  • Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy more time? Can I buy more resources? Do we have to build? Can we partner? Can we acquire?
  • Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.

So taking those high-level points, shouldn’t we all be product managers for everything we’re doing? Shouldn’t we be product managing our startups? Product managing our investors? Product managing our employees? Product managing our product?

I mean, couldn’t your startup use some product management? A timeline? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your startup include? Is it Windows, Mac OS, and Linux compatible? What mobile platforms do you support? Where are your feature/function gaps that could move your startup forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?

How’s your startup’s usability?

Think about it. Your startup will be better for it.

Leave a comment

Posted by on November 23, 2011 in Product Management, Uncategorized


Tags: , , , , ,

Product Storyteller – Essential for Product Development

There’s an interesting question on Quora right now:

If you had to pick between an amazing product designer or an amazing engineer to build a new company around, which would you pick and why?

During any product development, the essence should always be targetted at ‘WHY’ than being or ‘How or What’.

If your execution focuses on the how and what of a product whereas in a world where consumers are inundated with choices, products that want to be noticed and adopted must be rooted in the why, in this case you are bound to face issues like scope creep, missed deadlines, overspent budgets, frustrated teams and, ultimately, confused users.

A product is more than an idea, it’s more than a website, and it’s more than a transaction or list of functionalities. A product should provide an experience or service that adds value to someone’s life through fulfilling a need or satisfying a desire. But who defines these values?

Let’s face this: The executive and the stakeholders would eventually define or identifies the idea…but after that who would be there in the organization to actually deliver the value to the customer? May be a Product Manager, Marketer, Technologist, or designer? Or perhaps…well…The Product Story Teller?

Who are the product storytellers? A bit of all these: matchmaker, marketer, technologist, and artist, the product storytellers ask questions, find answers, and figure out how to distill a vision or idea into a product story. They develop a plot, identify the people, and shape the product around the specific values it should offer consumers.

How critical a Product story teller can be?

The product storyteller facilitates collaboration and co-creation. Today, many companies have their product and marketing groups disconnected from each other.

Marketing decisions are often made at the executive level—much higher than where product decisions are made.

The result is that marketing tells one story, and the product tells a different story. In the end, consumers are left to put together the conflicting messages and try to determine why they should engage with the product.

A product storyteller should be positioned in the company to help break down the walls between all groups, facilitate the development of a single story, foster collaboration between groups, and ensure that every interaction a consumer has with a product or brand maps back to that story.

Share and evangelize: A common understanding of the product story allows a team to incubate a shared vision. This vision turns into passion, and people with both passion and vision are more likely to produce products that others want to use. Without a firm understanding of the why, the team risks becoming task focused, losing sight of the big picture, and deflating any sense of empowerment or excitement that once existed. When this happens, consumers and the team feel the effects.

In his book, A Whole New Mind: Why Right-Brainers Will Rule The Future, Daniel Pink explains that we’re in the “Conceptual Age” and that skills that were revered in the Industrial Age and Information Age are not as integral to where we are as a society today. Pink writes:

We’ve progressed from a society of farmers to a society of factory workers to a society of knowledge workers. And now we’re progressing yet again—to a society of creators and empathizers, of pattern recognizers and meaning makers. We’ve moved from an economy built on people’s backs to an economy built on people’s left-brains to what is emerging today: an economy and society built more and more on people’s right-brains.

The challenge today is that we face a shortage of storytellers because our current organizational structures and cultures are not optimized for the activities involved in storytelling, reason being : Ownership of product value,  communication disconnects, vision not in line with the original vision…

Marty Cagan, a product management and product strategy expert, addresses this issue in his book Inspired: How To Create Products That Customers Love. Cagan notes that there are two key responsibilities of the product manager: “assess product opportunities, and define the product to be built.”

The product storyteller should synthesize rather than analyzes, should see the big picture rather than becoming stuck in the details, and ensure that all product interactions and touchpoints form a cohesive and value-based consumer experience.

So whether you are at a small start up or a large organization, whether you are a founder, executive, technologist, designer, manager, or marketer, ask yourself this: do you know your product’s story? And perhaps more importantly, who creates your product story?

Courtesy : UXMagzaine

Leave a comment

Posted by on October 18, 2011 in Product Management


Tags: , , , , , , ,

Scope of your Product….

While going through an interesting blog by Jeff Lash (…he explained in detail about defining the scope of the product and as a product manager you yourself should take this responsibility…by doing a proper market analysis and thorough understanding of the customer, as to how do they see it…

A bad product manager, define the scope of her product as how she see it. After all, you’re a product manager, right? You’re not a supplier manager, or a vendor manager, or a promotion manager. You can’t be held responsible if the free gift you offer with your product breaks within the first week. This is so very true for quote a few of Product Managers. And for them it becomes all too easy to delegate the stuff they by themselves should be responsible to complete.

It’s not your fault if your program won’t install correctly on computers with certain virus software. How are you supposed to know when a partner website changes their design without notifying you so that all your links to them break. In cases like this the best only thing you can do is just let customers know it’s not your fault and tell them to whom they should be complaining.

A good product manager, define the scope of your product as how the market sees it. You should know in and out of your product, you know who is responsible for what within the company and probably who dropped the ball on something outside of the “official” scope of your product. You need to forget all of that. What really matters is the scope of your product from the point of view of the customer.

Everything that the customer experiences in relationship to your product is ultimately your responsibility. Delays fulfilling a rebate may technically be because of mistakes made by the company handling the payment processing, but it reflects badly on your product. Broken links from your website to another may be because of changes the other site made, but customers perceive it as a problem to your site.

It’s very easy to draw the line and say that certain things are outside your control. That’s a short-sighted approach, though. Ultimately, those within the organization and outside it will look to you when these types of issues arise, and for the overall good of your product (and your career) you need to step up and take responsibility.

Leave a comment

Posted by on October 17, 2011 in Product Management


Tags: , , ,

Good Manager vs Bad Manager

Ben Horowitz is a venture capitalist in Silicon Valley. He was the CEO of Opsware before he became a VC – so he has real-world operating experience as well, and I love to read his blog regularly.

I was reading one of his recent posts, which linked to a document titled “Good Product Manager, Bad Product Manager”. Ben wrote it when he was the Director of Product Management at Netscape. The purpose of the document was to share his expectations with product managers in his team.

Read on for the link to Ben’s PDF and my favorite part of the document…

I love this part of doc…

The whole document is excellent – but my favorite part is:

Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).

Here is the link to Ben’s PDF – check it out. Whether you’re a Director or VP of Product Management (i.e. responsible for managing product managers), or a Product Manager yourself – the PDF is an excellent read.

Leave a comment

Posted by on October 17, 2011 in Product Management


Tags: , , ,

Essential for Product Managers : Writing Effective Use Cases – Book Review

Writing Effective Use Cases Front CoverAlistair Cockburn is a well-renowned expert on agile development and use cases; his book Writing Effective Use Cases is a “must read” for all product managers.  This is a book which will become part of your core reference library, never far from your reach.

For someone who has never written a use case, this is an excellent starting point, covering all you need to know about use cases to be successful.

For those that have written use cases, I am confident that you will find many new valuable nuggets of information that will help you in your job.  The book is manageable in length (270 pages including appendices and index) and very practical with many examples of uses cases throughout (including examples of bad ones). The most valuable aspect to the book is Cockburn’s professional advice and tidbits that he sprinkles throughout the book.  Anyone who is familiar with Alistair Cockburn’s work knows that he has a great deal of experience, and it shows in this book.  This book is short in theory and long in real-world examples.

Cockburn refers to use cases as “scaffolding” that connects various pieces of the project, which is very true.  Use cases are crossed linked to requirements, user interface designs and test plans, creating a traceability matrix throughout the lifecycle of the project.  Cockburn dedicates a chapter to how use cases fit in the overall process.  Managing the entire body of use cases is just as important as writing them.

A big part of any product manager’s job is time management, and Cockburn addresses this in the book.  It is not feasible to write detailed use cases right from the start, and it certainly cannot be done for all of the potential uses cases.  Cockburn stresses the importance of “warming up” with use case briefs or narratives, and then working towards more detailed, fully dressed use cases.

Best part is the section on differentiation between requirements and use cases – this is an important concept for product managers to understand.  In short, use cases really are requirements.  Properly written, use cases describe the behavioral requirements.  However, with that said, use cases do not deal with all requirements such as the non-functional ones (external interfaces, performance criteria, documentation standards, etc.).

As a product managers you may have your own format or preferred method for use cases, Cockburn provides many examples of different use case styles.In short the UCs are “fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general”. The use cases must be easy to read, short and clear for all stakeholders to understand.

1 Comment

Posted by on October 15, 2011 in Book Review


Tags: , , , , ,