The best analogy to the Product Manager role

I met with Vladimir Bataev yesterday, and this blog post is inspired by him.

If you were asked "what's a Product Manager like?", can you think of a parallel or analogy that can help others understand the role and say "aha.. I get it."

A Product Manager is like a movie director.


Here's what TheFilmMakers.com says about the role of a movie director:

A good director makes sure that all parts of a film are creatively produced and brought together in a single totality. A director interprets the script, coaches the performers, works together with the montagist, etc., interrelating them all to create a work of art. According to Film Scholar Eric Sherman, the director begins with a vague idea of the entire film and uses this to help him determine what is to be done. He gains most when others are given their freedom to show what they know.

The position of the director in the traditional filmmaking process varies greatly and is extremely complex. The film director is seen as a leader of others, as providing a kind of guiding force. According to this view, the final outcome is more or less predetermined by requirements of the script, camerawork, acting, and editing; the director providing certain organizational context to the picture.

A good Product Manager makes sure that all aspects that is required of a product's success are brought together in a single totality. A good Product Manager interprets the vision, trends and requirements, educate the organization, works together with the stakeholders, etc., interrelating them all to create a great product.

Product Managers usually begins with a vague idea of how the product should serve its customers and uses this o help him determine what is to be done. He gains most when others (customers, stakeholders) are given their freedom to show what they know (instead of being autocratic and dictate directions).

The position of the Product Manager in the product development process varies greatly and is extremely complex. The Product Manager is seen as a thought leader, as providing a kind of guiding force. According to this view, the final outcome is more or less predetermined by requirements of the customer, technology, design and marketing; the Product Manager provides organizational context to the whole process and ensure all the departments are orchestrated to perform to the success of the product.

Thanks Vladimir :)

The path to successful new products, according to McKinsey

According to a survey done by McKinsey in North America and Europe, the businesses with the best product-development track records do three things better than their less-successful peers:

• They create a clear sense of project goals early on.
• They nurture a strong project culture in their workplace.
• They maintain close contact with customers throughout a project's duration.

I certainly find the 3 very relevant and agree that a business will be in peril of the 3 does not exist. My experience with the 3:

Keeping it Focused

I find that while it's easy (as a product manager) to get a small group of people (the product management or the development team) focused on the goal, but very challenging to get all the other stakeholders to focus on the same goal.
Key reasons - misalignment of interest or the so called "KPI". If the sales & marketing team have different KPIs, your product development might not get enough attention (unless it's a money making machine). If the customer service team has a different agenda in what they tell the customers, your product might not be used in the intended way...

Project Culture

The article says it all: "When people with critical skills become overburdened, they often decide on their own which of their many projects is the most important, a decision best made at the management level."
And I thought good project management is very much about making sure the project delivers the intended result, but often we see project teams merely aiming for "completion of project" rather than "getting the result" itself. How many "projects" created in your organization is actually geared towards the desired result? And does everyone agree on what is the desired result to begin with?

Talk to the Customer

"More than 80 percent of the top performers said they periodically tested and validated customer preferences during the development process, compared with just 43 percent of bottom performers."

Validated customer preferences during the development process? Wow.. that's pretty much unheard of in Malaysian context. Correct me if I am wrong.
I have personally done that - though one could argue that I actually released a beta version of the product to do market testing so it's not technically in "development" anymore. I can testify that it is indeed a valuable process to minimize risk and increase chances of success when the final product is launched.

Ref: McKinsey Quarterly - The path to successful new products

On the roll

I was quite surprised and happy to see my blog Product Matters on the blog roll of On Product Management today.

It's number #44 on the list.
Coincidentally, I am employee #44 in the company I have served as Product Manager all these years.

Thank you - to the folks at OnProductManagement.com.
That means I will work harder on more quality posts.

 

 

Posted via web from Great article collection for Product Managers

Why Not? | Yale Economics Lecture

Watch it on Academic Earth

via academicearth.org

Posted via web from Great article collection for Product Managers

Six questions when no one wants to change

Six questions when no one wants to change

Posted using ShareThis

Dedicated Product Teams

Article: Dedicated Product Teams

In my last article (see http://www.svpg.com/knocking-down-walls/) I talked about the importance of knocking down walls, especially the wall between product management and engineering.  In this article, I want to describe a technique that helps achieve this, along with several other significant benefits.

While there are many variations, there are essentially two common ways of running your product organization.  The most common of the two is to do some form of project-based planning.  In this model, the management of the company essentially defines a communal roadmap – they come up with a prioritized set of projects for the quarter or year, and they allocate time and people to those projects.  For example, they may have a team spend two months working on a new advertising system, and then the next high-priority project for that team might be a new search technology, or some SEO work.  The team may or may not change, but the project and even domain they are working on typically changes frequently.

Basically if you look at the communal roadmap, you see a mosaic of different projects, each row typically an allocation of a set of developers to a project.

These roadmaps hardly go a week without significant change.  Some new business opportunity comes in and takes priority, so that throws a big wrench in the plans and a bunch of shuffling is done, or a project takes longer than expected, so that has a ripple effect.  

(Not to mention that these project-oriented portfolio roadmaps are typically created before there is any real information or knowledge on what it will really cost to build this, and whether customers will actually want to use it.  But that’s a different issue.  See http://www.svpg.com/your-business-plan-is-wrong/).

These communal roadmaps change so frequently are are so full of assumptions that they’re rarely something companies enjoy, but nevertheless this is often how they run their product organizations.  There are, however, several less obvious consequences of this approach.

First, teams are constantly moving around.  Product managers team up with specific developers on a project basis.  Often they don’t have nearly the time they need to form the working relationships so important to effective teams.

Second, the developers are often constantly reassigned to different areas.  While on the positive side the developer gets exposed to lots of different areas, they often don’t get the time to develop the deep expertise in an area that can make a developer so incredibly valuable.  

Third, since the developer is switching topics so frequently, they don’t develop the velocity that an experienced team does.

Fourth, since the developers are scheduled on different projects beginning right after the prior project ends, this tends to encourage what we call “release and forget” where a project is launched because it is scheduled to launch, but the follow-on work and the product optimization work gets deferred for months or even indefinitely because the team is on to other projects.

The alternative to this, which I’m happy to say is spreading fairly rapidly across our industry, is to move to dedicated product teams.

In this model, the executives, rather than debating specific projects, instead consider which areas of the business they want to invest in, and what percentage of resources to allocate to each area.  For example, for a typical e-commerce company, they might have teams like “Search and Recommendations,” “Product Pages and SEO,” “Fulfillment Systems,” “Infrastructure,” “Rapid Response” and “New Business Opportunities.”  They would then choose what level of investment they consider appropriate for each area.

The next step for the management team in this model is to define Product Team Scorecards for each of the teams (see http://www.svpg.com/the-product-scorecard/).  This essentially sets the business priorities for each of the teams.

Next the organization staffs the teams with a product manager, user experience, developers, and QA, in proportion to the allocation decided above.

In this model, the team then is charged with coming up with the projects, features and fixes that they believe will best deliver on the KPI’s defined in the Scorecard.  

There are two important differences here.  The first is that these teams are ongoing.  They don’t switch from topic area to topic area after every project.  Instead, they focus their energies on building true expertise on their topic, and coming up with real innovations in their areas.   The second is that the team members are persistent, in that they are assigned to this product area and they’re not just here for the specific project.

Of course management may choose to adjust the balance of resources by reallocating people, or by adjusting the Scorecard to reflect changing business priorities – this usually happens quarterly or annually.  And of course people are not sentenced to work on this area for the rest of their career.   They can and should move between teams, but generally people are working on a team for a year or so, and not just for a few weeks or months.

As I watch companies switch to this model, I consistently see the velocity go up as the teams gain expertise.  I also see the quality of product go up dramatically which I attribute both to the relationships that are built and also to the sense of ownership that teams feel over their area.  But most importantly, I see the business results that stem from the focus, the better product work, and from continuous and rapid improvement of the product.

A few notes:

- A very useful dedicated product team is the “rapid response team,” there to handle critical fixes and relatively minor improvements and functionality.  I’ll describe this in more detail in an upcoming article.

- I also like a “new business opportunities team” that is there to explore new potential products or sources of revenue.  In most companies, these opportunities will always arise, and if you don’t have a team available to pursue, then all too often other teams are raided for resources.  Instead, plan for a small team to pursue these opportunities, and help them get good at evaluating potential.

- The one team and allocation that’s usually a given is the “infrastructure team.”  This is a special team, usually comprised of just engineers and architects, and the allocation is typically 20% for consumer internet companies.  You can instead intersperse this work into the other teams, or you can have a blend (a dedicated team plus some resources in each of the other teams).  See http://www.svpg.com/engineering-wants-to-rewrite/.

- Moving to Scrum, if you haven’t already, will get you part-way towards dedicated product teams.  It helps a great deal in building the personal relationships of an effective team.  But all too often, Scrum teams are still handling backlog items from many product areas, and not being given the ability to focus on an area as a team.  That’s the difference really between a project team and a dedicated product team.

While I typically recommend moving to dedicated product teams for the full product organization, be warned that this is not a trivial change and requires executive support.  If your organization is not yet convinced, you can move just one or two teams to the dedicated product team model.  If you give this model even 6 months I’m fairly certain you’ll see the benefits and hopefully make the switch at the next planning cycle.

You can find all articles at www.svpg.com/blog. />

Posted via email from Great article collection for Product Managers