How to improve remote meeting productivity in one sentence

Build a hypothesis to provide context

A person drawing a hierarchical diagram in a journal. There are words at the top of the diagram and arrows pointing down.
A person drawing a hierarchical diagram in a journal. There are words at the top of the diagram and arrows pointing down.
Photo by My Life Journal on Unsplash

This is a followup to the previous conversation where I had stepped into a minefield of a meeting. If you haven’t read it, you can read it here.

After navigating an emotional minefield of a meeting, I began to wonder why the product team had wasted so much time and energy trying to figure out what was going on.

I talked about misunderstanding the Why-How-What of the situation in the previous article, but that wasn’t the only factor that contributed to this.

The simple fact of the matter was that the business didn’t have a clear way of tracking progress at this stage.

We were still in “Sprint 0”, when different team members were taking different actions, and keep track of everything in a remote setting was hard.

So I built a one-sentence hypothesis to address these concerns at the beginning of the meeting.

Here’s the Why, the How, and the What of that process.

If your business organization is Agile or Lean-based, you might have seen an organizational struggle with one of its’ key tenets.

One of the key principles for both methods is to avoid documentation in favor of constant updates and building small batches of work, but the remote working situation has kind of thrown that out the window.

People are documenting things a lot more now, with some even emphasizing that it’s the key to working remotely.

And the reasons why are pretty clear: it’s to make sure that decisions, progress, and conversations don’t vanish once a remote meeting concludes.

Our normal way of tracking progress, like informal conversations and backlogs, are quickly becoming e-mail chains to try and make sure that anything said in meetings is documented.

So not only are things like agendas written down, but also the points of the meeting, backlog items, action items, and all of those progress trackers you thought you escaped with Agile.

In this sort of environment, wouldn’t it be easier if you addressed these things from the start?

Rather than forcing people to go through existing documentation to figure out where we are and how this presentation fits into the larger scheme, provide the context from the start.

By addressing why you’re doing something ahead of time, people can stay focused on what you’re presenting rather than why you’re presenting.

And one of the simplest ways of doing that is to build a hypothesis.

What’s the first thing you think of when I talk about a hypothesis?

Your first inclination may be of academia: whether it’s learning about the scientific method in 5th grade or reading graduate research studies, it seems to live in the theoretical realm.

You may think that a level of formality or requirements is needed, such as having clear independent and dependent variables, p-values, or other statistical data.

As a result, you may think that it’s less useful in business settings, where there’s a lot more ambiguity.

But I’m not talking about using the entire scientific method here: I’m simply talking about building a hypothesis.

A hypothesis is a tentative, testable answer to a scientific question. So how is that different than any other explanation?

A hypothesis also includes an explanation of why the answer may be correct.

Let’s look at two hypotheses, introduced in the book Designing with Data, to illustrate this:

For [user group(s)], if [change] then [effect] because [rationale], which will impact [measure].

We predict that [doing this/building this feature/creating this experience] for [these people/personas] will achieve [these outcomes] because of [these reasons]. We will know this is true when we see [this impact to our metric of interest].

In both of these, we’re not just addressing changes: we’re providing context on some of the major changes that might result from this, and tying our actions to a larger goal.

And establishing the common ground of a larger goal is something that your stakeholders may desperately need to avoid miscommunication.

Let’s say that you’re in the middle of doing research and testing, and you want to talk about the results.

You might use the hypothesis model to say something like this:

For [adults age 18–34], if [we change our default page to be mobile-focused] then we suspect we will [have higher engagement rates] because [more people in this age range are used to mobile sites], which will impact [Multiple unknown metrics at this time].

Now let’s look at what this hypothesis does for the Why-How-What of the situation.

Why are you doing research? We suspect that we will have higher engagement rates if we make certain changes, but we don’t know what metrics will be impacted by this change.

How are you going to do research? We will change the page to be mobile-first for adults 18–34 and measure this against our current system.

What did you do? This is where you would begin your presentation about the steps you took, the tests you ran, the results you got, actionable insights, etc.

This hypothesis concisely sums up the Why, the How, and What of the problem.

But more importantly, it simplifies the message enough so that people can understand it more easily.

Stakeholders might remember your presentation as “talking about trying mobile design with adults” rather than a random presentation that they’d have to go through their notes to remember.

Now let’s look at another example:

We predict that [building a chatbot feature] for [these unknown people/personas] will achieve [Increased user engagement] because of [these unknown reasons]. We will know this is true when we see [this impact on our metric of interest].

Why are you building this feature? We suspect that it will increase user engagement, but we’re not sure why. We also don’t know how it will impact our metrics.

How are you building this feature? We first need to establish who our target audience is, and then try and understand their motivations or benefits they would get from this chatbot feature.

What will you do? This will be where you be discussing the next steps.

If we were introducing this statement to our stakeholders, it quickly becomes clear what we don’t know. That means the next steps can be easily understood: we need to figure out who our users are, or we need to decide what our metric of interest is.

As a bonus, as we make progress throughout these steps, you can also re-introduce this hypothesis with a number of these blanks filled in.

Remote work meetings are a learning process, and one of the things that many people have to learn is communicating progress within the team settings.

I’ve talked about what can go wrong when the team doesn’t know the Why or How of a person’s actions.

But that’s a simple mistake that many may make as they’re trying to communicate their progress across different team members in a remote setting.

So if you want to make sure that you cover not only your actions but your reasoning and progress, then utilize this method of explanation to simplify where you are.

And you might just find that your meetings run much smoother.

I write about UX, Healthcare, and Productivity regularly. If you would like to hear about effectively communicating with this methodology, I’ve created an online course about Design Communication here.

Written by

Healthcare-focused UX designer and researcher. Creator of two online courses on design communication and UX research planning:

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store