In this instalment of our #Zone5Principles blog series, Zone’s head of engineering, Paul Kiernan, explores why looking at the bigger picture is so important when setting your digital projects up for success.
Often missed or skipped, looking at the macro view helps give us context when looking at the micro. Looking at the big picture can be tricky and it’s easy to get lost in masses of information and endless drawn-out discovery phases. To help stop this from happening, we will discuss the key core themes that can support moving forward at speed.
In this article we’ll cover:
- Setting a vision and goals
- Agreeing measures and metrics
- Finding the edges of your experience
- Narrowing your focus for the future
- Aligning on terminology
- Checking your bias for existing or future solutions
Before getting into it, let’s use an analogy to understand why looking at the big picture is important. If I’m on the product team for Google Docs, I need to know about the vision and general practices for Google Drive — this helps me make decisions on how we should develop Google Docs and how it should sit within the wider ecosystem of Google Drive. It also helps us set our own vision and goals for Google Docs.
Setting a vision and goals
The first part of creating any new experience, or even iterating upon an existing one, is to take a step back and look at the big picture of what you are trying to achieve. Setting a clear vision and goals for your experience and how you’ll define success, is critical for later on in the process.
Big-picture thinking will serve as your north star and guiding light when you feel lost, it will give your team purpose and help them make decisions quickly.
Setting a vision, goals and success criteria doesn’t need to be a long, convoluted process. It can be as simple as a one-hour workshop to get the headlines on paper, which can then be iterated on later. Often we find clients have a vision in their mind — writing it down on a whiteboard (digital or physical) makes this vision visible to others and creates alignment.
Once a vision and goals have been set, make sure this is communicated to the team and refined, so that all can understand. One of the most important elements of setting the vision is ensuring that everyone on the team and business is aligned to it, providing a single common purpose.
Agreeing measures and metrics of success
One of the questions often asked at the start of the project is: “How will we know if we’ve been successful?” Often, this is answered with some high-level goals and success criteria, which is fine, but we also need to go deeper. It’s important to set and agree measures and metrics of success so you can use data to drive decision making.
Teams can create “measurement frameworks” to empirically prove their work has driven real customer and business value, or you can guide the team on how to pivot/adapt. If you’re in an agency, a measurement framework can be vital when demonstrating the value of an engagement; it’s also important for stakeholders to prove the value they’ve delivered for their business and their own stakeholders.
Metrics should be focused on business/user value and not on the volume of work. For example, good metrics can measure how a new service has reduced the time it takes a customer to buy a product or show an increase in the number of product upgrades to the premium models. Conversely, bad metrics for measuring a product’s value would be the number of story points a team has delivered or the number of features deployed to production. Although these metrics aren’t right for measuring product value, they can be useful for measuring velocity or projecting timelines, discussed later in “continuously managing scope”.
It’s important to tie the low-level metrics and measure of a product’s value to the overarching business impact targeted for a particular initiative. A good framework for this is described in Josh Seiden’s book “Outcomes Over Outputs” and helps to tie the two together.
The measurement framework can be an evolving document and should not be created in one big effort upfront.
Finding the edges of your experience
One of the tricks to speed is managing your circle of concern so you don’t get lost in the big picture. Putting boundaries around what you need to consider as part of the experience will allow your team to concentrate their efforts on where the value lies and not spin their wheels on low-value areas.
Setting boundaries for the team helps them focus, but the boundaries need to have balance. Setting a surface area too small might mean the team limits their understanding of the technological, customer or business domain which can ultimately lead to missed opportunities to create value quickly. In the early stages of looking at the big picture, the boundaries for the team should be wide but they should keep their research to a shallow depth to move at speed.
Where you set your boundaries also depends on the maturity of the overall product/service context. It can be easy to define the edges of the experience with products that are well known or their functionality can be easily predicted. It can be hard to define the boundaries of the experience when working with less well-defined product/service ecosystems, or when working with products/services that are particularly innovative or cutting edge. More time may need to be spent exploring the board context, capturing large amounts of data and then using this to narrow down the future boundaries for the experience.
The processes of creating artefacts such as service blueprints and high-level technical architectures are highly valuable in creating understanding and alignment on the experience big picture.
Narrowing your focus for the future
The big picture is great for giving the team a vast amount of context and understanding of where the product or service operates. However, one of the main purposes of looking at the bigger picture is to ultimately help you define what the smaller, more detailed picture should look like: redefining the experience edges or creating a smaller constrained area of the experience for the current or future teams to focus on.
Done correctly, it will allow the team to move at speed and with the confidence they are working on the highest value items for the experience.
Aligning on terminology
Often missed when understanding the big picture is aligning on domain language and terminology. If not done correctly, a vast amount of time can be lost due to innocent misunderstandings, individuals talking past each other, teams pulling in different directions or just having a different understanding of words. I’ve learned that sometimes understanding is easy, on other occasions it can take time, so be patient with each other and always be respectful, humble and human.
As consultants, we move between businesses, each with their own industry or domain-specific terminology, and I’ve seen many situations where misunderstandings occur. This isn’t anyone’s fault and understanding is a process like any other. Be open to taking on other people’s terminology and broadening your own lexicon, the best terminology is often what is standard for that industry.
Sometimes creating alignment can mean the client’s domain terminology also needs to be changed, this happens more often than you would realise but requires an open client and sometimes considerable effort to change already ingrained patterns.
Luckily, the path to understanding can be shortened with simple tools:
- A glossary of domain terminology — containing words/phrases with a related description to help align understanding.
- A conceptual domain model — detailing domain objects and their relationships helps to define core business concepts and constraints.
These assets should be built iteratively and often start out as sketches, sometimes incorrect, but serve as a discussion point to help drive alignment. Never underestimate the power of a picture, even two simply labelled boxes on a board can help drive clarity and understanding.
Checking your bias for existing or future solutions
We often design solutions based on our past projects, specialist skills, life experiences and unvalidated understanding of the requirements. This is natural and often helps us make decisions and guide solutions quickly. However, it’s important to check a bias towards a particular solution and make sure you’re not guiding it based on subjective opinions for a particular approach, requirement or solution.
Not checking your bias can send the team down the wrong path, wasting both time and money. During these early stages, you can follow a set of core principles to become more tech-agnostic. These principles will be discussed in our future article on picking the right tool for the job.
Conclusions
This article covered several key themes for how looking at the big picture can provide valuable information and context to the team, fuelling their decisions and setting them up for onward success. In summary…
- Align on your vision, goals and criteria for success
- Find the edges and boundaries of your experience, go broad, but not too broad and try not to go too deep unless you are confident you need to
- Set up future success by using what you’ve learned to narrow your future focus
- Align on terminology and domain language to mitigate time spent on confusion
- Take an unbiased view of the existing and future solutions
In the next article, we’ll look at how to create a truly lean MVP, ensuring the resulting build focuses on the right areas and that those areas deliver maximum value for the experience.
Notes:
This article is part of an overarching series aimed at people who develop digital products or services, either in-house or agency side, and have been frustrated by missed deadlines, poor output quality or the overall experience not delivering the value you hoped for.
The information discussed isn’t new or groundbreaking; however, it is generally talked about separately and in silo. These articles will provide a holistic and balanced view of the key focus areas to help teams move quickly while still delivering value.
It’s an iterative process to get all these practices and processes in place, so start small, experiment, persist with what works and take the learnings from what fails.
For a full introduction to the series please read the series introduction article.
Principle One: Look at the big picture, but don’t get lost in it
Principle Two: Create a true MVP (Part One)
Principle Two: Create a true MVP (Part Two)
Principle Three: Picking the right tools for the job
