Software Product Management
What is Software Product Management?
The Product Manager is a champion of the customer. The Product Manager's
primary responsibility is to ensure the product being developed or enhanced is
most relevant to the customers needs.
This cannot happen without seeking out the Voice of the Customer. Good
Product Managers don't confuse vision with insight. Vision, is what you
think the product ought to be like. Insight, is what you discover the
product ought to be like, from talking to the customer.
Marketing vs Development? Who should do Product Management?
Organizations tend to have several different models to address who does the
product management. In some companies, Development drives product
management; in others, Marketing. Some companies even have a separate
Product Management department.
There are really four Product Management models common in software
development. These are:
-
A separate Product Management department
-
Marketing Product Managers that work with developers
-
Development Product Managers that work with developers inside of Development
-
No Product Managers--development team lead is the Product Manager
1. Separate Product Management Department
Corporate size is a factor with this choice. Generally, resource funding
is not a problem if a company chooses this configuration. Although
organized nicely, this is not a lean-development model (see Cons, below).
Benefits include a more disciplined product management methodology can evolve
over time. Dedicated Product Managers become comfortable and effective
talking to customers often. Product Managers become free of distractions
that occur within the daily activities of Development or Marketing.
Cons include increased finger-pointing between departments, and also, a slower
overall software yield. Communication is slower and if the company is not
matrixed effectively, the individuals working together in different departments
will find excuses to delay progress by saying, conveniently, "my
manager asked me to work on other things this week."
2. Marketing Product Managers that work with developers.
This is not a popular model, but is does exist. This model reflects a
charcterization of marketing that they are not just a lead-generation group,
but rather, are responsible for the success of each product. In my
experience, something like 1 in 10 software development companies are set up
like this.
Benefits include a dedicated person assigned to the customer relevance of the
software product. Most marketing professionals spend most of their time
associating with customers and industry. This makes them a good candidate
for Product Management. Also, by virtue of the project being "managed" by
more than one department promotes the project higher on the corporate
radar. It will naturally be talked about more often in more departments,
minimizing communication risks.
Cons include the tendency to finger-point, and backseat drive development.
Some developers can feel territorial about their ideas and simply refuse to
comply with "someone is another departments ideas," which can be detrimental to
the product. The managers of both departments are left with how to decide
on outcomes. Because both team-members are working for different
departments, again, it becomes convenient to delay progress by saying "my
manager asked me to work on other things this week." This is also, not a
lean model.
3. Development Product Managers that work with developers inside of Development
This is the most popular model among smaller-to-midsize companies. The
Product Manager is tasked with gathering the Voice of the Customer from the
customers, the Voice of the Market from marketing, and delivering the
information to development.
This is a lean model because, not only does the Product Manager and the
developers work together, but they must work towards visible goals and answer
to the same manager with more frequency. Finger pointing gets
squashed much sooner, and one single manager can set priority on
projects. This represents a lean-development model and preserves the
"pride of ownership" within development.
Cons are that projects can be unduly influenced by one single development
manager. Also, projects can be siloed in development without proper
communication to the rest of the company. A frequent multi-departmental
development status-update process solves this problem.
4. No Product Managers--development team lead is the Product Manager
By necessity, this is a popular model among start-ups and very small
companies.
This model actually represents a good process so long as the development team
lead really has the time to extract the Voice of the Customer on
projects. Benefits include faster time-to-market--because there is
minimal knowledge-exchange needed, and fewer group decisions to be made.
Cons include the programmers tend to get busy with development and shun the
customers for decision-input. Also, some developers are seasoned with
techno-speak, and can unknowingly intimidate non-technical customers, resulting
in a less-effective customer-feedback process. The key-man-reliance
problem is amplified here because only one person knows the encompassing
details about a project. In order to mitigate the key-man-reliance
problem, thorough documentation is required. This begs the question,
however, that if the developer is doing the product management, and the
documentation, then who is doing the coding? In reality, one or two of
the three will suffer.
Capturing the Voice of the Customer: Ensuring Relevance!
Effective Product Management is a strategic factor in the final adoption
success of a product being developed or enhanced. Often, design groups
sit together in a room across a table from themselves and create a
'vision' for what the customer wants. This is not the same as
the insight gained from ongoing collaboration with the customer base.
Countless projects have failed due to the omission of this one dynamic.
Successfully collecting the Voice of the Customer requires a comittment
from the corporation.
Time must be allotted on project plans for it. In some cases, money must
be budgeted for it. To start, here are some simple methods for collecting
the Voice of the Customer:
-
Phone surveys after sales process, after installation, and three months after
installation.
-
Phone surveys at the end of incoming support calls. (you already have them on
the phone)
-
For brand new projects, a short phone call with a client can provide insight
into what a customer would expect from a conceptual idea being put into
production.
-
A focus group can provide more detailed insight about needed enhancements
or new features.
For projects or strategy sessions that require heavy-feedback, your group can be
divided into teams so that each team can call different
customers. Each team makes a detailed list of responses from their
contact engagements. After the calls are made, the lists are compared and
the items appearing most frequently should be the highest priority.
Another strategy is to call many customers, collect all of their input, and then
show each of them the entire list and have them prioritize the items for
you. Compare the prioritized items and you will have your hierarchy.
How is Product Management different from Project Management?
Software Product Management is Different from Software Project Management in
that the Product Manager is responsible for the relevance of the content in the
software produced, whereas the Project Manager is responsible for the project
being delivered successfully on-time and on-budget.
Read more about Software Project Management
Recent Posts on Product Management...
Software Production Support (5/20/2008)
In a conversation with a friend once, they jokingly described their inability to play racquetball against other seasoned players as ”They are playing racquetball, while I am just hitting a ball around the room.”
I’ll borrow that reference and apply it to Software Production Support.
Is your Software Production Support group ”playing racquetball,” or are they “just hitting a ball [...]
Book Review: Software Project Survival Guide (11/29/2007)
In Steve McConnell’s book, Software Project Survival Guide, he describes the foundation and procedures for managing a successful software development project.
Researching from NASA, IEEE, and some other industry giants like Grady Booch and Tom Demarco, McConnell summarizes software development into six stages:
Planning
Design
Construction
Testing
Release
Wrap-up
McConnell also offers some great ideas like keeping a project history to record lessons learned [...]
Book Review: Reinventing Strategy (11/28/2007)
I just finished reading Willie Pietersen’s book, Reinventing Strategy: Using Strategic Learning to Create and Sustain Breakthrough Performance.
Pietersen first sets the stage for the rest of the book by underscoring the need for organizations to be adaptable. He paraphrases Charles Darwin, concluding that is it not the largest, the strongest, or even the most intelligent of species [...]
Book Review: Product Development for the Lean Enterprise (11/23/2007)
I finished reading Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It, by Michael N. Kennedy. This book explains why Toyota’s internal product development process has enabled them to surpass the Detroit auto manufacturers production in both volume and quality.
If you haven’t heard already, Toyota now [...]
| Related Seminars |
Date |
Register |
|
|
|
|
|