Skip to content
Browse
BABOK Guide
BABOK Guide
10. Techniques
Introduction 10.1 Acceptance and Evaluation Criteria 10.2 Backlog Management 10.3 Balanced Scorecard 10.4 Benchmarking and Market Analysis 10.5 Brainstorming 10.6 Business Capability Analysis 10.7 Business Cases 10.8 Business Model Canvas 10.9 Business Rules Analysis 10.10 Collaborative Games 10.11 Concept Modelling 10.12 Data Dictionary 10.13 Data Flow Diagrams 10.14 Data Mining 10.15 Data Modelling 10.16 Decision Analysis 10.17 Decision Modelling 10.18 Document Analysis 10.19 Estimation 10.20 Financial Analysis 10.21 Focus Groups 10.22 Functional Decomposition 10.23 Glossary 10.24 Interface Analysis 10.25 Interviews 10.26 Item Tracking 10.27 Lessons Learned 10.28 Metrics and Key Performance Indicators (KPIs) 10.29 Mind Mapping 10.30 Non-Functional Requirements Analysis 10.31 Observation 10.32 Organizational Modelling 10.33 Prioritization 10.34 Process Analysis 10.35 Process Modelling 10.36 Prototyping 10.37 Reviews 10.38 Risk Analysis and Management 10.39 Roles and Permissions Matrix 10.40 Root Cause Analysis 10.41 Scope Modelling 10.42 Sequence Diagrams 10.43 Stakeholder List, Map, or Personas 10.44 State Modelling 10.45 Survey or Questionnaire 10.46 SWOT Analysis 10.47 Use Cases and Scenarios 10.48 User Stories 10.49 Vendor Assessment 10.50 Workshops

5.4 Make an Impact

5.4.2 Advance Strategy

Guide to Product Ownership Analysis

Effective POA focuses on product delivery, accelerating teamwork, and advancing strategy.

The Strategy Horizon (Agile Extension):

Value is created at the Strategy Horizon through understanding and achieving the business' goals. Business goals change; consumer tastes change; competitors create disruptive technology; regulations change. At the Strategy Horizon, the priority of business goals is continually reassessed and emerging opportunities evaluated.

Effective POA requires navigating the broad view of product alignment while advancing organizational strategy with a detailed view of the product backlog to deliver the product customers love. A value-focused mindset guides the team to align customers and the organization.

POA Practitioners create opportunities to engage the team in understanding strategic value to complement their understanding of customer value.

Effective POA focuses on communication, collaboration, and continuous improvement to ensure strategic alignment as the product evolves.

POA influences and is influenced by:
  • Product strategy,
  • Initiative cross-integration, and
  • Organizational support.
Agile mindsets introduce a change from the traditional viewpoint of how these components advance strategy, including how they are planned and measured.
Product strategy largely involves the roadmap of a product. Agile product strategy introduces a dynamic iterative approach where learning and empirical evidence guide the strategy. The Product vision guides development of the initial strategy with built-in refinement cycles that consider customer feedback, market positioning, value proposition, and organizational goals. Unlike traditional product strategy that takes months of detailed analysis, requirement documentation, and planning, agile product strategy minimizes the risk of failure by focusing on fast learning, continually assessing value, consistently collaborating with stakeholders and customers.

How POA Helps Product Strategy

POA Practitioners work collaboratively with the stakeholders and the team to develop an empirical product strategy with inputs from:
  • The product vision,
  • Product-market fit, and
  • Value proposition.
A Product Roadmap is a communication tool to help individuals visualize the product strategy. It manages the tendency to jump to release planning.

Steering away from traditional product roadmaps that typically show a timeline of features, effective POA focuses the team on:
  • Goals,
  • Benefits, and
  • Demonstrations of value.
Three specific types of roadmaps can be used independently or in combination with one another:
  • Goal Oriented Product Roadmap: Focused on outcomes with success criteria. Product Owners use visuals to clarify a unified picture of what success looks like across stakeholders and the delivery team.
Goal Orient Product Road Map.png
  • Now - Next - Later Product Roadmap: Good communication visual, especially for stakeholders. It poses a challenge if it becomes too feature-focused. Product Owners seek ways to keep it as value and benefit focused as possible.
Now Next Later.png
  • Story Map: While story maps are feature and story focused, they are beneficial at the beginning of new product planning. Story mapping invites opportunities for the team to focus on value by:
    • Starting with customer or user activities,
    • Engaging stakeholders to share in the understanding, and
    • Design solution feature ideas.
Activity Release Grid.png
Product strategy is a driving force for the team to accelerate maximizing product value. Alignment of expectations is essential to stakeholder and customer satisfaction. POA provides insights, techniques and tools that help the team to manage expectations.

POA Techniques for Product Strategy

Agile Extension Techniques
  • Story Mapping: Depict the product flow in the form of stories on a timeline that can be used as a roadmap of the product. Applicable in the delivery horizon for internal team communication.
  • Value Stream Mapping: Analyze the flow of the product features, product workflows or transactions to visually show how value is augmented over time.
BABOK® Guide Techniques
  • Collaborative Games - $100 Test: Participants are asked to spend an imaginary $100 to choose features that are valuable from a customer perspective.
  • Workshops: Discuss, collaborate, and build a shared understanding of the product strategy with stakeholders
Other Techniques
  • Product Roadmap: Goal-Oriented Product Roadmap: Depict product strategy as a succession of goals. It is more appropriate in the initiative horizon for external communication outside the immediate product team.
  • Product Roadmap: Now-Next-Later Product Roadmap: Communicate product strategy in the form of a product roadmap that embeds the agile principle of just enough planning where the Now (near term) is detailed and becomes less granular in the future.
  • Value Proposition Canvas: Ensure the features of the products are aligned to what is valuable to customers. This drives the product strategy.

Case Study: Product Strategy for Project Intake Process - Food Manufacturer
Background
Poultry Plus had some major time-consuming manual workaround intake and approval for new customer projects. The process began when the sales department was contacted by customers who would provide a list of needs for ingredients, manufacturing time constraints, labelling constraints, cost per product, etc. While the customers were innovating to become leaders in pet food production, Poultry Plus' systems were not keeping up with their automation needs. The sales team consulted with Tony, a Product Owner assigned to the IT product development team, and established work on a new project intake process.

Challenge
Tony identified major pain points of the project intake process:
  • The full scope of the customer's needs was not captured in the level of detail required to determine whether they had the capability of meeting the customer's needs.
  • The information was garnered from sales team members in informal conversations with the customers and captured in handwritten notes.
  • Some teams had spreadsheets that they would fill in with the help of the customer.
  • A few well-established customers were sent spreadsheets to fill in on their own.
  • Information was not centralized for ease of analysis.
  • Once the needs were scoped and capability confirmed, there was a great deal of project administration data that had to be loaded manually into disparate product management systems. This consumed a lot of internal work effort to perform and keep in sync.
Management was extremely interested in keeping internal data-entry to a minimum, especially since the customer had the bulk of the data needed at the outset of describing their project needs. They wanted an electronic solution that captured all the data early on but still supported a personal relationship between sales personnel and the customers.

Actions
Tony evaluated the situation and determined that an effective solution could include:
  • Rollout of an online information-collecting form for customers to complete,
  • Eventual growth to a more robust system with connections to other internal systems,
  • Workflows that alerted other departments that had influence and interest in the new customer projects,
  • Rules and other educational information that would benefit the customer, and
  • A front-end for customers to view the progress of their project approval and progress.
Tony developed a product roadmap that began with the development of the simple online customer interface for a first iteration. He arranged the roadmap in a timeline of what to do now, what to do in the next iteration, and what to do later (a Now-Next-Later roadmap) and confirmed with the business that the features were in the right place.

Outcome
Tony focused the team on the first iteration, and they began to write and elaborate user stories to deliver what was needed immediately. The user stories were then prioritized into a story map to drive their development process in delivering small increments of usable functionality frequently. The team enlisted subject matter experts on the business side to verify functions when ready and invited customers to review completed features. The first iteration met the business' initial major pain point and laid the groundwork for future value-added features.

Lessons Learned
There is a temptation to want to deliver a fully featured solution, but sometimes there is a larger, over-arching problem that can be solved with a smaller solution that can be built upon. In this case, a primary problem emerged early in the project: the data needed from a customer was available but not centralized, so the team tackled that first.

Sometimes there is reluctance from a business team to "greenlight" development without all the bells and whistles. Perhaps they are afraid they will not get desired features otherwise. The focus on the Now-Next- Later Roadmap helps alleviate that fear because the project is clearly not complete after the first iteration; there is still more work to be done, yet the value is already being enjoyed.
POA Practitioners need to understand how their initiative contributes at the strategic, initiative and delivery horizon, as well as integrates with other initiatives. Without planning across initiatives, the product is at risk of not having the needed resources to deliver maximum value.

Types of integrations across initiatives include:
  • Product integration - Multiple teams working on one product,
  • Strategic Initiative integration - Multiple products contributing to a strategic initiative, and
  • Organizational integration - Multiple departments within an organization contributing to the success of the product.
Scaling frameworks can address integration across initiatives including:
  • Scaled Agile Framework (SAFe®) for Lean Enterprises. This is a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using:
    • Lean,
    • Agile, and
    • DevOps.
  • Scrum-of-scrums is a scaling mechanism. Scrum scales fractally and limits the number of communication pathways needed to transmit information relevant to the success of the enterprise.
  • Large Scale Scrum (LeSS) provides two large-scale Scrum frameworks which are basically single-team Scrum scaled up:
    • LeSS: Up to eight teams (of eight people each).
    • LeSS Huge: Up to a few thousand people on one product.
How POA Helps Integrate across Initiatives

POA Practitioners have an expanded realm of responsibility and influence when it comes to integrations across initiatives. Imperative to the success of the product, POA advocates partnering to prepare for planning sessions that facilitate teamwork across the initiatives.
  • Integrations are planned.
  • Teams seek to uncover ways to share tasks.
POA Practitioners empower team members to engage as contributors to the success of each integrated initiative. They navigate communication and engagement with an expanded team as each initiative and integration point requires team members to cross-coordinate their efforts efficiently and effectively. They contribute to the success of integration (scaling) through:
  • Transparent communication,
  • Creative collaboration and negotiation,
  • Being available and interested, and
  • Commitment to the success of all integrated initiatives.
POA Techniques to Integrate across Initiatives

Agile Extension Techniques
  • Purpose Alignment Model: Assess ideas in the context of customer and business value. It can be extended to an initiative level and to evaluate cohesive business value.
  • Value Stream Mapping: Analyze the flow of the product features, product workflows or transactions to visually show how value is augmented over time. It can be used to understand the cadence of initiatives and builds a bigger picture.
BABOK® Guide Techniques
  • Business Capability Analysis: Understand the constraints and capabilities of the organization in planning and collaborating against initiatives.
  • Decision Modelling and Analysis: Establish a decision framework for the enterprise and their precedence so that collaboration across initiatives has a clear reference on how repeatable enterprise decisions would be taken.

Case Study: Integrate Across Initiatives - Food Manufacturer
Background
As Poultry Plus continued to modernize the systems used for their growing business, it became evident that the various divisions were using:
  • Multiple systems, and
  • Manual processes and spreadsheets to complete their work.
In discovery, the IT leadership, in conjunction with executive management, decided that a long-term solution would be to replace the disparate systems with four systems:
  • Product management,
  • Quality assurance systems for the plants,
  • An Enterprise Resource Planning system for back-office functions, and
  • A Business Intelligence system which worked across all systems.
Challenge
Implementing the new systems was done in parallel with the processes established at the company so that operations could continue without interruption. IT development proceeded in their business-unit focused scrum teams. It was apparent that overlapping work was being done, and that some gaps in needs for implementation, were being overlooked.

For example, the poultry division's need for product management varied from the pet food division's, so customizations to the software solution purchased were different. The poultry division's needs were simpler, and their development was completed faster and did not take into consideration the pet food division's needs. If development continued in favour of the poultry division, a great deal of rework would be needed for the pet food division. Then the rework may or may not meet the poultry division's needs.

Action
It was decided to realign IT operations around a more Scrum-of-Scrums model to integrate across the initiatives, led by Susan, a Senior Product Manager.

The IT organization was reorganized to focus on products rather than business units. Susan and the Product Owners in each group met regularly to discuss their product roadmaps and determine where overlaps may occur and where coordination between groups would be required. Care was taken to schedule resources to focus on the current highest-priority development items across the roadmaps, rather than staying within the product team. Susan worked with each team to overcome roadblocks and re-balance resources when needed.

For example, each business unit relied on data provided by Business Intelligence. They needed information beyond their unit, to inform decisions. The product groups knew which pieces of information were coming up in their next sprint that the business unit would need but required resources from Business Intelligence to make that data available.

Outcomes
Susan kept a diagram of the upcoming Business Intelligence needs on a timeline. The product Owners discussed which BI elements were needed in each sprint to allocate resources accordingly. Besides, members of the BI development teams attended sprint-planning meetings with the individual teams to understand the needs at a root level.

Lessons Learned
Communication is key when parallel initiatives are being run across an organization. Otherwise, inefficiencies and rework are common. Poultry Plus recognized this and re-structured the IT operations to avoid common pitfalls in development coordination. The Scrum-of-Scrums model worked well because it ensured that all scrum teams had their needs represented and communicated at a higher level. It coordinated efforts across scrum teams for maximum efficiencies in their development efforts.
Organizational support extends across departments, ignoring silos, to
  • Plan and coordinate efficiently,
  • Manage risks and assumptions, and
  • Harmonize work efforts.
Product success often depends on parts of the organization that may not be directly involved in the product team's day-to-day activities.

How POA Helps Cultivate Organizational Support

POA Practitioners cultivate a support system and create a culture of teamwork across the organization by:
  • Managing and using the stakeholder map to effectively communicate with each stakeholder.
  • Being attentive to signs of misunderstanding or misalignment and addressing concerns with transparency and authenticity.
  • Knowing how the product will contribute to organizational strategy.
  • Demonstrating interest in other strategic products and initiatives.
  • Having a compelling elevator speech.
  • Having social connections with stakeholders.
  • Championing the product throughout the organization.
  • Asking for help and seeking insights from others in the organization.
  • Asking questions to understand and to inspire.
POA Techniques to Cultivate Organizational Support

BABOK® Guide Techniques
  • Stakeholder Map: Analyze stakeholders across the organization to create an effective engagement and collaboration approach.
Other Techniques
  • Working Agreements: Get a formal or informal agreement for resource and outcome sharing across the enterprise.

Case Study: Cultivate Organizational Support - Food Manufacturer
Background
Poultry Plus is a manufacturer of food products for people and pets. Poultry is processed for sale:
  • To restaurants, and
  • In grocery stores
Pet food manufacturing includes:
  • Co-packing (using the customer's formulations), and
  • Private label (the company's formulation sold under a customer's private label).
While there are similarities between the business unit operations, there are differences in complexity and application of operations.

Challenge
Executive leaders at Poultry Plus struggled to allocate needed resources to the different business units because:
  • Data analysis was inconsistent,
  • Data for each business unit was not available in a visual format, and
  • Data elements reported were not comparable or available within a single system.
Executive management needed to have a view of the data that clearly indicated key business drivers to make the right decisions for the direction of the company.

Divisional management needed lower-level views of the data to make the right operational decisions on a day-to-day basis. Resources in both business units spent a great deal of time compiling data and arranging it in easy-to-view presentations for the top leaders to review. In most review meetings, there were many questions left unanswered by the data presented, and the divisional resources had to go back and revise the data. Frustrations were high as non-value-added work continued to answer questions and inform decisions.

Action
Poultry Plus previously purchased an enterprise data warehousing solution but was not using it to solve the data visibility issue. A POA Practioner on the development team, Carla, worked with the business leaders and operators to understand what data elements were essential to use in their daily work. She also worked with executives to understand what level of data would answer the critical questions for their level of decision-making. This formed the basis for customer personas, which included:
  • Executive Manager,
  • Operations Manager, and
  • Operator.
They were arranged on a Stakeholder Map. Their specific needs were listed visually and used to ensure that the right data from the right sources were leveraged to roll up to the executive level.

Carla worked with the Business Intelligence team to compile the data into a usable format for the entire company. The visualizations started at a high-level view across the company and could be drilled into according to business unit, specific projects, and even specific products and suppliers to see where there were changes needed or opportunities existed.

Outcome
The first rollout of a "speed-to-market" dashboard indicated how quickly products were being manufactured and distributed according to plan, which was given to the operations team for the poultry division. It was so well received that it was quickly adopted by the sales, marketing, quality, and research and development teams in that division and soon after to the pet food divisions.
  • Executives were thrilled that they could open a webpage on their tablet and immediately see trends across the company, all in the same context.
  • Managers no longer had to manually comb through data to produce slide presentations for status meetings, which freed up their time to work on more productive tasks. In fact, many status meetings across the company were deemed no longer necessary since access to the data was readily available.
Additional dashboards were prioritized for the creation and put into the development pipeline.

Lessons Learned
Prior attempts at providing data for decision-making across the company did not take into consideration the true needs of executive management and were limited to the daily needs of the different divisions.

The stakeholder map was an essential element because the primary user "types" for the data had quite different needs for the same data. Working towards pleasing one would not have been useful for the other, and may have led to more disparity, rather than unification.