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

You have to waitYour 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…

  1. 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.
  2. 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.”
  3. Getting Sh*t Done

    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.

  4. 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.
  5. 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.
  6. 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.

  • Dan Callahan Reply

    Great insights, Rich. As you’ve pointed out, evidence of people “winging
    it” and creating their own ways of getting sh*t done indicates that the
    underlying methods are broken… or never existed. Demonstrating that
    you’re listening to stakeholders (without immediately agreeing to do what
    they want) and delivering (and talking about) some “quick wins” will take a
    lot of pressure off the situation.

    What I’d add is that you have to drive it through to conclusion, which for
    the Product Manager means: (1) a single backlog list; (2) a way of choosing
    what backlog items will be worked next time; (3) evidence that stakeholders
    understand and respect that method.


  • Girish Reply

    Yet another classic Rich!

  • Scott Sehlhorst Reply

    It’s hard to remember we’re here to drain the swamp when we’re busy fighting off alligators.

    So many teams get lost in “the urgent” that they never get around to “the important,” and much of the advice I and others give is around making sure “the important” gets its due. This is a great article to remind us that sometimes “urgent” is truly “urgent” and not just “loud.”

    Thanks Rich!

  • Roger L. Cauvin Reply

    One big mistake I see product managers and owners committing is failing to
    provide context and the user point of view. Many of them never define epics
    (placeholders for large, end-to-end narratives that cut across many
    stories). If they do define them, they in many cases treat them as “large
    features” or categories thereof. In so doing, they fail to anchor the
    specifications in the backlog to the user point of view.

  • Geoffrey Anderson Reply

    I have to remind myself to circle back and read your blog. This is absolutely on target, and typical of every job I have started. In fact, often the clogged backlog is the spark that product management is needed at a company.

    Excellent suggestions on how to attack, and I particularly like the emphasis on meeting the stakeholders, and the PR for the engineering team. I have watched non-stop “beating” of the engineering team by other departments, and have done a lot of celebrating the small victories. It is amazing how that both helps morale in engineering, and begins to re-establish credibility within the other organizations.

    Might I add that getting the leads of the engineers out for pizza and beer in that first month will also go a long way to building the bridges and relationships you need to be successful. (or whatever off site group gathering where you can let your hair down).

    A former colleague just made the jump to Product Management, and her first plea for help was advice on how to deal with just this.

    And never forget the power of NO to the constant desire to re-prioritize. Whenever an exec wants his/her pet peeve raised to the top, I break out the backlog, and we figure out what we are going to lower. Usually, the “must have” tactical item can be inserted and prioritized normally without penalty.

    (P.S. the graphics for your book covers the comment entry area enough to be really annoying and almost completely obscures the “post” button).

Add your comment

Your email address will not be published. Required fields are marked *