I've now worked as a software engineer for 7 years across companies big and small from banking to BigTech to social media. In that time I've worked with dozens of teams on thousands of features, bugs, and product requests.

One of the biggest problems I've observed is product teams spending a lot of time / effort on things that aren't that important. Ultimately there's always more work to do than resources to do them so spending time on things that aren't the most important is a great way to ensure you never get to the important ones (and why I advise to Focus on Impact).

In this post we'll explore a simple method I use to prevent one of the most common causes of this waste - misunderstanding the incoming request.

Everything is a Hypothesis

Every incoming product request whether it's a feature, a bug, or a proposed long-term vision is a hypothesis about what the product is now, how it should work in the future, and why it's valuable to do that.

• The customer / user has a hypothesis about what they want to do, how they believe they can do it better, and what your product can do to help them
• The customer-facing people (could be sales or support or maybe it's someone on a product team) have a hypothesis about what the customer is trying to do, how the product currently works, and how they can evolve it into something that works well for the customer and the business
• The product people have a hypothesis about what the customer-facing people want, why they want it, and how they could build something to solve for it

The thing to call out here is that all of these are just hypotheses. They aren't facts as we don't actually have a way to prove these things. So we need to treat them as hypotheses - things we can and should test.

Moreover we can see how this chain of information passing quickly turns into a game of telephone - where one person starts by whispering a message X to their neighbor and the message is passed all the way back to the originator where they announce what the message is now vs the original. Spoiler alert - the end message is rarely the same as the original.

This means that even if the originating hypothesis was mostly correct, by the time it reaches the product people actually fulfilling it, it's often morphed a bit from its original form.

So how can we combat this and build better products?

Clear Hypotheses Highlight Unclear Problems

I can't guarantee anything about your outcomes. After all these are all just hypotheses and you've got to test those to determine whether they turn out to be true or not.

But I can offer a better system for playing this game of telephone so at least we're focused on the actual hypothesis (problem / request) that the business cares about rather than a morphed version that no one cares about (and therefore no amount of time / effort will make matter).

That system is to simply state your hypotheses clearly.

• What is the problem and who is having it?
• Why does this matter in the context of what the customer is doing and the business wants?
• What are the proposed ideas for solving it, if any? Does that actually solve the problem?

When we do this, we clearly extract the bits of information that most matter. We can then use this to check our own understanding of the hypothesis with those further up the information chain and those we collaborate with to validate early that this is an accurate representation of what we're thinking and whether it's true/false.

The way I like to do this is:

• When a request comes in -> frame it as a hypothesis and ask the requestor if that's correct. If not -> iterate with them til it's right
• Once we've aligned on the hypothesis -> validate it with available data / relevant stakeholders
• Before building anything -> frame it as a hypothesis and validate against the request / project it's supposed to solve for
• At each step of the way as you learn more about the context, problem, and solution and as you talk to people - check back with that hypothesis to see if it's the same / different

By doing this you get a lightweight signal for verifying you're still on course and whether that course still makes sense.

A Template for Clear Hypotheses

I do this a lot - for every request that comes in, every bug / feature I'm building, and especially for large projects we're considering spending a lot of time / effort on.

It serves as a simple, effective way to ensure everyone's aligned and highlight / call out mismatches early. When I first started doing this I was often surprised at the fundamental mismatches it uncovered - from context to base assumptions about how things worked.

Moreover I find having a clear hypothesis helps with context switching cause it provides everything you need to know to reload the context in which you're working.

The template I use is pretty simple and I've tweaked it over years of use to be as clear and concise as possible while covering the primary areas of misunderstanding. For small bugs / features you may just have one sentence per item but for large projects you may have a few bullet points with links to more fully capture the necessary context.

My Project Hypothesis Template

- TL;DR:
- Context
- Problem
- Impact
- Solutions

• TL;DR: A one-sentence summary of what you're doing - this helps people get context when they're only willing to skim (which happens to be most people).
• Context: Provide info on the context of the situation. Problems only make sense within context so providing this helps people understand where we're playing and why. For example connection issues in a hospital could be life or death whereas connection issues for my social media app could be a minor annoyance. Include - what are people trying to do and why.
• Problem: What is the problem people are having? Who is having that problem? This sets the stage for the thing we're going to try to solve.
• Impact: How big of an issue is this? It's important to know if this is life or death vs minor impact and if it affects all our users or just 1. Links / data is very helpful here!
• Solutions: There is never just one solution and usually the first solution you come up with is not the best one. I like to try to come up with at least 3 solutions to every problem and analyze their pros / cons cause often there's an even better solution out there if you combine the best of these.

Next

That's it - that's how I clarify all incoming product requests to ensure that I understand what the actual problem is and we're all on the same page wrt how impactful it is and how we want to go about solving it. It may seem a little robotic to do this at first but it becomes a lot more natural when you put it in your own words and I'm confident you'll uncover some surprisingly fundamental miscommunications after using this a few times.

If you liked this post you might also like:

• Stop wasting your time on Bad Startup Ideas
• 3 Tips to be an effective Software Engineer (with less work and more fun)
• Instagram's tech stack will surprise you