Specifically, you can take the time to develop and bring to the table an outside-in, market-centric perspective that is so compelling and so well informed that it can counterbalance the inside-out company-centric orientation of last year’s operating plan.

—Geoffrey Moore, Escape Velocity


Continuous Exploration

Continuous Exploration (CE) is the process of constantly exploring market and user needs, and defining a Vision, Roadmap, and set of Features that address those needs. It is the first element in the four-part Continuous Delivery Pipeline, preceding Continuous Integration (CI) Continuous Deployment (CD), and Release on Demand.

Figure 1. Continues exploration is the first element of the continuous delivery pipeline

New Features are initially captured and defined during the CE process. When each features is ‘ready’, it is entered into the Program Backlog, and the Continuous Integration process pulls the highest priority features into implementation. Thereafter, the Continuous Deployment cycle pulls the feature into the staging or deployment environment, where they are validated and made ready for release.

Inputs to CE come from Customers, Agile Teams, Product Owners, Business Owners as well as stakeholders, and portfolio concerns. Under the direction of Product Management, various research and analysis activities are used to further define and evaluate the feature. The result of this process is a set outputs including the Vision, and a set of features in the Backlog sufficiently defined for implementation, and a preliminary Roadmap forecast of how those features might be delivered over time.


SAFe is optimized to deliver a continuous flow of value to the customer. As a result, it avoids the traditional waterfall approach, eliminating extensive up-front definition of the work to be done. Instead, it applies a continuous exploration process, providing a consistent flow of new work that is sufficiently “ready” for the teams to implement. This way, new functionality is available in small batches that can travel easily through continuous integration, continuous deployment and on to release.

Continuous Exploration Process

In the large, the CE process may be considered to consist of three separate activates, collaboration, research and synthesis, as can be seen in Figure 2.

Figure 2. Continuous exploration: collaboration, research, synthesis


To create a compelling and differentiated vision, Product Management enables and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders. Primary sources include:

Customers –By voting with their wallets or their feet, Customers are the ultimate judges of value. They’re the most obvious and primary source of input. But a note of caution: Customers are heavily bound to their current Solution Context, so they are often motivated only to improve things incrementally. In other words, the sum total of customer input does not a strategy make. But failing to meet real and evolving customer needs is an alternate path to extinction. A sense of balance is required. As the SAFe Lean-Agile Mindset says, “Producers innovate. Customers validate.”

Agile teams – The Agile Teams and Product Owners have some of the foremost expertise in the domain. In most cases, they developed the existing solution, and are closest to both technical and user concerns. Their input is integral and invaluable.

Business OwnersBusiness Owners have the business and market knowledge needed to set the mission and vision. They also have specific SAFe responsibilities throughout the development process. A solution that doesn’t meet their expectations is probably no solution at all.

Portfolio Concerns – As we described above, SAFe Value Streams and ARTs operate in a larger Portfolio context. Strategic Themes drive new epics improve portfolio differentiation.

System Architects/EngineersSystem and Solution Architects/Engineers have in-depth technical knowledge of the solution, and are responsible for understanding it at the system level, as well as its use cases and NFRs. So, although it’s natural to view these roles as technically and internally inclined, the most capable—in our experience—also have significant and ongoing customer engagement.


In addition to this direct input, Product Management use a variety of research activities and techniques to help establish the vision. These may include:

Customer visits – There’s no substitute for first-person observation of the daily activities of the people doing the work. Whether structured or informal, Product Managers and Product Owners are responsible for understanding how people actually use systems in their actual work environments. They can’t so that at their desk, so there is no substitute for direct for observing users in their specific Solution Context.

Gemba walks – Many times, customers are the internal people who implement the operational values streams that our development systems support. In this case, the ‘Gemba walk’ [Gemba is the place where the work is performed, see Ref 2] can be used by developers to observe how these stakeholders execute the steps and specific activities in their operational value streams.

Elicitation – There are a variety of structured elicitation techniques that Product Management and Product Owner professionals use to generate input and prioritize user needs. These include research methods such as interviews and surveys, brainstorming and idea reduction, questionnaires, and competitive analysis. Other techniques include requirements workshops, user experience mock-ups, user personas, customer change request systems, and use-case modeling. (See Leffingwell [3] and Innovation Games [Hohmann Ref 4].)

Trade studies – Teams engage in trade studies to determine the most practical characteristics of a solution. They review numerous solutions to a technical problem, as well as vendor-provided products and services that address the subject area or an adjacent need. Solutions are evaluated against desirable outcomes, agreeing on a hypothesis for the effective solution for a particular context.

Market research – To expand their thinking, teams also conduct original market research, analyze secondary research and market/industry trends, identify emerging customer segments, interview industry analysts, and review competitive solutions.

Synthesis – Building the Vision, Roadmap and Program Backlog

Based on this collaboration and research, Product Management synthesizes their findings into the key SAFe artifacts of vision, roadmap and Program Backlog. The Program Kanban helps manage this work. The default states of ‘Funnel’, ‘Analysis’ and ‘Backlog’ are good starting points to establish that workflow. The net result is a set of features that are in the backlog and are ready for implementation. These are stored in the backlog until they’re ready to appear as a WSJF-prioritized feature at PI Planning.

Define Features with Lean UX Thinking

In the Lean UX articles, we described an approach to implementing features that followed a simple, four-step lean process model:  1. define an outcome hypothesis; 2. design collaboratively; 3. implement a Minimum Marketable Feature (MMF), and 4. evaluate the MMF against the hypothesis.

And while this model was developed and described in the context of user-facing functionality, it isn’t reserved exclusively for that; all features benefit from this approach. For example, a feature such as “in service software update”, might not be user facing at all, but when ‘ready’ in the Program Backlog, it could appear as in Figure 3.

Figure 3. A ‘ready for implementation’ feature statement


That’s the transition point. With a solid feature definition in hand, the next process, continuous delivery, pulls features from the backlog and implements them. In accordance with Lean UX process [Ref 5], each Minimum Marketable Feature (MMF) is collaboratively designed and developed, delivered incrementally, and objectively measured, each feature investment tuned to optimum outcome.

Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc. Kindle Edition.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education. Kindle Edition.

[3] http://www.innovationgames.com

[4] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc. Kindle Edition.

[5] Gothelf, Jeff; Seiden, Josh. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. Kindle Edition.



Last update: 17 June, 2017