Product management is responsible for documenting market requirements for development and engineering. Best practice prescribes that these market requirements are about who (the persona), what (the problem), when (frequency or event), and why (the overriding goal), but never how (designs or specs).
But what about business requirements? Just as product management articulates the market’s requirements to engineering and development, they must also communicate the business rationale so that the organization invests in the most promising projects or products.
Creativity vs. Standardization
Many organizations view business requirements management as more art than science in an effort to encourage lean and agile innovation and out-of-the-box thinking. This works well in smaller organizations such as startups. But even as companies scale, standardization of planning documentation and processes are often not implemented, usually because leadership or the organization fears that too much formalization will encourage bureaucracy and slow them down. Also, with vastly different types of projects, success metrics, and planning horizons across a typical organization, many believe that standardized processes do not work. “Doesn’t replacing an aging product architecture vs. building a third-party partnership program demand different types of planning documents and processes?” they think.
Pragmatic Institute teaches that the market-driven product manager should act like the CEO of their product. Company CEOs know that their investors and boards expect standardized updates and metrics—expenses, revenue, profit, risks and future outlook—to explain the overall value provided by the company and why it is a good investment. Similarly, product managers owe it to their organization to communicate standardized value-based information, regardless of the project type, to justify new or continued investment. This includes regular reporting on the progress being made against the original committed plan and any adjustments made to the plan due to changing product or market conditions.
Agile Planning Challenges
After 12 years as a Pragmatic Institute instructor and product management consultant, I’ve identified several key reasons why companies don’t effectively develop or manage their business plans and commitments or implement agile and dynamic business-planning processes.
Lacking the Necessary Skills
Many product managers lack the necessary skills or training to develop quality business-planning data. Though they often have a business degree or have attended professional business-oriented training, concepts like net present value (NPV), EBITDA, competitive strategy, segmentation, KPIs and burdened rate are foreign to them. This lack of experience often means they provide their own interpretation of what information is required in a standard corporate template.
Shifting Focus
The focus of many product lifecycle processes has shifted to product and technology details over business goals and metrics. Backlogs, story mapping, scrums, sprints, and demos dominate much more product management time and attention than strategy, roadmaps, KPIs, and profit.
Inadequate Accountability
Historically, business plans have been static artifacts that are required early in the product lifecycle process, and product teams have often viewed their role as selling the plans to the business. Aggressive financial commitments and schedules are made to get projects funded, and the processes lack a closed-loop way to hold the product teams accountable for their commitments. Schedules slip, scope changes and new competitors enter the market, yet the original business objectives are not modified to reflect these changes.
No Contextual, Fact-Based Documentation
With personnel shifts, promotions and departures, individuals may inherit plans minus the adequate details or context that were the basis for those plans. This lost intellectual property often leaves with the person who developed it. Without contextual, fact-based documentation, the new owners may struggle to understand where the numbers came from and may not have a clue about how the author expected to meet the plan’s objectives.
No Standardized Processes
As organizations scale from lean and nimble startups to multi-product, larger organizations, they often fail to define standardized processes for proposing new projects or making difficult investment priority decisions. This often results in confusion and erratic priorities and decisions.
Overworked Teams
Technology teams and management are often overworked, which tends to result in being more reactionary to crises—the unhappy and loud customer, the product defect, the budget cut, the organizational change—than strategic. Reviewing previously agreed-to business commitments is not usually a top leadership priority, and this often results in major surprises that would have been avoided had they been visible earlier.
Relying on Limited Metrics
Many companies rely on a limited number of standard metrics across all products to gauge success. With a broad range of products across different types of markets, standard metrics usually don’t provide an accurate or fair view of the health of a product’s value. For example, the return on investment may be less important than the net promoter score for existing products, whereas NPV may not be an accurate way to measure an innovative, thought-leadership offering.
Moving to Agile Business Planning
Moving to a dynamic, agile business-planning process follows specific stages, depending on the level of an organization’s planning maturity. By assessing the current state, organizations can implement the right improvements to fit their specific gaps. We find that most product organizations today tend to fit into one of three stages:
Ad hoc
No formal plans or processes have been established, and most planning is reactive or on-demand. As a first step, we recommend a lightweight but standardized planning template to establish consistency between the products and teams. It is important to encourage innovation and agility, but management also needs a standardized way to regularly evaluate multiple investments; common (yet flexible) templates makes this much easier.
Repeatable
Formal processes and planning documents exist, but they are manually developed, non-standard and quickly become out of date. To address this, companies look to automated tools that product managers can use to share their plans and keep data current.
Managed
Standardized plans are regularly reviewed and updated, and product management is held accountable for business commitments and metrics. To achieve this level of maturity, organizations must instill discipline and rigor in how they review and hold teams accountable for their plans. Ideally, managers use automated reporting and analytics based on their teams’ plans that can provide an on-demand snapshot of the overall state of the business.
Dynamic and agile business planning is an area that needs improvement in most technology companies we work with today. Though no one wants to take a big step back to the monolithic days of waterfall development and heavyweight documents and processes, we still need to think of our products like businesses and manage them as such. Business-requirements management is not sexy or fun; it’s not about burndowns, sprints, pigs and chickens, or even closing the next deal. But, being a CEO—whether for the company or the product—demands effective planning and management that keeps pace with the dynamic nature of the business.
