BY PETER DUGGAN | ORIGINALLY PUBLISHED IN PDMA VISIONS MAGAZINE, ISSUE 2, 2016 • VOL. 40 • NO.2
Ideas are the lifeblood of product development. And product managers need more and more blood on a regular basis.
There are many ways to get ideas for the next product breakthrough, but you need to know how to find them. If you are not working on and rolling out new products or product enhancements on a regular basis, someone is going to ask “Why do we have all these product managers?”
I’m in a service business. My team doesn’t produce physical products sold in stores or online. We provide shareholder record-keeping for public and private US companies, and as such we service their registered shareholders — paying the dividends, mailing and collecting proxy cards for the annual meeting and transferring ownership. So our products are services that address the problems of our issuer clients or their shareholders.
The intent of this article is to offer ways to solicit ideas from across your organization and externally. I’ll touch on ways to source the ideas, size the benefits of the ideas select the projects or portfolio of projects and track the pipeline of ideas and their status. I’ll also offer some tips for reporting to your management on how projects are performing.
IDEAS ARE EVERYWHERE
I’m not a fan of short term campaigns with catchy names with prizes for submissions. That tends to imply that idea generation is a project or a game — something only done periodically and for a reward. I believe idea generation to improve the business is the responsibility of every employee in the company.
I like to solicit ideas from across an organization and welcome the opportunity to brainstorm at staff meetings from operations to relationship management, marketing and sales. I’d rather pay for a pizza lunch with a team of operations or relationship management staff to talk about ideas than offer a prize for the best idea.
Sometimes the ideas don’t come from inside. In that respect, I’m a fan of: 1) old-fashioned focus groups with customers (or shareholders, in our case) to tease out their pain points, 2) surveys and 3) inviting test subject groups into a facility to use services while the product staff watches from behind a two-way mirror. (Does anyone invited to these sessions not realize that behind the large mirror at the back of the room is a group of excited product mangers hanging on their every word?)
SIZE IT UP
After gathering ideas, you will need to size them: What are they worth to the organization? I wouldn’t look for perfection here. I assign product managers who seek out other subject-matter experts and use a standard template to come up with a “back-of-the-envelope” sizing of the opportunity: revenue to be earned, expense to be saved, percentage of clients retained or satisfaction improvement — whatever the objective of the idea is.
It’s also important in the sizing phase to document a number of other aspects: implementation timing, the various groups within your organization that need to be involved (legal, technology, operations, marketing, etc.) and all assumptions.
Make sure you put all the ideas into some kind of a database. It can be as simple as an Excel spreadhseet, or something you build specifically for this purpose. The database should have fields for the idea description, the source of the idea, the opportunity size, the assumptions, the issue it addresses, the timing it might take to complete and other components you deem important.
The more you can create categories for the ideas to group them, the easier it will be over time to find overlapping or duplicate ideas. Categories might be revenue potential, expense savings, market share improvement, client satisfaction or risk reduction — it depends on the charter of your product team. You can also have subcategories: Within revenue potential, for example, might be increase in price, increase in volume of existing product, etc.
DECIDE HOW TO MOVE
Once you have the ideas sized, you have a pipeline, in the form of the database. The pipeline, simply defined, is the collection of opportunities that could be pursued. Now we move to the phase of selecting the projects to actually pursue. The nice thing about having a pipeline is that you can prioritize and know which ones you will move to next as resources become available. Selecting the projects will depend on a number of factors, such as your staffing, your corporate culture’s ability to absorb change, the availability and buy-in of the groups needed to implement the ideas, your budget and your corporate goals.
You can pick the projects without much science, or you can use a portfolio approach. With a portfolio approach, you decide in advance what percentage of projects you want for the various categories; or you can decide you want roughly 80 percent of your projects to produce revenue in the next one to two years, and 20 percent to be more strategic long-term revenue opportunities. Having portfolio targets will help prevent situations in which you pick projects at the whim of meeting this year’s financials without a strategy.
Once a project is decided on and becomes active, assign an owner (the one-throat-to-choke approach), the start date and the anticipated live date. After the assigned owner reviews the assumptions, create a revised opportunity sizing. The sizing may or may not change until the project owner starts working on it, but it should be updated on a regular basis as the project moves forward and more information is known.
The database can also be used to track the status of the project as it is being worked on. I like the red/amber/green approach to report on how the projects are doing. The database therefore becomes the source of data for project reporting as well as the pipeline of ideas.
I also recommend setting up a shared library with folders for each project where all documentation is stored: the project charter, team members, stakeholders, executive sponsor names (if applicable), meeting minutes, opportunity sizing assumptions, etc. If someone is hit by the proverbial bus or wins the Lotto, it’s easy for someone else to take over.
BRINGING IT ALL TOGETHER
Each project will develop its own governance. Larger projects require more complex project plans and very regular meetings and multiple stages of “go/no go” decisions. Smaller ones don’t require as much governance. This is something that the head of product development must put their stamp on. Nothing kills a small project like over-managing] it with too much governance. The greater the risk, the more governance is needed.
I use my product managers, who are the subject matter experts on their products, to run the projects related to their product set. But when the projects are big and complex and involve multiple groups and the stakes are high, I also like to add a project manager — and by that I mean a professional project manager (PMI-certified, if possible). Project management is an art and a science, and best left to the professionals.
I suggest a monthly status report on active projects, with commentary on the amber and red projects. The report should include the latest sizing estimates and timing to complete so the finance folks can project the benefit in the financials. And don’t forget to give credit to the idea-submitters when the projects close and benefits are achieved, and distribute that report widely — not just to the senior management team. That will ensure more ideas flow to you in the future.
Peter Duggan manages the product management and strategy group within Computershare’s Investor Services division, which oversees the development of new products and services for the US Registry business. Prior to assuming his current role, Peter was the head of client management for BNY Mellon’s Shareholder Services division, which was sold to Computershare. Before joining BNY Mellon in 1999, Peter was the head of product management for Deutsche Bank’s global corporate trust business. Peter graduated cum laude from Boston College with a B.S. in English and Mathematics. He received his MBA in finance and international business from the NYU Stern Business School.