Prioritization Requires Strategy

Richard Mironov -

I just spent a couple of hours with a mentee, newly promoted to Director of Product Management at a company building enterprise IoT solutions (hardware+software+cloud aggregation) and now responsible for 3 product managers. She finds herself in a very typical situation:

  • The development teams are doing week-to-week prioritization, but there’s no clear quarterly roadmap
  • There are lots of projects underway, but not one major theme. It’s hard to get a handle on what’s being worked on, or when things will finish.
  • The CEO wonders out loud if development is being productive, and can’t map technical activity to business outcomes

The company needs to scale up a lot to gain share, reach break-even, and meet Board commitments. Scaling up is a business goal, however, and of little help deciding where to focus technical effort.

WHAT TO DO?

Our Director’s first order of business is identifying major blockers to growth and the implied product improvements. Poking around, she has heard about (and thoughtfully clarified) various theories about product-related issues:

  • Deployability. The units are complex, shipped in pieces, and need some site survey work. If they could simplify the installation process and give the field team better planning tools, the field team would speed up deployments.
  • Pure cost. IoT prices in their solution space are falling, and deals are being won/lost on the financials. Reducing product costs by 25% or more will close some mega-deals.
  • Hardware/software reliability. Components fail too often, sometimes on arrival, and software bugs sporadically decrease output. They need to invest in manufacturing quality and automated software testing.
  • Cloud scaling. Their dashboards and control algorithms were designed for a few hundred deployed units. Thousands more are in active proposals, and will be hard to manage once installed.
  • Etc.

Our Director assumes there will be some executive-level disagreements and mis-attribution of what’s broken. The Field Engineering Director’s team struggles through deployments, and sees only those issues. Sales is most sensitive to margin, cost and deal pricing. Operations folks stare at the inadequate web portal all day. Each stakeholder group tends to focus on its own local concerns.

But without some force-ranking among these top-level issues, the development organization can’t prioritize stories or work. There is no natural prioritization of development work without an underlying strategy.

So our intrepid Director of Product Management has to drive discussion and agreement among business and technical heads. She must get them to accept a specific rank-order among the issues and a specific allocation of resources. She correctly frames this as “how should we ask Development to spend our precious story points?”

It’s almost always wrong to assign 100% of a development organization’s effort for an extended period against one narrow item. (For instance, focusing this quarter only on back-end software scaling, while ignoring all bugs and all other feature requests and all UI fixes.)  Our clever Director positions this instead as an allocation problem: what portion of effort should we spend on deployability? Software reliability improvements?

She’ll have to get the handful of executive stakeholders in a room together, and force a discussion about explicit trade-offs among their top issues.

“If we split our effort equally among 4 or 5 issues, we won’t make much progress on any. So we have to agree on which is most important, and what portion of overall development effort this quarter to stack against it. Are we 70% deployability and 20% cost reduction, deferring all of the software scaling work? Or 60% cloud scaling and 30% hardware reliability? We can’t assign more than 100%, so this forces us to make EXCLUSIVE OR choices rather than sign up for everything.”

Imagine a lot of whiteboarding with charts like these:

Also, she expects the CEO to grumble about technical throughput or efficiency. (“If the development team worked harder / smarter, we’d get all of this done.” Or “Agile is supposed to give us twice the velocity.”)  She’ll try to avoid getting sidetracked, since this is magical thinking: that somehow, we can have everything on our wish list by assuming more engineering capacity. In the history of technology companies, there’s never been a development team big enough to fulfill all of the dreams of executives. Regardless of velocity, we still have to make hard choices every quarter about what to do.

Eventually, our intrepid Director of Product Management wrestles some agreement into place. It actually looks like this

because there are some work categories that are internal to development, and which she doesn’t invite executives to trade away. (For example, Sales always wants to postpone automated testing “for just this quarter” in favor of some deal-driven feature. Sometimes, we have to protect people from themselves.)

CAN WE TALK WITH OUR TECHIES YET?

Finally, she is ready for some productive prioritization and backlog grooming with Development. Humbly, she engages engineering peers and her product managers in a semi-structured way:

“We have about 1000 story points to spend this quarter across all projects. The top business priority is Deployability, defined as shortening time and reducing costs to install our next few hundred units. If we had 600 story points to spend on this, how would we do it? Where are the wins and leverage points? What could we deliver this quarter (or this week) for meaningful improvement?”

It’s crucial to note that a different weighting of top-level goals will necessarily lead to different selections of user stories and technical work. There’s no strategy-independent scoring system or a priori value tied to individual work items.

Maybe the Deployability work is much easier, and our Director gets to use some of her valuable story points to use elsewhere. Maybe it’s super-difficult, with no improvement possible on such a small budget, and she has to revisit priorities. Most likely, this is a great way to focus and engage the development team: giving them freedom to creatively address a well-framed problem. And an easier discussion about projects that don’t support any key themes.

By the way, this model also provides some good delegation opportunities. If there are 100 story points to spend during the quarter on quality improvements or testing infrastructure, our savvy Director could trust QA to allocate those points against whatever projects they think have the best Quality ROI. After all, there will be another 100 points to spend on quality next quarter.

Summarizing our smart Director’s approach:

  1. Identify business issues with direct impact on revenue/customers
  2. Create a portfolio allocation: force-rank issues and relative effort, avoiding demand to “do everything right away”
  3. Collaborate with Development on how best to spend against priorities
  4. Adjust, adapt, repeat. Build trust among executives that development work is actually aligned with business priorities.  Build trust among the techies that execs will interfere less.

I’ve applied these tools to individual products, product portfolios, and marketing-side improvements. The essential step is forcing trade-offs among desired investments: we have to be specific enough to make hard choices, and patient enough to let reap the rewards.

SOUND BYTE

Prioritization happens in a context. If we’re having trouble deciding what’s most important, we may be failing to make (hard) strategic choices among the many opportunities in front of us.