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.

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

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.

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.

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.

“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

Productmanagement 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.