Strategy, Visibility and Traceability

In a previous post, I talked about the need for set of tools for quantifying and qualifying strategy that both empowers intuition and creativity, while also helping teams find objective ways to value design solutions to justify the experience investments in that bring us ever closer to our vision and goals.

In this post I’ll talk the need for visibility and traceability systems that allow us to make comparisons of expected outcomes with actual outcomes and enables you to adjust strategic choices accordingly.

TL;DR;

• The reason we need to find ways for capturing and tracking progress around the execution of an idea/approach comes from the fact that strategies can still fail if you fail to establish management systems that support strategic choices.
• Once we’ve created shared understanding about the strategic choices the unique positions our stakeholder want to create, creating systems for capturing and tracking progress around the execution of an idea/approach will allow us to make comparisons of expected outcomes with actual outcomes and enable us to adjust strategic choices accordingly.
• Using hypothesis to describe outcomes (instead of outputs or rigid requirements) creates focus and alignment by communicating to teams how they should be measuring success, aligning around the work they should be prioritizing, helping them choose the right customer opportunities to address.
• Alignment Diagrams can be great tools to help teams visualise the connection between assumptions, hypothesis, and outcomes.
• At some point in the product development lifecycle — however — we will need to know if we are making progress to our goals by tracking and tracing the build, creating measuring and learning cycles, providing the data that will help teams decide if they should persevere, pivot or stop.
• That’s why teams need to find ways to keep the discussions around assumptions, hypothesis, outcomes and deliverables at that right level of granularity with the right set of stakeholders:
  • Alignment diagrams help collaboration between strategists, leadership and teams to align goals to outcomes.
  • Visibility and Traceability Frameworks provide the systems to measure and decide if we should persevere, pivot or stop.
• Once these visibility and traceability systems are in place, all we need to do is rinse-and-repeat: create the rituals in a cadence that helps teams make sure we are getting closer to our vision by creating work that adds value, while striking a balance between the extremes of a burdensome process and no process at all.

Design and Metrics

In a previous post, I argued that we need objective ways to value design solutions to justify the experience investments, and to look at the different points in the strategic planning and execution and identify the discussions that strategists should facilitate around what customers and users perceive as value, while tracking and tracing the implementation of strategy to ensure we are bringing value for both customers and business.

Design is the activity of turning vague ideas, market insights, and evidence into concrete value propositions and solid business models. Good design involves the use of strong business model patterns to maximize returns and compete beyond product, price and technology.

Bland, D. J., & Osterwalder, A., Testing business ideas, (2020)

From that perspective, we need to find ways to:

• Explore (and preferably test) ideas early
• Facilitate investment discussions by objectively describe business and user value, establishing priorities
• Asses risk of pursuing ideas, while capturing signals that indicate if/when to pivot if an idea “doesn’t work”
• Capture and track progress of strategy implementation

Quantifying and Qualifying the value and performance of design does not need to be complex or foreboding. There is a case for intuition, a case for qualitative user research, a case for quantitative research, and a case for synthesis. And there is even room for imponderables, because somethings are simply beyond definition or measurement (Lockwood, T., “Design Value: A Framework for Measurement” in Building Design Strategy, 2008).

Visibility and Traceability

It’s an old saying that what gets measured gets done. There is more than a little truth to this. If aspirations are to be achieved, capabilities developed, and management systems created, progress needs to be measured (“Manage What Matters” in Playing to Win: How Strategy Really Works (Lafley, A.G., Martin, R. L., 2013).

Measurement allows comparison of expected outcomes with actual outcomes and enables you to adjust strategic choices accordingly.

“Manage What Matters” in Playing to Win: How Strategy Really Works (Lafley, A.G., Martin, R. L., 2013)

I will refrain from proposing a single metric for visibility and traceability for a few reasons:

• Different organizations have specific strategic choices about winning that uniquely positions in their corresponding industry: these metrics should take in consideration both the goals of users, but also what is the business trying to learn from the study, then design usability studies accordingly.
• Different organizations are different levels of design maturity: if you’ve never done any kind of usability studies, it’s not only hard to build the capability to run such studies, but also figure out how to feedback the information back into product decisions.
• Some of these metrics are discovered too late: since some of these metrics are collected either during usability studies or after the product or service is released, it means that — by the time you collect them — a lot of product decisions have already been made. Some of these decisions could be quite expensive to reverse or pivot at that point, so it might be too late for quantifying and qualifying the success of strategy.
• Beware of how you measure: quantitative metrics are good to explain ‘What’ and ‘How many’ of a given hypothesis; the ‘Why’ are usually better captured through qualitative research methods
• The world is different now: some of the signals and indicators that worked for measuring success may not work for new products or services you are trying to create.

Before we can define visibility and traceability systems for capturing and tracking progress around the execution of an idea/approach, designers must engage with their business stakeholders to understand what objectives and unique positions they want their products to assume in the industry, and the choices that are making in order to achieve such objectives and positions.

The reason I suggest we need to find ways for capturing and tracking progress around the execution of an idea/approach comes from the fact that — even when you have clearly articulated the answer to the six strategic questions (what are our aspirations, what are our challenges, what will we focus, what our guiding principles, what type of activities) — strategies can still fail — spectacularly — if you fail to establish management systems that support those choices. Without the supporting systems, structures and measures for quantifying and qualifying outcomes, strategies remains a wish list, a set of goals that may or may not ever be achieved (“Manage What Matters” in Playing to Win: How Strategy Really Works (Lafley, A.G., Martin, R. L., 2013).

Although design and several usability activities are certainly qualitative, the image of good and bad designs can easily be quantified in conversation, completion rates, completion times, perceived satisfaction, recommendations and sales (Sauro, J., & Lewis, J. R., Quantifying the user experience: Practical statistics for user research. 2016).

Once we’ve created shared understanding about the strategic choices the unique positions our stakeholder want to create, creating visibility and traceability systems for capturing and tracking progress around the execution of an idea/approach will allow us to make comparisons of expected outcomes with actual outcomes and enable you to adjust strategic choices accordingly

Requirements Management, Visibility and Traceability

For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is one of the last things we want to do on a project. We worry about getting the product built and tested as best as we can. And we feel fortunate to gather any requirements at all (Larson, E., & Larson, R., No time to manage requirements in project management methodology. PMI® Global Congress, 2008).

Lack of a well-managed requirements process can lead to common project issues, such as scope creep, cost overruns, and products that are not used.

Larson, E., & Larson, R., No time to manage requirements in project management methodology. PMI® Global Congress (2008)

Requirements Management Plans versus Managing Chaos

The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed. Some organizations refer to it as a business analysis plan. Components of the requirements management plan can include but are not limited to (Project Management Institute, A guide to the project management body of knowledge PMBOK guide, 2017):

• How requirements activities will be planned, tracked, and reported;
• Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;
• Requirements prioritization process;
• Metrics that will be used and the rationale for using them; and
• Traceability structure that reflects the requirement attributes captured on the traceability matrix.

Yet many project professionals skim over this important part of the project and rush to design and build the end product. It is not uncommon to hear project professionals and team members rationalize about why requirements management is not necessary. We commonly hear these types of statements (Larson, E., & Larson, R., No time to manage requirements in project management methodology. PMI® Global Congress, 2008):

• “I don’t have time to manage their requirements. I’m feeling enough pressure to get the project done by the deadline, which has already been dictated.”
• “Our business customers don’t fully understand their requirements. I doubt if all the details will emerge until after we implement!”
• “My clients are not available. I schedule meetings only to have them cancelled at the last minute. They don’t have time. They’re too busy to spend time in requirements meetings. And my clients, the good ones, are working on other projects, their day-to-day jobs, fighting fires, and their own issues.”
• “Managing requirements, when they’re just going to change, is a waste of time and resources. It creates a bureaucracy. It uses resources that could be more productive on other tasks, such as actually getting the project done!”

Getting the Right Amount of Requirements Management

Choosing an appropriate requirements management process is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. Too much rigor can become overly burdensome. Here are some pitfalls to avoid (Larson, E., & Larson, R., No time to manage requirements in project management methodology. PMI® Global Congress, 2008):

• Misaligning the amount of rigor required with the size of the project. One example of misalignment is having inappropriate levels of approval, such as requiring a formal Change Control Board for a small, wellunderstood, low-impact, and well-accepted change.
• Developing a requirements management plan that takes more time to create than developing the product.
• Requiring the creation of a requirements management plan “because that’s the process we follow here.”
• Handling all projects with the same degree of requirements management.

The “right” amount of requirements management occurs when there is enough rigor to (Larson, E., & Larson, R., No time to manage requirements in project management methodology. PMI® Global Congress, 2008):

• Reduce business and product risks.
• Communicate effectively with all stakeholders. Communications becomes more complex with more stakeholders, so formalizing the communications on larger, more complex projects is usually appropriate.
• Help ensure that a quality product is delivered at the end of the project.

Requirements Management and Agile

In the current environment that most technology companies in which words like “requirements” might sound so old-fashioned and not “agile”, I feel strongly the unintended consequence in attempting to create autonomous teams was that we’ve traded good stewardship principles of project management (like requirements managements, scoping, risk analysis) by complete chaos.

That said, we do need to acknowledge the limitations of requirement thinking.

Requirements assume we know exactly what we need to build. Ideally, they come from engineering rigor. But in software, they usually don’t have the rigor behind them. Still, they are taken at face value based on their author’s credibility or organizational title.

Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience (2021)

Amazon has decreased their time to market to one second. That’s right: every second some Amazon customer somewhere in their ecosystem experiences a change to the way the product works. Sixty times per minute, Amazon has an opportunity to learn how well they’re meeting the needs of their customers. Sixty times per minute, they have an opportunity to respond to what they’re learning. Sixty times per minute, they have an opportunity to make their user experience better. With this capability, the very idea of a rigid requirement is, at best, anachronistic. At worst, it’s an impediment that prevents teams from doing their best work (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).

If we can ship, sense, and respond to this quickly, then assuming that we know exactly how to best deliver value is a level of arrogance and risk your organization cannot afford.

Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience (2021)

So what should we do? We need to recognize that most requirements are simply assumptions expressed with authority. If we remove the authority, overconfidence, and arrogance from the conversation, we’re left with someone’s best guess about how to best achieve a user goal or solve a business problem. We are makers of digital products, so humbly admitting that these are indeed our best guesses or assumptions immediately and explicitly creates the space for product discovery and Lean UX to take place (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).

If we understand as a team that the work we’re undertaking is risky exactly because we can’t predict human behavior, we know that part of our work will have to include experimentation, research, and rework.

Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience (2021)

We reduce our attachment to the ideas and create a team culture that is more willing to adjust course–even to stop working on an idea that continues to prove unviable (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).

Assumptions, Hypothesis and Outcomes

Many companies try to deal with complexity with analytical firepower and sophisticated mathematics. That is unfortunate, since the most essential elements of creating a hypothesis can typically be communicated through simple pencil-and-paper sketches (Govindarajan, V., & Trimble, C., The other side of innovation: Solving the execution challenge, 2010.)

The key to dealing with complexity is to focus on having good conversations about assumptions.

Break Down the Hypothesis in The other side of innovation: Solving the execution challenge, Govindarajan, V., & Trimble, C., (2010)

As you sit down with your teams to plan out your next initiative, ask them these questions (Gothelf, J., & Seiden, J., Sense and respond. 2017):

• What is the most important thing (or things) we need to learn first?
• What is the fastest, most efficient way to learn that?

To understand the risk and uncertainty of your idea you need to ask: “What are all the things that need to be true for this idea to work?” This will allow you to identify all four types of hypotheses underlying a business idea: desirability, feasibility, viability, and adaptability (Bland, D. J., & Osterwalder, A., Testing business ideas, 2020):

• Desirability: Does the market want this idea?
• Feasibility: Can we deliver at scale?
• Viability: Is the idea profitable enough?
• Adaptability: Can the idea survive and adapt in a changing environment?

The idea is that we write our ideas, not as requirements, but as our best guesses for how to deliver value and with clear success criteria to tell us whether our idea was valuable and we delivered it in a compelling way (Gothelf, J., & Seiden, J., Lean UX, 2021):

We believe
[this outcome] will be achieved if
[these users] attain [a benefit]
with [this solution/feature/idea].

Gothelf, J., & Seiden, J., “Hypothesis Template” in Lean UX, (2021)

The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements (Gothelf, J., & Seiden, J., Lean UX, 2021):

• Assumptions: A high-level declaration of what we believe to be true.
• Hypotheses: More granular descriptions of our assumptions that target specific areas of our product or workflow for experimentation.
• Outcomes: the signals we seek from the market to help us validate or invalidate our hypotheses. These are often quantitative but can also be qualitative.
• Personas: Models of the people for whom we believe we are solving the problem.
• Features: the product changes or improvements we believe will drive the outcomes we seek.

In traditional planning, the solution provider commits to delivering specified deliverables (the scope) at a specified cost within a given time frame. This approach doesn’t work when requirement are volatile because it locks all parties into predetermined specifications that are likely to be outdated by the time the product is delivered. Instead of focusing on predetermined deliverables, agile enterprises focus on desired outcomes, such as increased revenues and increased customer loyalty (Podeswa, H., The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery, 2021)

You might be asking, “what you do mean by outcome”. Joshua Seiden defines as outcome “a change in user behaviour that drives business results.”

You can help the team start thinking in terms of outcomes by asking three simple questions (Seiden, J., Outcomes over Output, 2019):

• What are the user and customer behaviours that drive business results? I’ve suggested in another post that facilitating discussions around Jobs to be Done can be a great way to get the team to align.
• How do we get people to do more of these things?
• How do we know we’re right? The easiest (and the hardest) way to answer that question is to design and conduct tests.

Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do

Seiden, J., Outcomes over Output (2019)

Managing by outcomes communicates to the team how they should be measuring success. A clear outcome helps a team align around the work they should be prioritizing, it helps them choose the right customer opportunities to address, and it helps them measure the impact of their experiments. Without a clear outcome, discovery work can be never-ending, fruitless, and frustrating (Torres, T., Continuous Discovery Habits, 2021).

Alignment Diagrams

Organizations are out of sync with the people they serve experience. Misalignment impacts the entire enterprise: teams lack a common purpose, solutions are built that are detached from reality, and strategy is short sighted. Alignment Diagrams coordinates insights from the outside world with the teams inside an organization who create products and services to meet market needs (Kalbach, J., ”Visualizing Value: Aligning Outside-in” in Mapping Experiences, 2021).

In other words, Alignment diagrams or models serve as a hinge upon we can pivot from the problem space to the solutions space.

Thanks to their ability to pivot from the problem space to the solutions space, Alignment Diagrams can be great tools to help teams visualise the connection between assumptions, hypothesis, and outcomes.

Let’s look at some Alignment Diagrams that I’ve found more useful to define what we would like to trace and measure in the product development lifecycle.

Lean UX Canvas

Lean UX Canvas codifies the Lean UX process to help teams frame their work as a business problem to solve (rather than a solution to implement) and then dissect that business problem into its core assumptions. We then weave those assumptions into hypotheses. Finally, we design experiments to test our riskiest hypotheses (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).

Opportunity-Solution Tree

Many teams generate a lot of ideas when they go through a journey-mapping or experience-mapping exercise. There are so many opportunities for improving things for the customer that they quickly become overwhelmed by a mass of problems, solutions, needs, and ideas without much structure or priority (“Opportunity-Solution Tree” in Product Roadmaps Relaunched, Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M., 2017).

Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome (Torres, T., Continuous Discovery Habits, 2021):

• The root of the tree is your desired outcome—the business need that reflects how your team can create business value.
• Below the opportunity space is the solution space. This is where we’ll visually depict the solutions we are exploring.
• Below the solution space are assumption tests. This is how we’ll evaluate which solutions will help us best create customer value in a way that drives business value.

Opportunity solution trees have a number of benefits. They help product trios (Torres, T., Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, 2021):

• Resolve the tension between business needs and customer needs
• Build and maintain a shared understanding of how they might reach their desired outcome
• Adopt a continuous mindset
• Unlock better decision-making
• Unlock faster learning cycles
• Build confidence in knowing what to do next
• Unlock simpler stakeholder management

Impact Mapping

Like highway maps that show towns and cities and the roads, connecting them, Impact Maps layout out what we will build and how these connect to ways we will assist the people who will use the solution. An impact map is a visualisation of the scope and underlying assumptions, created collaboratively by senior technical people and business people. It’s a mind-map grown during a discussion facilitated by answering four questions: WHY, WHO, HOW and WHAT of the problem the team is confronting (Adzic, G., Impact Mapping, 2012)

User Story Maps

User story mapping is a visual exercise that helps product managers and their development teams define the work that will create the most delightful user experience. User Story Mapping allows teams to create a dynamic outline of a set of representative user’s interactions with the product, evaluate which steps have the most benefit for the user, and prioritise what should be built next (Patton, J.,  User Story Mapping: Discover the whole story, build the right product, 2014).

Jeff Patton is one of the few people that has been able to translate Agile into a User Centric practice, and User Story Mapping is probably my favourite visualisation tool to create shared understanding around product, users, context and it really helps with prioritisation discussions.

While Alignment Diagrams are great for visualising the connection between assumptions, hypothesis, and outcomes, the old saying goes that “The Devil is in the details”: at some point in the product development lifecycle, we will only be able to tell if we are making progress to our goals when we are able to track and trace the build, measure and learn cycle, providing the data that will help teams decide if they should persevere, pivot or stop.

What I suggest is that teams need to find ways to keep the discussions around assumptions, hypothesis, outcomes and deliverables at that right level of granularity with the right set of stakeholders:

• Alignment diagrams help collaboration between strategists, leadership and teams to align and map goals to outcomes.
• Visibility and Traceability Frameworks provide the systems to measure and decide if we should persevere, pivot or stop.

Visibility and Traceability Frameworks

Now, let’s look at some visibility and traceability frameworks that helps make comparisons of expected outcomes with actual outcomes and enable us to adjust strategic choices accordingly.

Objectives, Goals, Strategy, and Measures (OGSM)

Objectives, Goals, Strategy, and Measures (OGSM) is a simple, clear expression of a strategy, a living document that help with the visibility and traceability of objectives, strategy and measures, so that everyone in the business knows and understands (“Manage What Matters” in Playing to Win: How Strategy Really Works (Lafley, A.G., Martin, R. L., 2013).

The main benefit of the OGSM is that it helps management refrain from setting convoluted targets. By restricting the plan to a single page, the OGSM sharpens employees’ focus and is an effective reference tool for direction in times of uncertainty and decision dilemmas (“Manage What Matters” in Playing to Win: How Strategy Really Works (Lafley, A.G., Martin, R. L., 2013).

Use Cases Lists: Pugh Matrix

The UXI Matrix is a simple, flexible, visibility and traceability tool that extends the concept of the product backlog to include UX factors normally not tracked by agile teams. To create a UX Integration Matrix, you add several UX-related data points to your user stories (Innes, J., Pugh Matrix in Integrating UX into the product backlog, 2012)

The UXI Matrix helps teams integrate UX best practices and user-centered design by inserting UX at every level of the agile process:

• Groom the backlog: During release and sprint planning you can sort, group, and filter user stories in Excel.
• Reduce design overhead: if a story shares several personas with another story in a multi-user system, then that story may be a duplicate. Grouping by themes can also help here.
• Facilitate Collaboration: You can share it with remote team members. Listing assigned staff provides visibility into who’s doing what (see the columns under the heading Staffing). Then team members can figure out who’s working on related stories and check on what’s complete, especially if you create a hyperlink to the design or research materials right there in the matrix.
• Track user involvement and other UX metrics: It makes it easier to convince the team to revisit previous designs when metrics show users cannot use a proposed design, or are unsatisfied with the current product or service. Furthermore, it can be useful to track satisfaction by user story (or story specific stats from multivariate testing) in a column right next to the story.

I’ve created Use Cases Lists (or Pugh Matrix), which is decision matrix to help evaluate and prioritize a list of options while working with Product Management and Software Architecture teams in both AutoCAD Map3D and AutoCAD Utility Design projects to first establish a list of weighted criteria, and then evaluates each use case against those criteria, trying to take the input from the different stakeholders of the team into account (user experience, business values, etc).

Using the Outcome-driven Innovation Framework above, you can prioritize the Use Cases based on their Opportunities Scores.

Rituals for Visibility and Traceability

How to all of the above come together? In experience, the visibility and traceability challenges around adopting and working in all the good stuff that Agile and Lean processes have been advocating for a decade (how to help teams create shared vision, define outcomes, work from assumptions, hypothesis, experiments, etc) are not so much how to work with such best practices: most of the time, we don’t know how our current processes work, neither when, nor who we need to influence to introduce any new best practices.

In most organisations, no one person can describe the complete
series of events required to transform a customer request into a
good or service–at least not with any level of detail around organisational performance. This gap in understanding is the kind of problem that leads to making improvements in one functional area only to create new problems in another area. It’s the kind of problem that results in adding processes that increase operational cost but doesn’t truly solve problems with root causes that reside upstream. It’s the kind of problem that propels well-meaning companies to implement expensive technology “solutions” that do little to address the true problem or improve the customer experience (Martin, K., & Osterling, M., Value stream mapping, 2014).

The lack of understanding about how work flows — or, more commonly, doesn’t flow — across a work system that’s sole purpose is to deliver value to a customer is a fundamental problem that results in poor performance, poor business decisions, and poor work environments.

Martin, K., & Osterling, M., Value stream mapping (2014)

Conflicting priorities, interdepartmental tension, and–in the worst cases-infighting within leadership teams are common outcomes when a company attempts to operate without a clear understanding about how an organization’s various parts fit together and how value is delivered to its customers. And significant time and money is wasted when organizations attempt to make improvement without a clearly defined, externally focused improvement strategy that places the customer in the center. Enter the concepts of value streams and value stream mapping (Martin, K., & Osterling, M., Value stream mapping, 2014).

Value Stream Mapping is a practical and highly effective way to learn to see and resolve disconnects, redundancies, and gaps in how work gets done. Value Stream Mapping Transformation Plans include (Martin, K., & Osterling, M., Value stream mapping, 2014):

• Measurable outcomes
• Clear ownership
• Projected start and end dates for each improvement
• Real-time status for tracking transformation

Based on the concept of value stream mapping, I’ve been trying to work with stakeholders to put organisational transformation plans in place for any of these best practices to work. Such plans are not just about describing the best practices but also getting buy-in and executive support from stakeholders to ensure the transformation has any chance of success.

Let’s look at how — in my view — does value stream mapping fits into these Agile or Lean environments:

Prepare Leadership

At the leadership level, the biggest transformation that needs to happen is to help leaders think about their organisational goals in terms of outcomes.

As I mentioned earlier, managing by outcomes communicates to the team how they should be measuring success. A clear outcome helps a team align around the work they should be prioritizing, it helps them choose the right customer opportunities to address, and it helps them measure the impact of their experiments. Without a clear outcome, discovery work can be never-ending, fruitless, and frustrating (Torres, T., Continuous Discovery Habits, 2021).

Map Current State

Both the leadership and teams need to have shared understanding of what the current state, especially when it comes to one of the key vision questions, which is what are our challenges:

What problems are you solving for? Focus on customers and users, but you may also have internal challenges you want to list here too. In this stage we need to align in the challenges we want to address, by listing the following:

• Drivers: what are the forces (internal or external) that propel us to move. The sources of drivers could be many, including competitive analysis, user research, top level initiatives, company strategy.
• Challenges: what are the key problems we are trying to solve? and for whom?
• Goals: is there a shared understanding on what we are trying to achieve? Desired outcomes? OKRs?

Earlier in this series, I mentioned my experience has been that — more often than not — is not for the lack of ideas that teams cannot innovate, but because of all the friction or drag created by not having a shared vision and understanding of what the problems they are trying to solve. I’ve also mentioned that there are problem framing techniques that can help you get team alignment by creating clarity of what problems they are trying to solve.

Design the Future State

Both the leadership and teams need to have a shared understanding of what is the future we are trying to create, especially when it comes to two of the key vision questions, which is what are aspirations and what will we focus on:

With regards to what are our aspirations, we first need to clarify what is the purpose of our enterprise, our mission or winning aspiration. The term “winning” means different things to different people so the first step in developing great strategy is to specify exactly what winning will look like for us. I propose we specify it by answering the following questions:

• What is the future experience do we ultimately want to deliver? define that first, and what backwards by asking what needs to be true.
• How will we impact our customers’ work and daily lives?
• How does our solution transform what they capable of doing and who they ultimately are?

With regards to what will we focus on,

Once we’ve stated are aspirations, we then need to identify a playing field where we can realize our aspiration. No company can be all things to all people and win, so where-to-play choices – which markets, which customer segments, which channels, which industries, etc. – narrows our focus. 

From a positioning perspective, we could pick a few segments/facets of the experience to focus on:

• USERS: Who will use our solution? We need to list the personas that are most relevant to the success of this strategy.
• REGIONS: What are the countries, languages, and cultures that are in play? 
• SCENARIOS: We need to indicate the key scenarios of use at a high level
• AREAS OF UX: We need to strategically highlight aspects that should be priority such as information architecture, interaction design, visual design, as well as attributes of usability such as control, learnability, or discoverability, among others.

In order to answer any of these questions, the leadership and teams will need to create a lot of shared understanding around assumptions, hypothesis, outcomes, mapping impact to outcomes, will helps facilitate prioritisation discussions.

Create Transformation Plans

The success of any transformation boils it all down to five unavoidable facts: you need a well-crafted plan, consensus around that plan, the discipline to stick with it, the wisdom to know when to adjust the plan, and the restraint to deviate from the plan only when absolutely necessary (Martin, K., & Osterling, M., Value stream mapping, 2014).

The extend to the degree of formality that you need to create such transformation plans will be will depend heavily on 3 things:

• Striking a balance between the extremes of a burdensome process and no process at all;
• Your level of influence with the stakeholders;
• The level of buy-in and executive support in creating visibility and traceability systems.

One could argue that in the current state of the industry in which teams are pushed for ever greater need of agility, such transformation plans are overkill. That said, I cannot help but think that when multiple scrum teams are working towards bring a product into the world — which has been my experience with designing for enterprise for the last 25 years — some degree of formality and coordination will create clarity and reduce anxiety.

I can already hear your concern about not being able to influence the whole organisation (which is a fair concern). That said, it’s been my experience that a lot of team will be intrigued by and (most likely) willing try these techniques they feel will help them “be more agile”: while you may not be able to influence the whole organisation, if the teams themselves want to work based hypothesis and outcomes, I suggest to try creating momentum to adopt a build-measure-learn approach.

Socialise and Standardise

Once these visibility and traceability systems are in place, all we need to do is rinse-and-repeat: while you’ll need to strike a balance between the extremes of a burdensome process and no process at all, you’ll need to create the rituals in a cadence that helps teams make sure we are getting closer to our vision, frame the conversations during such rituals around doing work that adds value, facilitate the discussions that help teams decide if they should persevere, pivot or stop.

The Right Time for Visibility and Traceability

You might be asking yourself “These are all great, but when should I be doing what?”. Without knowing what kind of team set up you have, and what kinds of processes you run in your organization, the best I can do is to map all of the techniques above the the Double Diamond framework.

The Double Diamond Framework

Design Council’s Double Diamond clearly conveys a design process to designers and non-designers alike. The two diamonds represent a process of exploring an issue more widely or deeply (divergent thinking) and then taking focused action (convergent thinking).  

• Discover. The first diamond helps people understand, rather than simply assume, what the problem is. It involves speaking to and spending time with people who are affected by the issues.
• Define. The insights gathered from the discovery phase can help you to define the challenge in a different way.
• Develop. The second diamond encourages people to give different answers to the clearly defined problem, seeking inspiration from elsewhere and co-designing with a range of different people.
• Deliver. Delivery involves testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will.

Map of Visibility and Traceability Activities and Methods

Process Awareness characterises a degree to which the participants are informed about the process procedures, rules, requirements, workflow and other details. The higher is process awareness, the more profoundly the participants are engaged into a process, and so the better results they deliver.

In my experience, the biggest disconnect between the work designers need to do and the mindset of every other team member in a team is usually about how quickly we tend — when not facilitated — to jump to solutions instead of contemplate and explore the problem space a little longer.

Knowing when team should be diverging, when they should be exploring, and when they should closing will help ensure they get the best out of their collective brainstorming and multiple perspectives’ power and keep the team engaged.

Visibility and Traceability Activities during “Discover”

This phase is very divergent in nature, so we need to things that are counterintuitively risky and are usually perceived as “slowing us down”, such as user research, challenge the problem framing, create a shared vision, and test business ideas: the more you “discover” in this phase, the clearer (and more confident) you will be about your strategic choices.

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• User Research
• Hypothesis Writing
• Problem Framing
• Challenge Briefs
• Visioneering
• Value Proposition Design
• Jobs to be Done (JTBD)
• Testing Business Ideas
• A Value Opportunity Analysis (VOA)
• Desirability Testing

Visibility and Traceability Activities during “Define”

While in the previous phase we needed ask ourselves good questions that foster divergent thinking and explore multiple solutions, in this phase we need help teams converge and align on the direction they should go.

Visibility and Traceability in this phase depends on the kind of data that was generated in the previous phase (e.g.: Outcome-Driven Innovation, Importance vs. Satisfaction Framework, Kano Model, etc.) and find way to map them to Objectives, Goals, Strategy & Measures (OGSM).

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• User Story Mapping
• Stories/Epics
• Design Sprints / Studio
• Concept Validation
• Outcome-Driven Innovation / JTBD
• Importance vs. Satisfaction Framework
• Kano Model
• Objectives, Goals, Strategy & Measures (OGSM)
• Product Backlog & Sprint Planning

Visibility and Traceability Activities during “Develop”

Since this is the phase that we are moving away from simulations, and we can put something that resembles the final product in product of customers and users, we should be focusing as much as possible on capturing both preference and performance data from with concept validation and usability testing to decide if we should persevere, pivot or stop.

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• User Story Mapping
• Design Studio
• Specifications
• Collaborative Prototyping
• UXI Matrix (Pugh Matrix)
• Usability Testing
• Usefulness, Satisfaction, and Ease of Use (USE)
• American Customer Satisfaction Index (ACSI)
• System Usability Scale (SUS)
• Usability Metric for User Experience (UMUX)
• UMUX-Lite

Visibility and Traceability Activities during “Deliver”

In this phase, the visibility and traceability systems we should be collecting data from real customer usage, and make hard choices about pivot, persevere, or stop on next iteration of the product.

On the other hand — since the product is now on the hands of customers and users — we should be able to collect the richest data from live usage that can inform decisions about our viability hypothesis, enabling you to adjust strategic choices accordingly.

Here are my recommendations for suggested quantifying and qualifying activities and methods:

• Designer – Developer Pairing
• Fit-and-Finish
• Pirate Metrics (a.k.a. AARRR!)
• UXI Matrix (Pugh Matrix)
• Objectives, Goals, Strategy & Measures (OGSM)

Facilitate Visibility and Traceability Discussions

I’m of the opinion that designers — instead of complaining that everyone else is jumping too quickly into solutions — should facilitate the discussions and help others raise the awareness around the creative and problem solving process.

I’ll argue for the Need of Facilitation in the sense that — if designers want to influence the decisions that shape strategy — they must step up to the plate and become skilled facilitators that respond, prod, encourage, guide, coach and teach as they guide individuals and groups to make decisions that are critical in the business world though effective processes.

That said, my opinion is that facilitation here does not only means “facilitate workshops”, but facilitate the decisions regardless of what kinds of activities are required.

Recommended Reading

Bland, D. J., & Osterwalder, A. (2020). Testing business ideas: A field guide for rapid experimentation. Standards Information Network.

Design Council. (2015, March 17). What is the framework for innovation? Design Council’s evolved Double Diamond. Retrieved August 5, 2021, from designcouncil.ork.uk website: https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

Gothelf, J., & Seiden, J. (2021). Lean UX: Applying lean principles to improve user experience, 3rd edition. Sebastopol, CA: O’Reilly Media.

Gothelf, J., & Seiden, J. (2017). Sense and respond: How successful organizations listen to customers and create new products continuously. Boston, MA: Harvard Business Review Press.

Govindarajan, V., & Trimble, C. (2010). The other side of innovation: Solving the execution challenge. Boston, MA: Harvard Business Review Press.

Innes, J. (2012, February 3). Integrating UX into the product backlog. Retrieved July 28, 2021, from Boxesandarrows.com website: https://boxesandarrows.com/integrating-ux-into-the-product-backlog/

Kalbach, J. (2020), “Mapping Experiences: A Guide to Creating Value through Journeys, Blueprints, and Diagrams“, 440 pages, O’Reilly Media; 2nd edition (15 December 2020)

Lafley, A.G., Martin, R. L., (2013), “Playing to Win: How Strategy Really Works”, 272 pages, Publisher: Harvard Business Review Press (5 Feb 2013)

Larson, E., & Larson, R. (2008). No time to manage requirements in project management methodology. PMI® Global Congress 2008—EMEA, St. Julian’s, Malta. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/no-time-manage-requirements-8359

Lockwood, T., “Design Value: A Framework for Measurement” in Building Design Strategy: Using Design to Achieve Key Business Objectives, Lockwood, T., Walton, T., (2008); Allworth Press; 1 edition (November 11, 2008)

Lombardo, C. T., McCarthy, B., Ryan, E., & Connors, M. (2017). Product Roadmaps Relaunched. Sebastopol, CA: O’Reilly Media.

Martin, K., & Osterling, M. (2014). Value stream mapping: How to visualize work and align leadership for organizational transformation. New York, NY: McGraw-Hill Professional.

Patton, J. (2014). User Story Mapping: Discover the whole story, build the right product (1st ed.). Sebastopol, CA: O’Reilly Media.

Podeswa, H. (2021). The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery. Boston, MA: Addison Wesley.

Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (Sixth Edition). Newtown Square, PA (USA): Project Management Institute.

Sauro, J., & Lewis, J. R. (2016). Quantifying the user experience: Practical statistics for user research (2nd Edition). Oxford, England: Morgan Kaufmann.

Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.