Monday, December 05, 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 debate about product management "authority".  Product managers typically lack formal authority but assume much of the responsibility for the output of the product team and for the ultimate success of the product.  Perhaps some product managers believe that, if we convince executives and team members that we "own" the products we manage, they will grant us the authority to make product decisions that stick.

For example, if the product manager disagrees with a user experience (UX) designer on the team about a design decision, the product manager can "overrule" the UX designer's recommended approach, since somehow the product manager's ownership of the product trumps the UX designer's design expertise.  I don't subscribe to this authority-based model, and I doubt product "ownership" does much to support it in practice.

Third, the other side of the product management "authority" debate believes in the romantic notion of leadership as unilateral self-empowerment with little or no enablement from others.  Under this view, product "ownership" implies that the product manager steps up to take full responsibility and accountability for the success of the product despite the lack of formal authority.  It's a statement of confidence and sometimes derision towards those who complain about the lack of formal authority.  Yet this view rests on a naive and overly simplistic view of leadership, as I have argued before.

But the practical reason you should reject the notion of product management "owning" the product is that it undermines one of the key determinants of product success.  The most successful product teams possess a culture in which the team owns the product.  Each member of the team - whether a developer, sales person, marketer, support specialist, or tester - has strengths and plays roles that contribute to the team effort, and ultimately to market acceptance and product profits.  They all feel accountable for the success of the product and the team, and there is no need for a "single throat to choke".  This form of accountability is a highly effective motivator and yields impressive productivity and outcomes.

A product manager's unique role on a team is informing the strategy that drives all the team's product decisions.  She does so by leading the process of eliciting and sharing market knowledge and applying marketing principles to form the basis for sound product decisions.

Finally, no discussion of "product ownership" would be complete without a note about the use of the term "product owner" in agile development.  The original use of the term referred to a person on the team who could serve as a proxy to the customer or market.  It wasn't someone who was solely responsible or accountable for the success of the product or project.  Originally, it wasn't even someone who necessarily had tactical "backlog management" responsibilities.  No, it was mostly a role that helped inform the team's requirements decisions from a customer and user perspective.

A product manager's role is a bit broader than agile's original notion of product owner, in that a product manager's insights and perspectives drive not just requirements, but positioning and messaging as well.

Thursday, July 28, 2011

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 management?
2.  Will product managers join the executive ranks?  (CPO = Chief Product Officer)
3.  Will product managers embrace cutting edge "lean startup" and "customer development" processes?

What do YOU think the future of product management holds?

WHAT: ProductCamp Austin 7
WHEN: August 6, 2011 from 8:30 AM to 4:30PM
WHERE: AT&T Conference Center @ 1900 University Ave., Austin, TX 78705
COST: Network, volunteer, pitch a session idea, or just make new folks feel welcome.

You must register (free) to attend.

You can get transit directions to the event by visiting the Capital Metro trip planner and filling in your starting location.  If you choose to drive, parking is available for a fee in the AT&T Center underground parking lot.

Monday, July 25, 2011

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 have embraced agile methods, but two of her independent-minded engineers, Raquel and Oscar, are frustrated and have begun to question the results. They decide to meet with Joan to discuss their concerns.

Joan: "What's up, Raquel? Oscar?

Raquel: "We're concerned about our development process at Trendy Startup."

Joan:  "Raquel, you know we're an agile shop. It's important that we all buy into agile practices, and frankly I don't think there's a place in our company for engineers who can't fit into agile teams."

Raquel:  "Oh, I have no problem with agile methods. My concern is that I don't think we're really doing agile."

Joan: "Hmm. I'm not sure what you mean. We've adopted all the major practices, haven't we?"

Raquel: "Sort of. But what we call 'stories' are really just development tasks. We're not defining acceptance criteria for our user stories. And our product roadmap is oriented around features instead of what really matters to users."

Oscar:  "Exactly! I'm frustrated because we seem to be losing sight of delivering value to customers. I actually don't care whether we are doing 'theoretically pure' agile, but we've gotten too far in the weeds."

Joan: "Ultimately, we can't deliver value to customers and be successful in the market without dealing with the details; things like font sizes, the positions of buttons and other user interface elements, and even grammar."

Oscar: "Of course. But we need to tie these details back to the larger picture of what the user is trying to accomplish as they are exposed to these details."

Raquel: "Right. That's part of what I mean about not doing agile properly. Many of the stories in our backlog are development tasks to 'move the Cancel button two pixels to the left'. But there is no tie-back to a real user story, which should state what the user wants to do and why she wants to do it."

Oscar: "I would go even further. Even when we do have real user stories, I sometimes lose sight of the big picture."

Raquel: "Good point! We've made some attempts to group user stories under features, but that's not how Mike Cohn says to do it. Cohn says to use epics and decompose them into user stories."

Joan: "But we do use epics. We group our user stories into epics such as 'asynchronous storage' and 'cloud infrastructure'."

Raquel: "But those aren't real epics! A story is a narrative. An epic is a long narrative. Look them up in the dictionary! In agile, a story is a placeholder for a narrative that achieves users' goals, and an epic is a placeholder for a longer, end-to-end narrative that captures and implements the larger goals of the users and buyers."

Joan: "Okay, I have to draw the line here. This organization doesn't care what the real definition of 'epic' is. We're not employing poets or novelists here. And in the final analysis, it doesn't matter whether we're doing what some purists think is agile. We care about producing quality software that will sell in the marketplace."

Oscar: "I couldn't agree with you more on those points, Joan, but I think Raquel has hit on precisely why the team loses the user perspective. Users care about what they're doing and what their goals are, not about 'asynchronous storage'."

Joan: "What would you suggest as an alternative? Can you provide an example of what you consider a true epic, Raquel?"

Raquel: "Here's one: 'As a gadget guy, I want to view and edit my documents from any device connected to the Internet so that I'm not dependent on any particular device for access.'"

Joan: "Okay, that seems to capture succinctly what the user wants to do, and the overarching value of our suite of cloud storage products. Your concerns are starting to become more concrete for me. Raquel, how do you suggest we modify our agile process to address these concerns?"

Raquel pulls up the following diagram from a Mike Cohn presentation on user stories.


Raquel: "Let's make sure we include real epics in our portfolio and product roadmaps.  Let's decompose epics into user stories and include the user stories in our backlog. When we need to split a user story to fit into an iteration, our first instinct should be to split it by iteratively strengthening the acceptance criteria, not always by decomposing it along functional lines. All development tasks we include in the backlog should reference the user stories they support.  Also, let's follow Mike Cohn's template for epics and user stories to ensure they are understandable to users and are verifiable. We can also group stories according to themes, but let's make sure the themes tie back to prospect problems."

Oscar: "Works for me! I really like the idea of epics standing for lengthy, end-to-end stories. They really tie everything together to show the value to customers and users in such a way that I, as a developer, can see how the details fit into the big picture.  As a matter of fact, I've noticed a recurring pattern we could employ."

Oscar proceeds to draw the following diagram on Joan's whiteboard.


Raquel: "Pretty cool, Oscar. Your diagram shows a decomposition of an epic into smaller stories.  The epic encompasses what the user ultimately wants to do and the unfortunate - but often necessary - system interactions that administrators must perform behind the scenes to enable the true value for end users. You've divided what we would need to implement into chunks our product owner could put in the backlog and our developers could complete in a single iteration. At the same time, none of the individual user stories by itself delivers what the end user needs. The top-level epic captures all of the stories playing out and satisfying the end user's needs."

Joan: "Now that you've explained them, these ideas make a lot of sense to me. We need to make this a team conversation and decision. I will fully support your starting this conversation with the team and proposing your ideas. I suggest a series of 'brown bag' lunches to discuss our process and possible modifications to it. Let's set the expectation that no decisions will be made at these lunches, but through open sharing of ideas and perspectives, we'll naturally converge on some improvements to our processes."  

Wednesday, June 22, 2011

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:
  1. A great leader's effectiveness comes from authority.
  2. Great leaders are largely self-empowered and require little or no help to influence others and be effective.
Some people believe leaders are granted authority.  Other people have a romantic model of a leader as someone who, with little or no help, achieves great things and influences and earns the respect of others.

Both of these notions of leadership are ill conceived.

What is Leadership?

On page 12 of Becoming a Technical Leader: An Organic Problem Solving Approach, Gerald M. Weinberg defined an organic model of leadership:
Leadership is the process of creating an environment in which people become empowered.
A person can lead in many ways – by fostering a shared understanding of problems the group will solve, by organizing and putting supportive structures in place, by motivating others, by stimulating or managing the flow of ideas, and in some cases by acting unilaterally.  In almost every case, the leadership manifests itself in enabling or helping others.

But guess what – leaders also need empowerment. They need help. In fact, one great talent of many leaders is that they know when and whom to ask for help.  Indeed, Weinberg wrote on page 261:
People become leaders thinking they will help other people.  Before long they realize that it's they who need help.  They need help to see themselves as others see them, to carry them through their mistakes, to learn about other people, and to deal with the frustrations of trying to be helpful.  The only way to learn to be helpful is by learning to be helped.
A great leader may appear completely ineffectual in one environment yet masterful in another environment. The difference lies in how supportive and empowering the environment is for the leader.

Product Management Leadership Challenges

The formal authority that most product managers lack may not limit their leadership, but the lack of formal authority often reflects a disempowering environment.

Most people – executives included – don’t fully understand the product management role.  They don't recognize that product managers need to be like therapists to understand markets.  They aren't aware that marketing principles tend to defy common sense.  In a work environment where executives and fellow employees don't understand the role and what it means to be effective in it, product managers receive limited support.

At this point, if you still believe in the romantic model of leadership (the one in which great leaders don't need support from others), you think this description of product managers' situation is just whining.  Why don't product managers just "buck up" and overcome this situation?

To overcome the situation, product managers can attempt to build credibility and educate executives and others around them. But recognize that most product managers are hired into a poorly-defined role, are expected to behave tactically, and are actively discouraged from spending time defining their role and educating others about it.

Indeed, the worst corporate environments actively prevent product managers from realizing their leadership potential.  On page 166 of Leading Change, John P. Kotter wrote:
Highly controlling organizations often destroy leadership by not allowing people to blossom, test themselves, and grow. In stiff bureaucracies, young men and women with potential typically see few good role models, are not encouraged to lead, and may even be punished if they go out of bounds, challenge the status quo, and take risks. These kinds of organizations tend either to repel people with leadership potential or to take those individuals and teach them only about bureaucratic management.
Take note of the last sentence about this type of organization repelling people with leadership potential.  We'll revisit it at the end of this piece.


What to Do?

As an executive, you can empower your product managers by providing them with support.  Support doesn't necessarily mean giving product managers formal authority.  But you can:
  • Encourage (and budget for) your product managers to visit prospective and existing customers, to observe them in their native environments, and to conduct one-on-one interviews with them.
  • Encourage your product managers to share their market knowledge with others throughout the organization.  For example, suggest that a product manager set up a mid-day meeting and have the company provide lunch for everyone who attends.
  • Encourage (and budget for) your product managers to attend training and learn and share best practices in public forums.
  • Let others in the organization know that you believe these activities, and the functions of product management, are important.
For more information on the challenges of creating an organization that empowers its employees and fosters innovation, see this paper by my friend and colleague, Becca Frasier.

Self-Empowerment

Finally, let's consider how product managers can empower themselves.

When a great leader finds herself in a disempowering environment, she changes her environment.

In some cases, she does so by establishing mutually supportive relationships with others, by "speaking truth to power" (making the case to executives for organizational change), by teaching, and by demonstrating competence and building credibility over time.

However, the often-overlooked quality of great leaders is that they quickly recognize disempowering environments, extricate themselves from them, and seek out and place themselves in empowering ones.  People who hold onto the romantic notion of leadership might see such a tactic as cowardly or as a form of avoidance, but it is in many cases the only realistic - and the most empowering - approach.

Sunday, March 20, 2011

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?

Sunday, February 27, 2011

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:
  1. Are product managers innovators or innovation enablers?
  2. What do great product managers do to innovate or foster innovation?
  3. What is the relationship between requirements and innovation?
  4. 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.

Tuesday, January 04, 2011

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:
  1. 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.
  2. 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.
  3. 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:
  1. Base product decisions on market understanding and marketing principles. Teams will not buy in to major product decisions unless they can make a compelling case for them. It's hard to make a smart product decision without understanding the market and the principles of marketing (which are often counter-intuitive).
  2. Involve the team in making product decisions. In the authoritarian model of product management, a product manager becomes an expert on the market, gets input from development on the technical feasibility of implementing new features, and makes unilateral decisions. In the organic model of product management, a product manager leads the process of collective product decision-making and arms the team with the market information and marketing principles necessary to produce quality decisions. A product manager applying the organic approach uses change management and decision facilitation to foster buy-in and to motivate the team to execute.
  3. Iterate on the research and development of products. Product teams will make mistakes. They will never fully understand the impact of product decisions on their customers until the team at least partially executes and tests those decisions in the market. Thus the team will and should revisit decisions. An effective product team leader helps the team confront risks and uncertainty quickly and in a disciplined fashion. Frequent iterations provide a systematic way of learning and of evaluating and revisiting product decisions.
Thanks to Joshua Duncan for helping me to refine my thoughts on the organic model of product management.