Imagine that you're starting a large and complex project with many dependencies and stakeholders. How do you focus on the pieces of that project that matter most to stakeholders across your enterprise and focus less or not at all on elements that won't?

In a recent project focusing on crafting and deploying Infrastructure as Code (IaC) in multi-domain and cross-architecture environments, our Customer Partner Experience Chief Technology Office (CPX CTO) team had to think through how each stage and layer of this project would impact other projects and teams. This project was one of the first to use the practice of working backwards - imagining some future state of business and customer value and then figuring out what needed to be done to deliver that value in the future. We have now adopted this practice for all our innovation projects.

Amazon Web Services (AWS) first popularized this process. Like AWS, we use a Press Release (PR) and Frequently Asked Questions (FAQ), commonly referred to as a PRFAQ. This document expresses the future state of value to both the business and customers. We have also introduced a new element to the "working backwards" process: a streamlined business model canvas.

Imagining the Future State: The Press Release (PR) and Frequently Asked Questions (FAQ)

The PR is dated at some point in the future when the product or system that is being imagined is announced to the world. The purpose is to help focus on a description of customer value: what is it that could be announced, based on your idea, that would be sufficiently interesting and valuable to be worth doing at all?

The FAQ is a document that accompanies the PR. Generally, the questions fall into two sets for internal and external audiences. The FAQ content is a way to help describe your future state idea from different perspectives. Not everything can or should go into a PR, so the FAQ answers help fill in the gaps and round out the ideas.

The PRFAQ sometimes defines some future customer value that will be part of an existing system - for example, a new feature or capability of something that is already deployed or planned. The PRFAQ can also describe the value that a new offer or capability will bring to a customer. There are, of course, myriad possibilities in between these positions. Indeed, part of the point of the exercise can be to answer the question of what the form should be.

Executing on the Vision: The Minimal Viable Product (MVP) and Minimally Viable Questions (MVQs)

Given the future state described in the PRFAQ, and a consensus that there is value in that state, a body of work must be scoped to start on the journey. Ideally, this is the minimum amount of work required to address as much as possible of the problem space -i.e., some form of minimally viable product (MVP).

Some aspect of the value expressed in the PRFAQ represents the essence of what you need to know to determine what is possible. It is this essential set of features or capabilities that the MVP has to focus on. This focus will help the MVP prove out enough of the original problem space to provide answers that inform the long-term goal illustrated in the PRFAQ.

The scope of the MVP can be difficult to define even in constrained problem spaces. In complex, multi-domain, and cross-architecture situations, the scope of the MVP is even more challenging to describe. Too broad, and the dependencies slow down progress because of the effort of managing multiple stakeholders. Too narrow, and the risk is that key stakeholders and/or dependent systems, techniques, practices, or tools are not fully explored.

In the IaC project that I have just completed, we chose the domain for which an MVP solution would be of immediate business value and that contained several components shared by the other domains. It also became clear, during my project, that the MVP technical deliverable is not a sufficient goal on its own. Simply because we could only tackle one domain, the problems we solved, and the code we developed, could not answer some questions about the other domains.

To get a complete picture of the challenges to overcome to deliver the business value in, we also needed to pose, and answer, a key set of questions. These became, if you like, the minimally viable questions (MVQs) - the minimal set of information needed to fully understand the other domains in the problem space.

Technologists typically think of creating MVPs, but the challenge with a multi-domain, cross-architecture project is that you can't address all concerns of all possible stakeholders with an MVP. If you tried, then your work would not be "minimal". You need to develop MVQs to fill in the gaps between what you can investigate from a technical perspective and what business, or technology needs remain to be explored.

Driving Organizational Alignment and Change

Our initial MVP has been adopted by another part of the business who are using our code to implement and deliver a service. Because of the commonality between our MVP and the other domains, this is also helping start a virtuous circle of improvement and organizational change for other domains.

It is important to be able to illustrate what that virtuous circle needs to look like, who has a role to play in it, and how those people interact in a sustainable way over time. Not every project leads to the same kind of organizational outcome, but explicit organizational alignment is almost always required to help support the sustainable delivery of a new idea over time.

That organizational alignment is an important prerequisite, before starting a project, is perhaps not always understood when working backwards. For multi-domain, cross-architecture problem spaces, knowing who the stakeholders are and ensuring that they understand and relate to the goals in the PRFAQ is key.

However, if the idea is new, then the organizational scaffolding to support it might not already exist and so might also have to be erected, or perhaps discovered. It is rare that a problem space worth tackling is completely unknown to an organization, but it can be common that such information is "diffuse" - in other words, pieces of knowledge of the problem space are distributed in pockets throughout the organization. This can be especially true when the overall idea is being delivered in a complex, multi-domain problem space with multiple stakeholders.

Coalescing awareness across multiple domains helped address the "knowledge diffusion" problem and identify issues that added up to a systemic concern from a multi-domain perspective. This, in turn, helped motivate new structures or programs for cross-architecture alignment.

In addition to clarifying priorities and driving organizational alignment, working backwards reinforces a constant and consistent awareness that a focus on technology, without also prioritizing customer value, is not sensible. For technologists like me, keeping an eye on the prize of serving the customer has shed light on what goals to execute on today to arrive at that ideal future state.