Skip to main content


Showing posts from 2011

Who "Owns" the Product?

Recently, I've noticed a number of product managers on social channels claim that product managers "own" the products they manage.  On the surface, this claim seems rather innocuous and uncontroversial.  But the claim bothers me, for several reasons. Let's examine why anyone would make such a claim.  I can think of a few reasons.  (I'll get to the notion of "product owner" in agile development later.) First, a single point of accountability simplifies how we conceptualize the product management role.  It's understandable that product managers are tempted to find a simple definition of product management.  The responsibilities of the role vary greatly across different companies, and few people can articulate concisely what a product manager is or does.  So it's nice to boil it down to ownership of the product.  But what does it really mean to own the product? Second, many folks in the product management community are familiar with the deba

Join Me at ProductCamp Austin 7

Join me Saturday, August 6th, 2011 for ProductCamp Austin 7 .  ProductCamp is an "unconference" where  product management and marketing professionals teach, learn, and network. Along with a team that included John Milburn , Scott Sehlhorst , and founder Paul Young , I attended and helped organize the first ProductCamp Austin .  This time, assuming our proposed session makes the cut, we'll be leading a panel discussion on the future of product management. You've heard the traditional challenges product managers face ( basing product decisions on market problems , leadership without formal authority , getting buried in tactical tasks).  But product management has grown up, and there are new challenges we face.  What is the future of product management, and how will it address these new challenges? Austin's "Gang of Four" product managers will lead an interactive conversation on such topics as: 1.  We've gone agile.  Do we still need product man

An Epic Conversation

The following is a fictitious example of the type of conversation that could occur at many organizations claiming to use agile development methods. Joan is the VP of engineering at Trendy Startup, a rapidly-expanding company developing a suite of cloud storage products and services. Joan's organization uses the popular scrum development process to develop its products. Product managers and owners create user stories, allocate them to iterations and releases, and manage them in backlogs.  Quality assurance (QA) engineers write tests for the user stories, and developers implement the user stories.  Team members meet daily to review the previous day's accomplishments, agree on what they'll do today, and surface any obstacles they are facing. Joan is proud of her teams and their adoption of agile methods and practices.  She touts the Trendy Startup's development processes to her fellow executives and to prospects and customers. All members of her product teams hav

Debunking Leadership Myths

Typical Conversation Between Product Managers Many conversations about product management and leadership have taken place in the blogosphere and Twitter.  The typical exchange goes something like this: Product Manager 1:  "Product managers have a lot of responsibility but no formal authority." Product Manager 2:  "Authority is something to be earned, not granted." Product Manager 1:  "But developers and sales don't listen to me, because they don't report to me and are in different departments." Product Manager 2:  "Great leaders work with cross-functional teams." Product Manager 1:  "Yes, but I don't get any support from executives when I work across departments." Product Manager 2:  "You shouldn't need support if you are a great leader." Leadership Myths Let's put to rest the two opposing leadership myths that underlie these types of exchanges.  The opposing myths are: A great leader's effec

Talents of Great Agile Team Members

Recall the advice of Marcus Buckingham and Curt Coffman: hire people based on talent, not so much for experience, intelligence, and determination . Talent is defined as “a recurring pattern of thought, feeling, or behavior that can be productively applied”. So, what are the talents that great agile team members share? Here are some possibilities: focus – sets goals and uses them every day to guide actions discipline – imposes structure onto life and work reflection – examines past choices and learns from experience adaptability – quickly adjusts practices to achieve goals strategic thinking – plays out future alternative scenarios cooperation – interacts with others constructively Note that, when a person possesses them, talents span every aspect of a person’s life and do not merely manifest themselves in a particular job or work environment. How would you add to this brainstorm of possible talents that great agile team members share?

ProdMgmt Talk on 02/28/2011

Join me on 02/28/2011 (Monday) at 5 pm CT for the next ProdMgmt Talk. ProdMgmt Talk is a weekly Twitter event in which product management professionals examine and answer questions about a particular topic. You can follow the conversation here or configure your favorite Twitter tool to show tweets containing the #prodmgmttalk hash tag. This week's topic is innovation and how it relates to product management. We will be discussing the following questions: Are product managers innovators or innovation enablers? What do great product managers do to innovate or foster innovation? What is the relationship between requirements and innovation? Does agile product management foster or hinder innovation? How would you answer these questions? I'll be sharing my thoughts and hope to see yours on Monday.

How to Prevent Product Paralysis

Does your company suffer from product paralysis? Product paralysis occurs when progress halts on improving or innovating a product. At some point, you've probably experienced: A product team can't agree on major product decisions, so they concentrate on minor bug fixes and enhancements that have little or no market impact. Bold product decisions are made (often by members of the team that just happen to wield the most influence at the time), but the decisions come under fire and are put on hold shortly thereafter. Team members don't buy into product decisions, so they undermine them, stall their execution, or just aren't motivated to be productive in executing them. The most effective product managers - to the extent that company executives empower them to do so - employ three approaches to prevent product paralysis: Base product decisions on market understanding and marketing principles . Teams will not buy in to major product decisions unless they can make a compe