Kevin Brennan

Clearly define roles and responsibilities to avoid product team conflict

Product teams, like all teams, tend to move through a series of phases from the time the team is assembled to when the team is executing optimally on the product scope. One model of group development identifies four phases: Forming, Storming, Norming, and Performing.

In the Forming phase, the team comes together to discuss and understand the product project and resulting goals. Mature teams or teams that have already worked together on past projects often move from the Forming phase directly to the Norming and then Performing phases, where the team is operating cohesively toward the overall product goals. However, the team often passes through a Storming phase where friction and conflict arise.

One common source of conflict is misunderstanding about the roles and responsibilities of the product team members. Spending time when the team is formed, or when there’s a personnel change, to have a discussion on the different roles, who does what, and the expectation that each role has of the other roles will go a long way toward eliminating this source of team conflict.

Common technology product team members often include a Product Manager, a Program or Project Manager, an Engineering Lead, and a UX or Design Lead. Each role should identify what they see as their responsibilities to the team and also their expectations of what the other roles will do and deliver. For example, the Product Manager may include the following as key responsibilities of the Product role:

  • Is an expert on the market, including customers and competitors
  • Has ultimate responsibility for the business success of the product in the market
  • Owns the creation and execution of the product strategy
  • Owns the product roadmap
  • Defines the product requirements
  • Sets pricing
  • Monitors and manages the program P&L and return on investment
  • Is the final decision maker on product scope and schedule

The Product Manager may also identify the following in their list of expected responsibilities and deliverables for the Engineering Lead role:

  • Specifies, develops, tests, and releases the product
  • Defines the technology and architectural strategy for the product
  • Translates product requirements from the Product Manager into technical specifications
  • Creates and owns the engineering plan

The other roles would likewise identify the key responsibilities of their role and their expectations of the other roles. Having an open discussion on each role works to identify areas of alignment and, importantly, misalignment, which can then be resolved.

The final area the team should identify is the responsibilities that exist at the collective level and are no one role’s responsibility. This can include items such as monitoring for where ownership is unclear or identifying capacity deficits and working together to resolve those.

Read more about product teams and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Five best practices for sharing product roadmaps

A product roadmap is a visual tool to summarize a product offering over time. A roadmap is most often used internally, for example, when working on project planning. However, there are times when a product roadmap needs to be reviewed with entities outside your company, for example, when pitching a future version of a product with a prospective customer. Be extra careful when reviewing what is primarily an internal tool with people outside your company. Here are five best practices for sharing product roadmaps externally.

  1. Remove all sensitive data such as features that are not being disclosed, project cost information, staff names, and competitor references.
  2. Include a prominent disclaimer to note that the roadmap is not a commitment and is subject to change. It is critical that external parties are aware that while the roadmap is an expression of intent, it is not a committed plan. Setting the right expectations is critical to avoiding disappointment if a plan changes in the future.
  3. Use project code names to obfuscate the product or brand name in case the roadmap ends up in the hands of competitors or others outside of the intended audience.
  4. Consider creating two versions: The version that is presented and a “leave behind” version that further removes sensitive data. Sometimes it’s acceptable to present certain information verbally but leave that undocumented.
  5. Use a secure .PDF or another non-changeable format. If sharing the roadmap under a non-disclosure agreement, note that and include the name of the external partner on the roadmap.

Read more about roadmaps and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Not all product features are created equal

Products and services are often made up of a collection of features and benefits that combine to deliver the full value of the offering. Some features are bare essentials and represent the “price of entry” for customer consideration. Other features make up the core of the product value proposition and are the focus for customers when deciding to buy. Understanding how a feature is perceived by customers is the key to successfully defining a new product or service and optimally managing scarce product team time and resources.

A tremendously useful paradigm for evaluating product features is the Kano Model. Features are categorized based on how satisfied the customer would be with a given feature (ranging from “frustrated” to “delighted”) based on the level of implementation of the feature (from “absent” to “fully implemented” ). The resulting five categories are:

  1. “Must-Have” features are expected by the customer. Although these features will not make a customer satisfied with the overall product, excluding them creates dissatisfaction. Continuing to invest in Must-Have features beyond the customer’s expected level of performance is pointless as it does not increase satisfaction.
  2. “Satisfiers” are features that provide a satisfaction level that increases linearly with the given level of functionality (for example, higher pages per minute throughput on a laser printer or more processor cores on a PC). These are typically the core features that the product competes on. Choose the right Satisfiers and the right level of implementation given how the product will compete in the market.
  3. “Delighters” are unexpected features that have a disproportionately high impact on customer satisfaction given the level of investment. Strive to have one to two Delighters in the product to create customer delight and positive differentiation.
  4. “Indifferent” features are ones that the customer doesn’t care about. Eliminate these since they have no impact on customer satisfaction.
  5. “Reverse” features are the opposite of Satisfiers in that the more that are added, the more dissatisfied the customer will be. It’s important to monitor new features to ensure they are not, in fact, Reverse features, and if they are, to remove them.

When considering a new product or service, gather feedback from target customers on potential new features and attributes. Start by eliminating any features that fall into the Indifferent or Reverse categories. Include Must-Have features but only develop them to the customer’s expected level of performance. Build the overall feature set primarily on Satisfiers, the key three to five features the product will compete on in the market. Finally, include one to two Delighters to create customer delight.

Recognize that value changes over time. What was a Satisfier in a prior version of a product may now be a Must-Have feature as customers’ expectations evolve. When planning a new version of an existing product, re-evaluate all features to see if their classification has changed.

Read more about feature prioritization and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.