Focus Versus Agility in Business, Product Management and Product Development
Two of the most common statements we hear from our clients are:
Business: “Our product and engineering teams lack the agility to quickly pivot to the needs of the business”.
Product and Engineering: “Our business lacks the focus and discipline to complete any initiative. We are subject to the ‘Bright Shiny Object (BSO’ or ‘Squirrel!’ phenomenon”.
These two teams seem to be at an impasse in perspective requiring a change by one team or the other for the company to be successful.
Companies need both focus and agility to be successful. While these two concepts may appear to be in conflict, a team need only three things to break the apparent deadlock:
- Shared Context.
- Shared agreement as to the meaning of some key terms.
- Three process approaches across product, the business, and engineering.
First, let’s discuss a common context within which successful businesses in competitive environments operate. Second, we’ll define a common set of terms that should be agreed upon by both the business and engineering. Finally, we’ll dig into the approaches necessary to be successful.
Successful businesses operating within interesting industries attract competition. Competitors seek innovative approaches to disrupt each other and gain market share within the industry. Time to market (TTM) in such an environment is critical, as the company that finds an approach (feature, product, etc.) to shift or gain market share has a compelling advantage for some period. As such, any business in a growth industry must be able to move and pivot quickly (be agile) within its product development initiatives. Put another way, businesses that can afford to stick to a dedicated plan likely are not in a competitive or growing segment, probably don’t have competition, and aren’t likely attractive to investors or employees.
The focus that matters within business is a focus on outcomes. Why focus on outcomes instead of the path to achieve them? Focusing on a path implies a static path, and when is the last time you saw a static path be successful? (Hint: most of us have never seen a static path be successful). Obviously, sometimes outcomes need to change, and we need a process by which we change desired outcomes. But outcomes should change much less frequently than path.
Agility enables changing directions (paths) to achieve focused outcomes. ‘Nuff said.
Commonly known as (O)bjectives and (K)ey (Results), or in AKF parlance Outcomes and Key Results, OKRs are the primary mechanism of focus while allowing for some level of agility in changing outcomes for business needs. Consider the O (objectives or outcomes) as the thing upon which a company is focused, and the Key Results as the activities to achieve those outcomes. KRs should change more frequently than the Os as companies attempt to define better activities to achieve the desired outcomes. An objective/outcome could be “Improve Add-To-Cart/Search ratio by 10%”.
Each objective/outcome should have 3 to 5 supporting activities. For the add-to-cart example above, the activities may implement personalization to drive 3% improvement, add re-targeting for a net 4% improvement, and improve descriptive meta-tags in search for a 3% improvement.
OKRs help enforce transparency across the organization and help create the causal roadmap to success. Subordinate organizations understand how their initiatives nest into the high-level company objectives by following the OKR “tree” from leave to root. By adhering to a strict and small number of high-level objectives, the company creates focus. When tradeoffs must happen, activities not aligned with high level objectives get deprioritized or deferred.
Geoffrey Moore outlines an approach for product organizations to stay focused in their product development efforts. When combined with the notion of a Minimum Viable Product the approach is to stay focused on a single product, initially small, focused on the needs of the pioneers within the technology adoption lifecycle (TALC) for a single target market or industry.
The single product for a single industry (P1T1) or need is the headpin of the bowling alley. The company maintains focus on this until such time as they gain significant adoption within the TALC – ideally a beachhead in the early majority of the TALC.
Only after significant adoption through the TALC (above) does the company then introduce the existing product to target market 2 (P1T2) and begin work on product 2 (or significant extension of product 1) in target market 1 (P2T1).
While OKRs and the Bowling Alley help create focus, Agile product methodologies help product and engineering teams maintain flexibility and agility in development. Epics and stories map to key results within the OKR framework. Short duration development cycles help limit the loss in effort associated with changing key results and help to provide feedback as to whether the current path is likely to meet the objectives and key results within OKRs. Backlogs visible to any Agile team are deep enough to allow for grooming and sizing, but shallow enough such that churn and the resulting morale impact do not jeopardize the velocity of development teams.
Putting it all together:
There is no discrepancy between agility and focus if you:
- Agree to shared definitions of both agility and focus per above
- Jointly agree that both agility and focus are necessary
- Implement OKRs to aid with both agility and focus
- Employ an Agile methodology for product and product development
- Use the TALC in your product management efforts and to help enforce focus on winning markets