Through decades of consulting for companies such as Apple, Bose, Roche, IBM, and others, we at TCGen Inc. have seen our share of product development snafus. We tend to see many of the same problems across organizations and across industries. Most of them are simple, all of them avoidable, and yet their effects are significant.  

Below are five of the most common product development pitfalls we have seen — and how to avoid them.

1. Lack of a clear product development strategy. 

A clear and well-understood product strategy is a must. Product strategy provides a line of sight between your “true north” as a company, and what you’re developing in your product programs. Yet, in too many companies we find teams still working on ideas that aren’t as tied in with company strategy as they could be. Both dev teams and the functions (Marketing, Engineering, Finance, etc.) must understand corporate strategy and how their work fits into its priorities.

Too many companies hide the strategy in a drawer. Executives treat it as top secret, when it should be known to everyone including individual contributors. When product development strategy is divorced from the day-to-day work it often leaves team members wondering “is my work relevant?”

A solution is to have a clearly communicated and simple strategic plan. This plan should be communicated throughout the organization and accessible to all. It should include:

• A Vision: a broad statement of where you’d like your company to be in three to five years.

• A Strategy document: the steps you intend to take to achieve that vision over a two to three year horizon.
• Product and technology roadmaps, priorities and budgets, connected to specific programs that realize the strategy.

Individual programs should be able to see where they connect to the strategy and the vision. Getting this big picture right is a key to a coherent strategy and coherent brands that resonate in the marketplace.

2. Poor product definition.

Poor product definition is one of the most common pitfalls we see. In too many cases, we find that the dev team doesn’t know what to build. The Product Owner hasn’t been clear about product requirements, and often requirements aren’t sufficiently rooted in customer feedback. Communication between inbound marketing and the dev team is not always clear and efficient, often with the two speaking different languages.

One solution is to clearly identify customer segments. Make sure you get direct qualitative feedback from them. Integrate these customer research activities into the dev team. Ideally, have team members participate and not just the dedicated Marketing person. 

Next, prioritize the qualitative feedback. Transform this qualitative data into requirements expressed quantitatively. For example, if customers reviewing an audio electronics product report “there’s too much hum” quantify how much is “too much.” There’s a point where the signal-to-noise ratio is optimized and engineers don’t need to exceed it. Create a threshold for the amount of allowable perceived “hum” and make this a part of your product definition.  

Finally, it is up to the Product Owner on the team to make clear what are the “need to haves” for each product. In our audio product example, suppose engineers attempted to reduce noise levels below the perception of human hearing. That’s not a “need to have.”

Any product will have many customer requirements – only a few make a difference in terms of competitive advantage. Have a prioritized list of features and requirements and refer to it early and often. 

3. Project oversight fails to add value and slows decision-making.

Reviews of your team’s progress are inevitable, when your company is getting ready to commit to significant investment or facing a major release. But too often reviews turn into senior management meddling that does little good. Many reviews are inappropriately long, too detailed, and add little value. Teams that are on the right track are forced to deliver lengthy justifications for their continued existence in order to satisfy Management’s desire for control. 

Sometimes the opposite occurs. Rather than meddling too much, senior teams get distracted and neglect teams that require direction, need more resources to hit their targets, or face some other problem that only senior managers can solve. (This often happens when the VP of Marketing or Sales is travelling or out of the office.) This slows decision-making, creating costly delays.

To avoid this pitfall, have few, but logically justified, checkpoints. Establish a few critical parameters for the project and the product at the very beginning. We call these parameters a project’s boundary conditions. Boundary conditions define the key metrics that the team wants to hit with respect to features, product and project cost, quality, timing, or other success factors. If the team perceives, as it works, that it’s on target with these key metrics, the management team should leave them alone.

If the team foresees that it will violate one or more of the boundary conditions, then it requires a fast escalation process to let the senior team know so they can help put the project back on track. In our escalation process, a team that has crossed a boundary condition must a) inform the senior team immediately and b) propose a solution. If the senior team agrees with the solution, then it informs the team via e-mail or Slack, without lengthy analyses of what went wrong. The important thing is to get the team back on track in hours or days, not weeks. 

If the management team does not agree with the team’s solution, then a meeting is called to discuss how to solve the boundary break, or change the boundary condition in question. We’ve called this meeting an out-of-bounds (OOB) review (see flow diagram below). Once the dev team and senior managers agree, the new boundary condition is established and the team continues on this basis.

4. Projects are under resourced leading to functional bottlenecks.

We see too many products that are under resourced. Project managers have too many projects on their plate, while teams lack key skills. Product Owners are also stretched and too often communication between them and the dev team is sub-optimized, leading to poor product definition. 

Also, make sure you have adequate dedicated skills on the team. Have a maximum of only two projects per Product Owner, Scrum Master, Project Manager or Program Manager. Efficiency and quality fall off when these managers have more than two projects on their desk. Our experience finds that the bottleneck often occurs with these roles. Where there is joint development with outside partners, we find bottlenecks in Legal as well. 

The ultimate solution to this pitfall is simple: don’t bite off more than you can chew. What’s worth doing is worth doing right, and you need sufficient skilled players to do development right. Skimping and getting by, while driving Program Managers into the ground, is an all too frequent occurrence. It leads to burnout, turnover, and hurts the company in the long term. 

5. Unclear roles and responsibilities.

Who does what? It’s a basic question. Yet you’d be surprised how many organizations don’t have that question answered. Too many times, it is unclear to teams who is responsible for which deliverable. 

Project managers should be responsible for the how and when related to product development, while Product Managers are responsible for the why and what. But beyond these broad definitions, many teams don’t have clearly defined work streams and deliverables, with someone’s name written next to each. Or more than one person has the idea that he or she is responsible, leading to redundant work and confusion. 

Even where the team itself is clear on roles and responsibilities, we have seen cases where these roles are not communicated to the functional groups or to partners.

The solution is to define roles and responsibilities at the beginning of the project. Document them. Make the tasks more granular than you expect, by dividing broader tasks into smaller, bite-sized activities. Have one and only one Directly Responsible Individual for each and every deliverable. We have used a modified version of the RACI diagram (below) that helps keep everything straight. It also helps to have a communication map that clarifies who speaks for the team, who talks to partners and executives, etc.

Avoiding the pitfalls

It’s frustrating to see the same mistakes repeated over and over, especially when they are avoidable. Many of the pitfalls above can be avoided without onerous post-mortems, lengthy change management initiatives, or expensive IT buys. They are basic to human beings and the vagaries of how we communicate — or fail to do so.