Product Roles: The Role of a Director of Product Management

We continue our series on Product Roles and how each role varies, while focusing on the work each Product role can play in an organization. Please keep in mind, product team’s responsibilities can be highly varied. Some organizations have parsed these job functions to other roles, sometimes across departments. The success of that parsing will vary from company to company. In this series, we will focus on what we feel the roles entail in a “typical” product organization.

In this third post of the series, we dive into the Director of Product Management role.

From our first post in the series:

Directors of Product Management look after the business of product management. They usually help oversee the cohesion of multiple product/service verticals and they should be the guiding light on the process and tools used to report the product team’s direction. They are the stabilizing and negotiating hand that ensure teams are operating with synergy. They know when to step in to support a Product Manager and they, most importantly, know when to step back from the Product Manager to let her flourish.

These people have two essential responsibilities. First, they must build a strong team of product managers. Second, they may be responsible for the company’s overall product strategy (if there is no VP) and more commonly, they oversee various products in the company’s portfolio.

The director of product management is really an enabler, mentor and one who often brings process. Their job is to guide, and remove roadblocks while establishing expectations and goals. Directors need to trust in their PM’s ability to execute and the director needs to be the uniting force that ensures their success. This role is one with influence, but often less “power” than the PM has on the product.

Establishing process, building mentor tracts, and championing learning are often some of the primary responsibilities a director will have. The key is to recognize the shift from a doer to enabler.

A typical job description for a Director of Product Manager often includes (with some added company specific, cultural fit type requirements):

  • Providing product portfolio management, mentoring and training Product Managers in best practices, and managing products as needed to support the company’s strategic goals.
  • Owning the end-to-end Product and Solution portfolio and associated financial performance with a P&L orientation.
  • Providing leadership for the product development process across Sales, Marketing, IT, and Operations.

This role is one that works across the organization and negotiates up and down to keep a Product Portfolio on track. It is demanding and time consuming, but with a strong Product Management team, it is highly rewarding when thing go right. Conversely, this person can sink a company if they are not successful.

Using Lean Canvas in (Agile) Epics

A novel approach to utilizing Lean Canvas within Epics in an Agile methodology

Most of us in product / engineering organizations within software companies evolved into Agile development life-cycles over the past ten to fifteen years.  Most of us started out pretty straightforward applying the basic Agile Manifesto probably combined with a Scrum foundation.  Of course, many offshoots and variations emerged and even still younger compliments to Agile continue to emerge, such as Lean Canvas, Lean MVP and others.

I’ve been finding reasons to apply Lean Canvas and MVP approaches for the past five years and have had some interesting successes and failures.  This blog post presents one recent success using Lean Canvas, but in what might be a unique and helpful variation for your organization.

At Envysion, Inc., we were exploring the Lean Canvas, er, canvases approach, as well as following advice from the Silicon Valley Product Group. This meant we were filling out canvases for specific product lines or new product feature groups. We found Lean Canvas and Lean MVP are designed for smaller software projects and are ideal for the first generation (MVP) of a product. For a more mature product company (Envysion is a 100-person company with over a hundred enterprise clients and tens-of-thousands of enterprise end-users), the approach can be somewhat lacking.

Then one of our thoughtful and innovative product managers had an interesting idea:  Use the Lean Canvas structure essentially as the “body” of Epics (and/or Initiatives).  Here’s how it worked…

Background

Within our Agile methodology, we adhere to the approach that Themes beget one or more Initiatives which beget one or more Epics beget one or more Stories beget one or more Activities.  There is always more work than we can possibly address within a quarter (our planning extends out six quarters at the moment).  If we apply the Lean Canvas approach to feature groups, we’d be writing a lot of Lean Canvases.  That’s not necessarily a bad thing, really, but combined with the fact we also have to write a lot of Initiatives and Epics, it adds up to a lot of time we don’t have.

When writing Initiatives and Epics, we were following the general approach that you might learn from an Agile coach or through your own experience of writing requirements and Stories and such over the years (As a… , I need… so that). We were consistently providing context and background, a description of what the problem is, how we might want to solve it and what benefit our customers might gain from the result. One of our product managers realized this approach encompassed most of the aspects of a Lean Canvas. In an effort keep our Initiatives/Epics short-and-sweet, we decided to migrate to the Lean Canvas approach, but still provide a consistent structure of information to the reader.

Execution

We now simply apply the Lean Canvas structure to every Initiative and Epic.  There are a few slight variations of the Lean Canvas format out there (and no real standard, yet) but the one we adopted looks like this, which each of these bullets representing a section that is no more than one or two sentences or a short bullet list…

  • Problem
  • Existing Alternatives
  • Solution
  • Key Metrics (of successful Solution)
  • Unique Value Proposition (of our Solution)
  • Unfair Advantage (of our Solution)
  • Channels to Market
  • Customer Segments (including Early Adopters identified)
  • Cost Structure / Considerations (which we measure in Points or “Organizational Dollars”)
  • Revenue Model / Potential

Results

The results have been pretty impressive, substantive and immediate:

  • These turns out to be very fast to write, once you get the hang of it.  It takes a little training, which you can find online in a few blogs easily one good resource from starlit.rs is here: LeanCanvas), your product managers will get it quickly.
  • Engineering and marketing seem to love it as well, so much so we’ve seen other organizations start to use the basic canvas template for their own department’s work.
  • It also seems to help the scoping of the child Stories within those Epics quite a lot, which Engineering also loves.
  • The learning curve of new product managers and engineers is shortened, and the transition time is shortened if we move a product manager to a different product.

Product Roles: The Role of a Product Manager

The Product Roles series focuses on the work each Product role can play in an organization. Please keep in mind, product team’s responsibilities can be highly varied. Some organizations have parsed these job functions to other roles, sometimes across departments. The success of that parsing will vary from company to company. In this series, we will focus on what we feel the roles entail in a “typical” product organization.

In this second post of the series, We are going to dive into the Product Management role a bit more. This description is one of the best over arching summaries we can offer. We will try to talk about day-to-day tasks and what it means to “Be the CEO of your Product.” Some aspect of Product Management include Product Marketing, Product Strategy, or the delineation Agile sometimes put on roles (Product Owner, Business Analyst, etc.). 

From our first post in the series:

Starting with Product Managers – they fundamentally look after individual products/services: shepherding the short-term development efforts and long-term strategy. They work to keep a 3-12 month roadmap that’s coherent. There are manymanymany resources out there that describe the intricacies of this role. At the end of the day, you want to empower these people to own the vision, execution, and support of a product/service vertical. You want to ensure they are accountable for the results the product is delivering.

At the core, The product manager is the person responsible for doing the market research, evaluating and prioritizing the features that will drive the largest benefit for the customer and then validating that feature selection hypothesis (without feedback it is important to know you only have a hypothesis on what will drive the most value). The validation process happens in lots of ways: some build an MVP, some build out the feature in it’s entirety and some merely shop ideas without dev effort at all.

A typical job description for a Product Manager often looks like this (with some added company specific, cultural fit type requirements):

  • Managing the product life cycle from start to end (strategic planning to tactical activities)
  • Specifying market requirements for current and future products by conducting market research
  • Delivering value by working with cross-functional teams (primarily Development/Engineering, and Marketing Communications) to clarify market requirements, product contract, and positioning.
  • Developing and implementing a company-wide go-to-market plan (often times called a roadmap), working with all departments to execute.

These four things may sound easy, but if done well, they are incredibly time consuming and often require heavy context switching. Product Management is an exciting and challenging role; one which can afford you lots of freedom and responsibility. Get it right, and you’re off to the races. Get it wrong and the organization will languish and sputter to see any real success.