Strategically Clogged Backlogs

Among the urgent calls from software teams to me for interim product leadership is a variety that I call “systemic product failure” or “strategically clogged backlog.” I dealt with this twice in 2011, so it’s worth describing for other product folks: sh*t isn’t getting done, product managers are drowning (or have been let go), and engineering is dangerously disconnected from internal stakeholders and customers. Software isn’t shipping, and backlogs are growing. This may not look like a product management breakdown, but it really is… and identifying its organizational/structural roots is key to turning the situation around.
If you’re moving to a new product team within your company, or joining a new company that lacks strong product management, watch for systemic backlog failure. You’ll want a contingency plan for your first few weeks: understanding your new team’s challenges, demonstrating early wins, and rebuilding trust in a sustainable process.

What are the symptoms?

Generalizing wildly, and overstating for clarity, here are ways to spot a systemic backlog failure:

Marketing, Sales, and Executives are very frustrated that nothing seems to be coming out of Engineering. Everyone has examples of items that have been talked about for months, don’t seem to get done, and “should be easy.”
Engineering is very frustrated by a lack of priorities, clear specs/requirements, and inability of Marketing/Sales/Executives to appreciate the things that are getting done. It’s increasingly impossible to make progress on the strategic agenda due to a high volume of small (tactical) interruptions.
Since the backlog process is broken, Sales and Marketing managers lobby individual engineers: each pushing for their items to jump the queue. (This makes the interrupt problem worse and politicizes the results.)
Customer Support gives up, and stops demanding urgently needed fixes.
Seeing the chaos, executives focus on hot items escalated by their staffs. Each exec’s list is a mix of strategic and tactical; insightful and irrelevant; tiny and boil-the-ocean-OMG-huge.
Engineering starts to ignore all other inputs, and resentfully works through the easy items on some senior exec’s punch list.

Of course the real losers here are the customers and the investors. Their patience is wearing thin, and they both see better places to put their money.
People issues aren’t solved by opening tickets

Your stakeholders are understandably emotional. They lack trust (“my things won’t get done”) and commitments (“when will we have it?”) and a clear process (“how can I know that my items are in the queue and seriously considered?”)

Your engineers are emotional (if you listen closely) because they hate endless negotiations over priorities, inventing business justifications, mollifying stakeholders, and talking up their own accomplishments. Technical types do their best work with clear goals and a mostly-stable mix of short-term and long-term problems. They really want to get sh*t done.

Sound familiar? I’ve seen dozens of tech firms in this particular pickle. Since backlog failure is so pervasive, you can’t just quit and hope your next company is better. You need to know how to fix it.
What to do in your first 30 days?

Remind yourself that this is a people issue as well as a process problem. Announcing a new workflow or document template won’t (by itself) change attitudes or build trust. So…

Meet everyone as quickly as possible. Introduce yourself, listen, and capture each person’s issues. Don’t promise – yet – to fix any specific issue, since you don’t yet understand resources, priorities, problems, or how long improvements take.
Own the backlog, especially if it’s a mess. Consolidate all the requests into a single list with a single priority. Add every suggestion to the list, and start sifting. Learn the vocabulary. Insist that stakeholders come to you, rather than to Engineering, even though you won’t have any useful answers for a week or two. Diverting the interrupt stream to your own temporary holding pond – and away from developers – will instantly boost Engineering productivity and morale.
Practice phrases like “I don’t know yet, but I’ll look into it,” “I think this is the backlog item you mentioned before,” and “Yes, that seems like a small thing. There may be technical/architectural dependencies, though, so let me ask the engineers.”

Cherry pick a few small wins from your messy backlog. Look for improvements that are truly small, well spec’d, customer visible, and low risk. With an agile development team, aim for a handful of small fixes that can ship within two weeks. You’re not trying to optimize customer value; instead, you’re building credibility and buying time for more substantial changes.

Give your engineering team some internal PR. As soon as #3 is done, send around a brief “here’s what engineering just completed” email. Remember you’ve got twin battles: actual delivery problems and perceptions of delivery problems. Publicizing progress is almost as important as the progress itself.
Start studying your product and segment. This is a long-term effort, but you need to sound cogent within a few weeks. A tough balancing act: you’ll initially be spending 80% of your time on inward-facing execution, with a shift to 50% outward market-sensing within a month.
Start sizing up the people and organizations, but assume that everyone is trying to do a good job and cares about the company. Don’t pick sides (or fights) based on first impressions. Look for organizational conflicts rather than personality defects.

IMO, a seasoned product manager can repair a broken backlog in four or five weeks. It may take another month for the broader organization to notice the improvement.

Notice that I haven’t mentioned “strategy” or “vision” or “roles” yet. After a month, you’ve tamed the backlog, gotten a sense of your technical team, and won over a few stakeholders. You’ve talked with some customers/prospects and are forming opinions. You’ve identified staffing gaps.

In Months Two and Three, you’re ready to attack the next level of product issues: roadmaps, target markets, messaging, competition, pricing and business models, technical evolution. Along with some specific product knowledge.

Sound Byte

Backlog failure is a mix of actual productivity, perceptions, unclear priorities, and broken processes. Product managers need to address both the facts and the emotions by generating quick wins and helping shift opinions. That buys time to work on more strategic issues.