Cauvin

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 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...

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...

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...

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?

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.

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...

In their Bloomberg piece, "Why Innovation Is Beginner's Luck" , G. Michael Maddock and Raphael Louis Vitón write that companies emphasizing industry experience in their hiring practices do not, as a general rule, innovate well. On a related note, I've written before that industry experience is a poor substitute for the ability to learn markets . And don't forget Buckingham and Coffman's observation that the best managers hire for talent, not for experience . If you are hiring for innovation, the first bit of advice from Maddock and Vitón is: "Stop hiring leaders from your industry. Ask recruiters to look for a specific problem-solving ability instead of industry experience. Find leaders who have created the results you want in a unique way. For example, if you are faced with disintermediation issues—and all service companies are—look for experts who have tackled disintermediation. It's likely better that they know nothing about sump pumps or ...

Believe it or not, prospect problems and product positioning play only a small part in customers' decisions to purchase or use your product. The majority of obstacles to product adoption lie in the behind-the-scenes decision-making processes that people and organizations face. It's true I've dedicated many entries on this blog to pointing out that, to market and sell a successful product, you must develop it so that it: Solves problems that prospective customers face. Captures or "owns" a compelling position in the mind of the prospective customer. Many, if not most, products fail on both these counts. I've explained how the best product managers acquire market understanding and apply marketing principles to address these issues. Nonetheless, even products that solve problems and are well positioned often fail, because buyers weren't able to deal with change management issues that precede the purchase of a product. Prospects wishing to pu...

Trying new things - especially new software products - can be both intimidating and time consuming. You face a challenge when introducing a product in the marketplace. The forces of nature are working against you, since almost everyone but " early adopters " resists trying new products. A major reason people resist trying new products is the learning curve. People simply don't have the time or patience to wade through pages and pages of documentation just to figure out what a product does, envision what it's like to use it, and how it would disrupt the way they live their lives. One thing you can do to minimize this obstacle to adoption of your product is to provide the shortest path. Providing the shortest path means minimizing the time and effort necessary for a first-time prospective user to obtain demonstrable value from your product. To provide the shortest path, you do some combination of the following: Make available a "quick start" guide that a pr...

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the...

It's common for people at all levels of a company, and in all company departments, to comment on the usability of the product or company web site and give suggestions on how to improve it. Why? Here's a clue. I wrote in late 2005 that: Most people, including executives, consider much of marketing to be common sense. We're all consumers, so we all know how we respond to products, names, logos, advertisements, and PR, right? So we're all experts on what works in marketing, no? Wrong. See the original blog entry to learn why marketing is not common sense . The same principle applies to usability. In playing the role of consumer in many aspects of our lives, we use products and web sites, and we know which ones are usable - and perhaps even what makes them usable - right? Wrong. Just as marketing isn't common sense, usability isn't common sense, and for the same reasons. Nonetheless, debates over usability and strategies for redesign can get quite contentio...

Reading Al Ries and Laura Ries' War in the Boardroom , I took particular note of the following excerpt (page 36): [A] left brainer at a smaller company thinks, "We can't afford the costs of launching a new brand. So let's use our existing name. Furthermore, we already have some good consumer recognition. With a new brand, we'd have to start all over again. We don't have the resources to launch a new product and a new brand at the same time, nor is it necessary to launch a new brand." The authors ridicule this line of reasoning, which is unfortunately common even among marketing professionals . The authors counter that successful product strategists: Strive to create a new product category. Create a new brand to stand for that category in the mind of the customer. Keep the brand focused on that one category. In the short run, creating a new brand may be more expensive. But in the long run, trying to "stretch" a brand name to stand for more th...

I will be in Sydney, Australia in early November to facilitate the fourth installment of brainmates ' Product Talks . The conversations will focus on the challenges of balancing commercial initiatives with user experience concerns. A copy of the media release follows: Raising the Bar on Product Management Excellence brainmates is inviting Product Management specialist, Roger L. Cauvin , to Australia this November to lead public and client events in Sydney, offering his expertise and fresh perspectives in Product Management to local corporations. Cauvin will be facilitating brainmates fourth Product Talks session, a free quarterly forum that brings together product and marketing professionals to network and discuss issues in contemporary Product Management. Cauvin will lead conversations on ‘Balancing Commercial Initiatives with User Experience Concerns’ on November 5th at brainmates’ office. Registration is required to attend Product Talks events. A selection of brainmates clie...

Pragmatic Marketing has a framework for creating and marketing successful, market-driven products. A grid familiar to many product managers and marketers depicts an overview of the framework: The left side of the grid shows the more strategic marketing activities, while the right side of the grid shows the more tactical marketing activities. On the far left side of the grid, we find research activities such as understanding market problems, the competitive landscape, and distinctive competence. On the far right side of the grid, we find presentations and demos, sales or other "special" calls, and event and channel support. The grid is an enormously useful tool for finding the gaps in your company's marketing efforts. Most of us who have taken Pragmatic Marketing classes know that most companies are severely deficient in the left side of the grid. They either have no coherent strategy or have developed strategies without a thorough understanding of the market. Does y...

Before becoming a product manager, I was a software engineer for about eleven years. During my career as a software engineer, I interviewed for many different positions and many different companies. Some of the companies had perfected their interview process; they employed such methods as: Analysis and design sessions Coding quizzes Design pattern questions Development process question/answer sessions The candidate's performance during each segment was fairly objective and straightforward to assess, and hiring managers felt confident that a candidate would excel on the job if she performed well. Any software engineering "rock star" felt confident that she would come close to acing these exercises and quizzes. Now, as an experienced product manager having recently interviewed at various companies, I'm struck that 95% of product manager interviews yield almost no useful or reliable information for assessing how well the product manager would perform on the job. Unfor...

Recently, several of my favorite bloggers have debated the role of product management in agile product development: Adam Bullied asked if the notion of an agile product manager is baloney . Enthiosys argued that agile does and should change how product managers do their jobs . Saeed argued that agile only need affect product management incidentally and at the margins . You'll find my thoughts dispersed throughout some of the comments in these blog entries. If you're an executive interested in the debate, here's what you need to know. First, read a blog entry I wrote in June 2005 entitled "Agile Product Management" . In it, I lay out some of the basics of waterfall and agile methods. Second, read a blog entry I wrote in September 2005 entitled "BUFR" . In the entry, I contended that the two main causes of problems with waterfall methods are big up-front design (BUFD) and big up-front requirements (BUFR). Third, note that the most important set of proble...

Over at the On Product Management blog, Saeed asks us to complete a brief survey on what the biggest problems are in technology product management. I answered roughly as follows: Q1. What do you see as the biggest problems facing the technology product management profession today? Too much tactical activity in the absence of sound strategy. The lack at most companies of a skilled interaction designer or user experience professional role. Q2. What solutions would you suggest to address these problems? Educate executives about the importance of strategy and how to best determine it. Hire skilled interaction designers or user experience professionals. Q3. Which of the following best describes your role/department? Product Management

Over on the Accidental Product Manager blog , Dr. Jim Anderson writes that cost-based pricing of a product is a bad idea, and that value-based pricing is the way to go. Cost-based pricing and value-based pricing are two different ways a product manager can decide on the price of a product. A cost-based price is the cost of producing a unit of the product plus a certain margin. For one example of applying cost-based pricing, see Adam Bullied's blog entry on the pricing new products . A value-based price reflects the value of the product to the customer. The way I suggest pricing a product based on value is to use negative pricing . Dr. Anderson points out that price and volume have mutual feedback effects: Since your unit cost is changing with volume, your price will determine how much you sell. This will then impact volume which then impacts unit cost. As a result: So what’s wrong with cost plus pricing? Simple - cost plus pricing will cause you to over-price your ...

Back in November, Seth Godin wrote about a frustrating experience almost all of us have shared. You call customer service, navigate a long sequence of touch-tone prompts, only to be informed that the office is closed. In Godin's case, he endured nine prompts. If a typical product manager or business analyst presided over the development of this telephone navigation system, I can imagine how it went. "Let me talk to your subject matter experts (SMEs) ." "What are the departments a customer might need to contact?" "Let's draw a chart showing the different paths through the phone system." Contrast this approach with the following focus on real requirements . The product manager or business analyst converses with customers and customer support to understand the problems that they are trying to solve and avoid by calling support. The problems don't just include the reason they call support in the first place. They also include potential proble...