Why (Agile) Program Management Tools Don’t Help (Agile) Product Managers

Agile development teams need tools for tracking the creation of software. There are dozens of well-known, purpose-built offerings including Jira, Rally, Pivotal Tracker, Mingle, VersionOne, ScrumWorks, Trello, TFS and AxoSoft.  These are agile project/program management tools.

Product managers at commercial software companies are tempted to use these same tools for core product management activities. It would seem obvious: our development teams are already using Jira or Rally or Pivotal, our backlogs and stories have to end up there anyway, and adding a few more users is no problem.

But I’ve found – as other agile product managers have – that project/program applications are badly suited to most of what we do. Great tools, wrong job. Hammers vs. screwdrivers.

Program management tools need the OUTPUT of a good product management process. Our development teams need us to deliver finished product strategies, groomed backlogs, unambiguous roadmaps. Believable revenue forecasts. Well-segmented market segments. Traded-off trade-offs. Bought-in executives. Market-viable product plans.

Said another way, engineering is about building one specific vision of the future; product management is about choosing from among many possible futures.

I’m excited to see a new generation of product-management-specific tools emerging to fill the gap. Jeff Lash and team at SiriusDecisions provide value here: their Field Guide to Product Planning, Prioritization and Roadmapping Apps lists eleven product-focused offerings: Accompa, Aha!, InnovateNow, Jama, OneDesk, ProdPad, ProductPlan, Reqqs, SensorSix, TrendRadius and Wizeline. Undoubtedly there are more. And most of these tools export to Jira/Rally/etc, letting them connect into the program management cycle.

Let’s disassemble the problem a bit.

Almost every agile/scrum discussion starts with formation of a cross-functional team to build a product (or complete a project). By definition, the team is assigned a general problem, target audience, proposed solution, rough estimate of customer value, and intended delivery timeline. They may get a starter backlog of stories, epics and features.

If this is a new product, a product manager (or someone) should have done some critical market-side work before we commit a team:

• Validated that a market exists for this new product, that sufficient prospects are willing to pay for a solution (product/market fit) and our thumbnail financials make sense
• Picked one segment as our market entry point, and matched that to the right benefits, feature sets, price points and channels
• Refereed some executive-level wrestling matches about funding this product versus ten competing proposals. (In public, we pretend the process is entirely objective. In private, we’ll admit that revenue forecasts and cost estimates are notoriously inaccurate, and getting buy-in to product plans is highly political.)
• Rationalized the size of the development team against likely direct revenue or pull-through on other products. Large companies typically need $1M/year in forecast revenue for every member of the development team.

In other words, much of the success/failure of a product has been determined before we hire our first developer or fill out our first story card. No amount of excellent code will change a weak idea into a good one. An extra month spent on market validation and product pre-planning might save 20 developer-years.

So a useful product management tool would help us make difficult EXCLUSIVE OR decisions about which products and features to move to the front of our roadmap and how to balance competing initiative. It would help us compare dozens of attractive products/features against each other. It would support distinct categories of investment – from speculative Horizon 3 investigations to low-risk improvements to CEO-level commitments for strategic customers – since a single value metric will never fit our multi-dimensional problem.

A good product tool would help us track information about:

• How many customers have asked for a product/feature, who are they, when did they ask, was it a deal-breaker, whether the request is still relevant. A CRM/ERP link might be handy.
• Sales forecasts, projected renewal rates and market share predictions. We’ll want to attach complex forecasting models to some product ideas. Error bars are important, since enterprise account teams have been known to exaggerate by 10x or more.
• Recent competitor announcements about products/features, price points and pricing units, partnerships
• Which features are Kano Exciters/Delighters, linear performance items, or mandatory/baseline. Timing matters, since exciters quickly degrade into mandatories in competitive markets.
• If this product contributes to revenue from other products (and how).
• How we see the trade-off between feature completeness and quality in this segment. Are we early enough that customers will put up with problems to get our hot new thing?
• Any cross-product investments we must make, for instance platform support or portfolio-wide UX restructuring.

Notice that most of this is semi-structured, semi-quantitative, and heavily dependent on the situation. Product managers apply tons of personal judgment when sifting through such noisy data. A good product management tool would let us play with changes to content or priority, and then commit only those changes we want to implement.

The agile community has spent a lot of energy finding ways to reduce waste and improve velocity within the development process. I’d love them to hold us product managers up to some of the same scrutiny, since there’s nothing more wasteful than brilliantly engineering a product that doesn’t sell.

Some questions I’d like to hear development teams raise more often:

“How did you decide that was the best strategy?”
“Show us the market evidence that large numbers of prospects will pay for this.”
“Why are we shuffling the roadmap for a feature that only one big customer will use?”
“Those two corporate objectives are in direct opposition. How much emphasis/investment should we put on each side?”

At the same time, I’d be asking for some forbearance, because product strategy is (at best) semi-quantitative and our tools don’t deliver much fidelity. Because as Yogi Berra reminded us, “It’s tough to make predictions, especially about the future.” Forecasting market reactions is even more error-prone than forecasting development cycles.

Sound Byte

Product management work is an essential input to the development process. Program management tools aren’t necessarily a good fit for front-end product/market planning.

A note for start-ups: I’ve described a big company process above. Startups can get there faster. IMHO, though, the essential point is the same: your development team is the most valuable commodity in the universe. Do as much market validation homework as you can before starting them on building anything, because that’s when your funding clock sweeps ahead ten times as fast. You can keep everything on PostIt notes for the first few quarters, though, and not necessarily invest in any commercial planning tools.