what is a product hypothesis statement

• Product Management

How to Generate and Validate Product Hypotheses

What is a product hypothesis.

A hypothesis is a testable statement that predicts the relationship between two or more variables. In product development, we generate hypotheses to validate assumptions about customer behavior, market needs, or the potential impact of product changes. These experimental efforts help us refine the user experience and get closer to finding a product-market fit.

Product hypotheses are a key element of data-driven product development and decision-making. Testing them enables us to solve problems more efficiently and remove our own biases from the solutions we put forward.

Here’s an example: ‘If we improve the page load speed on our website (variable 1), then we will increase the number of signups by 15% (variable 2).’ So if we improve the page load speed, and the number of signups increases, then our hypothesis has been proven. If the number did not increase significantly (or not at all), then our hypothesis has been disproven.

In general, product managers are constantly creating and testing hypotheses. But in the context of new product development , hypothesis generation/testing occurs during the validation stage, right after idea screening .

Now before we go any further, let’s get one thing straight: What’s the difference between an idea and a hypothesis?

Idea vs hypothesis

Innovation expert Michael Schrage makes this distinction between hypotheses and ideas – unlike an idea, a hypothesis comes with built-in accountability. “But what’s the accountability for a good idea?” Schrage asks. “The fact that a lot of people think it’s a good idea? That’s a popularity contest.” So, not only should a hypothesis be tested, but by its very nature, it can be tested.

At Railsware, we’ve built our product development services on the careful selection, prioritization, and validation of ideas. Here’s how we distinguish between ideas and hypotheses:

Idea: A creative suggestion about how we might exploit a gap in the market, add value to an existing product, or bring attention to our product. Crucially, an idea is just a thought. It can form the basis of a hypothesis but it is not necessarily expected to be proven or disproven.

• We should get an interview with the CEO of our company published on TechCrunch.
• Why don’t we redesign our website?
• The Coupler.io team should create video tutorials on how to export data from different apps, and publish them on YouTube.
• Why not add a new ‘email templates’ feature to our Mailtrap product?

Hypothesis: A way of framing an idea or assumption so that it is testable, specific, and aligns with our wider product/team/organizational goals.

Examples: 

• If we add a new ‘email templates’ feature to Mailtrap, we’ll see an increase in active usage of our email-sending API.
• Creating relevant video tutorials and uploading them to YouTube will lead to an increase in Coupler.io signups.
• If we publish an interview with our CEO on TechCrunch, 500 people will visit our website and 10 of them will install our product.

Now, it’s worth mentioning that not all hypotheses require testing . Sometimes, the process of creating hypotheses is just an exercise in critical thinking. And the simple act of analyzing your statement tells whether you should run an experiment or not. Remember: testing isn’t mandatory, but your hypotheses should always be inherently testable.

Let’s consider the TechCrunch article example again. In that hypothesis, we expect 500 readers to visit our product website, and a 2% conversion rate of those unique visitors to product users i.e. 10 people. But is that marginal increase worth all the effort? Conducting an interview with our CEO, creating the content, and collaborating with the TechCrunch content team – all of these tasks take time (and money) to execute. And by formulating that hypothesis, we can clearly see that in this case, the drawbacks (efforts) outweigh the benefits. So, no need to test it.

In a similar vein, a hypothesis statement can be a tool to prioritize your activities based on impact. We typically use the following criteria:

• The quality of impact
• The size of the impact
• The probability of impact

This lets us organize our efforts according to their potential outcomes – not the coolness of the idea, its popularity among the team, etc.

Now that we’ve established what a product hypothesis is, let’s discuss how to create one.

Start with a problem statement

Before you jump into product hypothesis generation, we highly recommend formulating a problem statement. This is a short, concise description of the issue you are trying to solve. It helps teams stay on track as they formalize the hypothesis and design the product experiments. It can also be shared with stakeholders to ensure that everyone is on the same page.

The statement can be worded however you like, as long as it’s actionable, specific, and based on data-driven insights or research. It should clearly outline the problem or opportunity you want to address.

Here’s an example: Our bounce rate is high (more than 90%) and we are struggling to convert website visitors into actual users. How might we improve site performance to boost our conversion rate?

How to generate product hypotheses

Now let’s explore some common, everyday scenarios that lead to product hypothesis generation. For our teams here at Railsware, it’s when:

• There’s a problem with an unclear root cause e.g. a sudden drop in one part of the onboarding funnel. We identify these issues by checking our product metrics or reviewing customer complaints.
• We are running ideation sessions on how to reach our goals (increase MRR, increase the number of users invited to an account, etc.)
• We are exploring growth opportunities e.g. changing a pricing plan, making product improvements , breaking into a new market.
• We receive customer feedback. For example, some users have complained about difficulties setting up a workspace within the product. So, we build a hypothesis on how to help them with the setup.

BRIDGES framework for ideation

When we are tackling a complex problem or looking for ways to grow the product, our teams use BRIDGeS – a robust decision-making and ideation framework. BRIDGeS makes our product discovery sessions more efficient. It lets us dive deep into the context of our problem so that we can develop targeted solutions worthy of testing.

Between 2-8 stakeholders take part in a BRIDGeS session. The ideation sessions are usually led by a product manager and can include other subject matter experts such as developers, designers, data analysts, or marketing specialists. You can use a virtual whiteboard such as Figjam or Miro (see our Figma template ) to record each colored note.

In the first half of a BRIDGeS session, participants examine the Benefits, Risks, Issues, and Goals of their subject in the ‘Problem Space.’ A subject is anything that is being described or dealt with; for instance, Coupler.io’s growth opportunities. Benefits are the value that a future solution can bring, Risks are potential issues they might face, Issues are their existing problems, and Goals are what the subject hopes to gain from the future solution. Each descriptor should have a designated color.

After we have broken down the problem using each of these descriptors, we move into the Solution Space. This is where we develop solution variations based on all of the benefits/risks/issues identified in the Problem Space (see the Uber case study for an in-depth example).

In the Solution Space, we start prioritizing those solutions and deciding which ones are worthy of further exploration outside of the framework – via product hypothesis formulation and testing, for example. At the very least, after the session, we will have a list of epics and nested tasks ready to add to our product roadmap.

How to write a product hypothesis statement

Across organizations, product hypothesis statements might vary in their subject, tone, and precise wording. But some elements never change. As we mentioned earlier, a hypothesis statement must always have two or more variables and a connecting factor.

1. Identify variables

Since these components form the bulk of a hypothesis statement, let’s start with a brief definition.

First of all, variables in a hypothesis statement can be split into two camps: dependent and independent. Without getting too theoretical, we can describe the independent variable as the cause, and the dependent variable as the effect . So in the Mailtrap example we mentioned earlier, the ‘add email templates feature’ is the cause i.e. the element we want to manipulate. Meanwhile, ‘increased usage of email sending API’ is the effect i.e the element we will observe.

Independent variables can be any change you plan to make to your product. For example, tweaking some landing page copy, adding a chatbot to the homepage, or enhancing the search bar filter functionality.

Dependent variables are usually metrics. Here are a few that we often test in product development:

• Number of sign-ups
• Number of purchases
• Activation rate (activation signals differ from product to product)
• Number of specific plans purchased
• Feature usage (API activation, for example)
• Number of active users

Bear in mind that your concept or desired change can be measured with different metrics. Make sure that your variables are well-defined, and be deliberate in how you measure your concepts so that there’s no room for misinterpretation or ambiguity.

For example, in the hypothesis ‘Users drop off because they find it hard to set up a project’ variables are poorly defined. Phrases like ‘drop off’ and ‘hard to set up’ are too vague. A much better way of saying it would be: If project automation rules are pre-defined (email sequence to responsible, scheduled tickets creation), we’ll see a decrease in churn. In this example, it’s clear which dependent variable has been chosen and why.

And remember, when product managers focus on delighting users and building something of value, it’s easier to market and monetize it. That’s why at Railsware, our product hypotheses often focus on how to increase the usage of a feature or product. If users love our product(s) and know how to leverage its benefits, we can spend less time worrying about how to improve conversion rates or actively grow our revenue, and more time enhancing the user experience and nurturing our audience.

2. Make the connection

The relationship between variables should be clear and logical. If it’s not, then it doesn’t matter how well-chosen your variables are – your test results won’t be reliable.

To demonstrate this point, let’s explore a previous example again: page load speed and signups.

Through prior research, you might already know that conversion rates are 3x higher for sites that load in 1 second compared to sites that take 5 seconds to load. Since there appears to be a strong connection between load speed and signups in general, you might want to see if this is also true for your product.

Here are some common pitfalls to avoid when defining the relationship between two or more variables:

Relationship is weak. Let’s say you hypothesize that an increase in website traffic will lead to an increase in sign-ups. This is a weak connection since website visitors aren’t necessarily motivated to use your product; there are more steps involved. A better example is ‘If we change the CTA on the pricing page, then the number of signups will increase.’ This connection is much stronger and more direct.

Relationship is far-fetched. This often happens when one of the variables is founded on a vanity metric. For example, increasing the number of social media subscribers will lead to an increase in sign-ups. However, there’s no particular reason why a social media follower would be interested in using your product. Oftentimes, it’s simply your social media content that appeals to them (and your audience isn’t interested in a product).

Variables are co-dependent. Variables should always be isolated from one another. Let’s say we removed the option “Register with Google” from our app. In this case, we can expect fewer users with Google workspace accounts to register. Obviously, it’s because there’s a direct dependency between variables (no registration with Google→no users with Google workspace accounts).

3. Set validation criteria

First, build some confirmation criteria into your statement . Think in terms of percentages (e.g. increase/decrease by 5%) and choose a relevant product metric to track e.g. activation rate if your hypothesis relates to onboarding. Consider that you don’t always have to hit the bullseye for your hypothesis to be considered valid. Perhaps a 3% increase is just as acceptable as a 5% one. And it still proves that a connection between your variables exists.

Secondly, you should also make sure that your hypothesis statement is realistic . Let’s say you have a hypothesis that ‘If we show users a banner with our new feature, then feature usage will increase by 10%.’ A few questions to ask yourself are: Is 10% a reasonable increase, based on your current feature usage data? Do you have the resources to create the tests (experimenting with multiple variations, distributing on different channels: in-app, emails, blog posts)?

Null hypothesis and alternative hypothesis

In statistical research, there are two ways of stating a hypothesis: null or alternative. But this scientific method has its place in hypothesis-driven development too…

Alternative hypothesis: A statement that you intend to prove as being true by running an experiment and analyzing the results. Hint: it’s the same as the other hypothesis examples we’ve described so far.

Example: If we change the landing page copy, then the number of signups will increase.

Null hypothesis: A statement you want to disprove by running an experiment and analyzing the results. It predicts that your new feature or change to the user experience will not have the desired effect.

Example: The number of signups will not increase if we make a change to the landing page copy.

What’s the point? Well, let’s consider the phrase ‘innocent until proven guilty’ as a version of a null hypothesis. We don’t assume that there is any relationship between the ‘defendant’ and the ‘crime’ until we have proof. So, we run a test, gather data, and analyze our findings — which gives us enough proof to reject the null hypothesis and validate the alternative. All of this helps us to have more confidence in our results.

Now that you have generated your hypotheses, and created statements, it’s time to prepare your list for testing.

Prioritizing hypotheses for testing

Not all hypotheses are created equal. Some will be essential to your immediate goal of growing the product e.g. adding a new data destination for Coupler.io. Others will be based on nice-to-haves or small fixes e.g. updating graphics on the website homepage.

Prioritization helps us focus on the most impactful solutions as we are building a product roadmap or narrowing down the backlog . To determine which hypotheses are the most critical, we use the MoSCoW framework. It allows us to assign a level of urgency and importance to each product hypothesis so we can filter the best 3-5 for testing.

MoSCoW is an acronym for Must-have, Should-have, Could-have, and Won’t-have. Here’s a breakdown:

• Must-have – hypotheses that must be tested, because they are strongly linked to our immediate project goals.
• Should-have – hypotheses that are closely related to our immediate project goals, but aren’t the top priority.
• Could-have – hypotheses of nice-to-haves that can wait until later for testing. 
• Won’t-have – low-priority hypotheses that we may or may not test later on when we have more time.

How to test product hypotheses

Once you have selected a hypothesis, it’s time to test it. This will involve running one or more product experiments in order to check the validity of your claim.

The tricky part is deciding what type of experiment to run, and how many. Ultimately, this all depends on the subject of your hypothesis – whether it’s a simple copy change or a whole new feature. For instance, it’s not necessary to create a clickable prototype for a landing page redesign. In that case, a user-wide update would do.

On that note, here are some of the approaches we take to hypothesis testing at Railsware:

A/B testing

A/B or split testing involves creating two or more different versions of a webpage/feature/functionality and collecting information about how users respond to them.

Let’s say you wanted to validate a hypothesis about the placement of a search bar on your application homepage. You could design an A/B test that shows two different versions of that search bar’s placement to your users (who have been split equally into two camps: a control group and a variant group). Then, you would choose the best option based on user data. A/B tests are suitable for testing responses to user experience changes, especially if you have more than one solution to test.

Prototyping

When it comes to testing a new product design, prototyping is the method of choice for many Lean startups and organizations. It’s a cost-effective way of collecting feedback from users, fast, and it’s possible to create prototypes of individual features too. You may take this approach to hypothesis testing if you are working on rolling out a significant new change e.g adding a brand-new feature, redesigning some aspect of the user flow, etc. To control costs at this point in the new product development process , choose the right tools — think Figma for clickable walkthroughs or no-code platforms like Bubble.

Deliveroo feature prototype example

Let’s look at how feature prototyping worked for the food delivery app, Deliveroo, when their product team wanted to ‘explore personalized recommendations, better filtering and improved search’ in 2018. To begin, they created a prototype of the customer discovery feature using web design application, Framer.

One of the most important aspects of this feature prototype was that it contained live data — real restaurants, real locations. For test users, this made the hypothetical feature feel more authentic. They were seeing listings and recommendations for real restaurants in their area, which helped immerse them in the user experience, and generate more honest and specific feedback. Deliveroo was then able to implement this feedback in subsequent iterations.

Asking your users

Interviewing customers is an excellent way to validate product hypotheses. It’s a form of qualitative testing that, in our experience, produces better insights than user surveys or general user research. Sessions are typically run by product managers and involve asking  in-depth interview questions  to one customer at a time. They can be conducted in person or online (through a virtual call center , for instance) and last anywhere between 30 minutes to 1 hour.

Although CustDev interviews may require more effort to execute than other tests (the process of finding participants, devising questions, organizing interviews, and honing interview skills can be time-consuming), it’s still a highly rewarding approach. You can quickly validate assumptions by asking customers about their pain points, concerns, habits, processes they follow, and analyzing how your solution fits into all of that.

Wizard of Oz

The Wizard of Oz approach is suitable for gauging user interest in new features or functionalities. It’s done by creating a prototype of a fake or future feature and monitoring how your customers or test users interact with it.

For example, you might have a hypothesis that your number of active users will increase by 15% if you introduce a new feature. So, you design a new bare-bones page or simple button that invites users to access it. But when they click on the button, a pop-up appears with a message such as ‘coming soon.’

By measuring the frequency of those clicks, you could learn a lot about the demand for this new feature/functionality. However, while these tests can deliver fast results, they carry the risk of backfiring. Some customers may find fake features misleading, making them less likely to engage with your product in the future.

User-wide updates

One of the speediest ways to test your hypothesis is by rolling out an update for all users. It can take less time and effort to set up than other tests (depending on how big of an update it is). But due to the risk involved, you should stick to only performing these kinds of tests on small-scale hypotheses. Our teams only take this approach when we are almost certain that our hypothesis is valid.

For example, we once had an assumption that the name of one of Mailtrap ’s entities was the root cause of a low activation rate. Being an active Mailtrap customer meant that you were regularly sending test emails to a place called ‘Demo Inbox.’ We hypothesized that the name was confusing (the word ‘demo’ implied it was not the main inbox) and this was preventing new users from engaging with their accounts. So, we updated the page, changed the name to ‘My Inbox’ and added some ‘to-do’ steps for new users. We saw an increase in our activation rate almost immediately, validating our hypothesis.

Feature flags

Creating feature flags involves only releasing a new feature to a particular subset or small percentage of users. These features come with a built-in kill switch; a piece of code that can be executed or skipped, depending on who’s interacting with your product.

Since you are only showing this new feature to a selected group, feature flags are an especially low-risk method of testing your product hypothesis (compared to Wizard of Oz, for example, where you have much less control). However, they are also a little bit more complex to execute than the others — you will need to have an actual coded product for starters, as well as some technical knowledge, in order to add the modifiers ( only when… ) to your new coded feature.

Let’s revisit the landing page copy example again, this time in the context of testing.

So, for the hypothesis ‘If we change the landing page copy, then the number of signups will increase,’ there are several options for experimentation. We could share the copy with a small sample of our users, or even release a user-wide update. But A/B testing is probably the best fit for this task. Depending on our budget and goal, we could test several different pieces of copy, such as:

• The current landing page copy
• Copy that we paid a marketing agency 10 grand for
• Generic copy we wrote ourselves, or removing most of the original copy – just to see how making even a small change might affect our numbers.

Remember, every hypothesis test must have a reasonable endpoint. The exact length of the test will depend on the type of feature/functionality you are testing, the size of your user base, and how much data you need to gather. Just make sure that the experiment running time matches the hypothesis scope. For instance, there is no need to spend 8 weeks experimenting with a piece of landing page copy. That timeline is more appropriate for say, a Wizard of Oz feature.

Recording hypotheses statements and test results

Finally, it’s time to talk about where you will write down and keep track of your hypotheses. Creating a single source of truth will enable you to track all aspects of hypothesis generation and testing with ease.

At Railsware, our product managers create a document for each individual hypothesis, using tools such as Coda or Google Sheets. In that document, we record the hypothesis statement, as well as our plans, process, results, screenshots, product metrics, and assumptions.

We share this document with our team and stakeholders, to ensure transparency and invite feedback. It’s also a resource we can refer back to when we are discussing a new hypothesis — a place where we can quickly access information relating to a previous test.

Understanding test results and taking action

The other half of validating product hypotheses involves evaluating data and drawing reasonable conclusions based on what you find. We do so by analyzing our chosen product metric(s) and deciding whether there is enough data available to make a solid decision. If not, we may extend the test’s duration or run another one. Otherwise, we move forward. An experimental feature becomes a real feature, a chatbot gets implemented on the customer support page, and so on.

Something to keep in mind: the integrity of your data is tied to how well the test was executed, so here are a few points to consider when you are testing and analyzing results:

Gather and analyze data carefully. Ensure that your data is clean and up-to-date when running quantitative tests and tracking responses via analytics dashboards. If you are doing customer interviews, make sure to record the meetings (with consent) so that your notes will be as accurate as possible.

Conduct the right amount of product experiments. It can take more than one test to determine whether your hypothesis is valid or invalid. However, don’t waste too much time experimenting in the hopes of getting the result you want. Know when to accept the evidence and move on.

Choose the right audience segment. Don’t cast your net too wide. Be specific about who you want to collect data from prior to running the test. Otherwise, your test results will be misleading and you won’t learn anything new.

Watch out for bias. Avoid confirmation bias at all costs. Don’t make the mistake of including irrelevant data just because it bolsters your results. For example, if you are gathering data about how users are interacting with your product Monday-Friday, don’t include weekend data just because doing so would alter the data and ‘validate’ your hypothesis.

• Not all failed hypotheses should be treated as losses. Even if you didn’t get the outcome you were hoping for, you may still have improved your product. Let’s say you implemented SSO authentication for premium users, but unfortunately, your free users didn’t end up switching to premium plans. In this case, you still added value to the product by streamlining the login process for paying users.
• Yes, taking a hypothesis-driven approach to product development is important. But remember, you don’t have to test everything . Use common sense first. For example, if your website copy is confusing and doesn’t portray the value of the product, then you should still strive to replace it with better copy – regardless of how this affects your numbers in the short term.

Wrapping Up

The process of generating and validating product hypotheses is actually pretty straightforward once you’ve got the hang of it. All you need is a valid question or problem, a testable statement, and a method of validation. Sure, hypothesis-driven development requires more of a time commitment than just ‘giving it a go.’ But ultimately, it will help you tune the product to the wants and needs of your customers.

If you share our data-driven approach to product development and engineering, check out our services page to learn more about how we work with our clients!

How to Generate and Validate Product Hypotheses

Every product owner knows that it takes effort to build something that'll cater to user needs. You'll have to make many tough calls if you wish to grow the company and evolve the product so it delivers more value. But how do you decide what to change in the product, your marketing strategy, or the overall direction to succeed? And how do you make a product that truly resonates with your target audience?

There are many unknowns in business, so many fundamental decisions start from a simple "what if?". But they can't be based on guesses, as you need some proof to fill in the blanks reasonably.

Because there's no universal recipe for successfully building a product, teams collect data, do research, study the dynamics, and generate hypotheses according to the given facts. They then take corresponding actions to find out whether they were right or wrong, make conclusions, and most likely restart the process again.

On this page, we thoroughly inspect product hypotheses. We'll go over what they are, how to create hypothesis statements and validate them, and what goes after this step.

What Is a Hypothesis in Product Management?

A hypothesis in product development and product management is a statement or assumption about the product, planned feature, market, or customer (e.g., their needs, behavior, or expectations) that you can put to the test, evaluate, and base your further decisions on . This may, for instance, regard the upcoming product changes as well as the impact they can result in.

A hypothesis implies that there is limited knowledge. Hence, the teams need to undergo testing activities to validate their ideas and confirm whether they are true or false.

Hypotheses guide the product development process and may point at important findings to help build a better product that'll serve user needs. In essence, teams create hypothesis statements in an attempt to improve the offering, boost engagement, increase revenue, find product-market fit quicker, or for other business-related reasons.

It's sort of like an experiment with trial and error, yet, it is data-driven and should be unbiased . This means that teams don't make assumptions out of the blue. Instead, they turn to the collected data, conducted market research , and factual information, which helps avoid completely missing the mark. The obtained results are then carefully analyzed and may influence decision-making.

Such experiments backed by data and analysis are an integral aspect of successful product development and allow startups or businesses to dodge costly startup mistakes .

‍ When do teams create hypothesis statements and validate them? To some extent, hypothesis testing is an ongoing process to work on constantly. It may occur during various product development life cycle stages, from early phases like initiation to late ones like scaling.

In any event, the key here is learning how to generate hypothesis statements and validate them effectively. We'll go over this in more detail later on.

Idea vs. Hypothesis Compared

You might be wondering whether ideas and hypotheses are the same thing. Well, there are a few distinctions.

An idea is simply a suggested proposal. Say, a teammate comes up with something you can bring to life during a brainstorming session or pitches in a suggestion like "How about we shorten the checkout process?". You can jot down such ideas and then consider working on them if they'll truly make a difference and improve the product, strategy, or result in other business benefits. Ideas may thus be used as the hypothesis foundation when you decide to prove a concept.

A hypothesis is the next step, when an idea gets wrapped with specifics to become an assumption that may be tested. As such, you can refine the idea by adding details to it. The previously mentioned idea can be worded into a product hypothesis statement like: "The cart abandonment rate is high, and many users flee at checkout. But if we shorten the checkout process by cutting down the number of steps to only two and get rid of four excessive fields, we'll simplify the user journey, boost satisfaction, and may get up to 15% more completed orders".

A hypothesis is something you can test in an attempt to reach a certain goal. Testing isn't obligatory in this scenario, of course, but the idea may be tested if you weigh the pros and cons and decide that the required effort is worth a try. We'll explain how to create hypothesis statements next.

How to Generate a Hypothesis for a Product

The last thing those developing a product want is to invest time and effort into something that won't bring any visible results, fall short of customer expectations, or won't live up to their needs. Therefore, to increase the chances of achieving a successful outcome and product-led growth , teams may need to revisit their product development approach by optimizing one of the starting points of the process: learning to make reasonable product hypotheses.

If the entire procedure is structured, this may assist you during such stages as the discovery phase and raise the odds of reaching your product goals and setting your business up for success. Yet, what's the entire process like?

• It all starts with identifying an existing problem . Is there a product area that's experiencing a downfall, a visible trend, or a market gap? Are users often complaining about something in their feedback? Or is there something you're willing to change (say, if you aim to get more profit, increase engagement, optimize a process, expand to a new market, or reach your OKRs and KPIs faster)?
• Teams then need to work on formulating a hypothesis . They put the statement into concise and short wording that describes what is expected to achieve. Importantly, it has to be relevant, actionable, backed by data, and without generalizations.
• Next, they have to test the hypothesis by running experiments to validate it (for instance, via A/B or multivariate testing, prototyping, feedback collection, or other ways).
• Then, the obtained results of the test must be analyzed . Did one element or page version outperform the other? Depending on what you're testing, you can look into various merits or product performance metrics (such as the click rate, bounce rate, or the number of sign-ups) to assess whether your prediction was correct.
• Finally, the teams can make conclusions that could lead to data-driven decisions. For example, they can make corresponding changes or roll back a step.

How Else Can You Generate Product Hypotheses?

Such processes imply sharing ideas when a problem is spotted by digging deep into facts and studying the possible risks, goals, benefits, and outcomes. You may apply various MVP tools like (FigJam, Notion, or Miro) that were designed to simplify brainstorming sessions, systemize pitched suggestions, and keep everyone organized without losing any ideas.

Predictive product analysis can also be integrated into this process, leveraging data and insights to anticipate market trends and consumer preferences, thus enhancing decision-making and product development strategies. This approach fosters a more proactive and informed approach to innovation, ensuring products are not only relevant but also resonate with the target audience, ultimately increasing their chances of success in the market.

Besides, you can settle on one of the many frameworks that facilitate decision-making processes , ideation phases, or feature prioritization . Such frameworks are best applicable if you need to test your assumptions and structure the validation process. These are a few common ones if you're looking toward a systematic approach:

• Business Model Canvas (used to establish the foundation of the business model and helps find answers to vitals like your value proposition, finding the right customer segment, or the ways to make revenue);
• Lean Startup framework (the lean startup framework uses a diagram-like format for capturing major processes and can be handy for testing various hypotheses like how much value a product brings or assumptions on personas, the problem, growth, etc.);
• Design Thinking Process (is all about interactive learning and involves getting an in-depth understanding of the customer needs and pain points, which can be formulated into hypotheses followed by simple prototypes and tests).

Need a hand with product development?

Upsilon's team of pros is ready to share our expertise in building tech products.

How to Make a Hypothesis Statement for a Product

Once you've indicated the addressable problem or opportunity and broken down the issue in focus, you need to work on formulating the hypotheses and associated tasks. By the way, it works the same way if you want to prove that something will be false (a.k.a null hypothesis).

If you're unsure how to write a hypothesis statement, let's explore the essential steps that'll set you on the right track.

Step 1: Allocate the Variable Components

Product hypotheses are generally different for each case, so begin by pinpointing the major variables, i.e., the cause and effect . You'll need to outline what you think is supposed to happen if a change or action gets implemented.

Put simply, the "cause" is what you're planning to change, and the "effect" is what will indicate whether the change is bringing in the expected results. Falling back on the example we brought up earlier, the ineffective checkout process can be the cause, while the increased percentage of completed orders is the metric that'll show the effect.

Make sure to also note such vital points as:

• what the problem and solution are;
• what are the benefits or the expected impact/successful outcome;
• which user group is affected;
• what are the risks;
• what kind of experiments can help test the hypothesis;
• what can measure whether you were right or wrong.

Step 2: Ensure the Connection Is Specific and Logical

Mind that generic connections that lack specifics will get you nowhere. So if you're thinking about how to word a hypothesis statement, make sure that the cause and effect include clear reasons and a logical dependency .

Think about what can be the precise and link showing why A affects B. In our checkout example, it could be: fewer steps in the checkout and the removed excessive fields will speed up the process, help avoid confusion, irritate users less, and lead to more completed orders. That's much more explicit than just stating the fact that the checkout needs to be changed to get more completed orders.

Step 3: Decide on the Data You'll Collect

Certainly, multiple things can be used to measure the effect. Therefore, you need to choose the optimal metrics and validation criteria that'll best envision if you're moving in the right direction.

If you need a tip on how to create hypothesis statements that won't result in a waste of time, try to avoid vagueness and be as specific as you can when selecting what can best measure and assess the results of your hypothesis test. The criteria must be measurable and tied to the hypotheses . This can be a realistic percentage or number (say, you expect a 15% increase in completed orders or 2x fewer cart abandonment cases during the checkout phase).

Once again, if you're not realistic, then you might end up misinterpreting the results. Remember that sometimes an increase that's even as little as 2% can make a huge difference, so why make 50% the merit if it's not achievable in the first place?

Step 4: Settle on the Sequence

It's quite common that you'll end up with multiple product hypotheses. Some are more important than others, of course, and some will require more effort and input.

Therefore, just as with the features on your product development roadmap , prioritize your hypotheses according to their impact and importance. Then, group and order them, especially if the results of some hypotheses influence others on your list.

Product Hypothesis Examples

To demonstrate how to formulate your assumptions clearly, here are several more apart from the example of a hypothesis statement given above:

• Adding a wishlist feature to the cart with the possibility to send a gift hint to friends via email will increase the likelihood of making a sale and bring in additional sign-ups.
• Placing a limited-time promo code banner stripe on the home page will increase the number of sales in March.
• Moving up the call to action element on the landing page and changing the button text will increase the click-through rate twice.
• By highlighting a new way to use the product, we'll target a niche customer segment (i.e., single parents under 30) and acquire 5% more leads. 

How to Validate Hypothesis Statements: The Process Explained

There are multiple options when it comes to validating hypothesis statements. To get appropriate results, you have to come up with the right experiment that'll help you test the hypothesis. You'll need a control group or people who represent your target audience segments or groups to participate (otherwise, your results might not be accurate).

‍ What can serve as the experiment you may run? Experiments may take tons of different forms, and you'll need to choose the one that clicks best with your hypothesis goals (and your available resources, of course). The same goes for how long you'll have to carry out the test (say, a time period of two months or as little as two weeks). Here are several to get you started.

Feedback and User Testing

Talking to users, potential customers, or members of your own online startup community can be another way to test your hypotheses. You may use surveys, questionnaires, or opt for more extensive interviews to validate hypothesis statements and find out what people think. This assumption validation approach involves your existing or potential users and might require some additional time, but can bring you many insights.

Conduct A/B or Multivariate Tests

One of the experiments you may develop involves making more than one version of an element or page to see which option resonates with the users more. As such, you can have a call to action block with different wording or play around with the colors, imagery, visuals, and other things.

To run such split experiments, you can apply tools like VWO that allows to easily construct alternative designs and split what your users see (e.g., one half of the users will see version one, while the other half will see version two). You can track various metrics and apply heatmaps, click maps, and screen recordings to learn more about user response and behavior. Mind, though, that the key to such tests is to get as many users as you can give the tests time. Don't jump to conclusions too soon or if very few people participated in your experiment.

Build Prototypes and Fake Doors

Demos and clickable prototypes can be a great way to save time and money on costly feature or product development. A prototype also allows you to refine the design. However, they can also serve as experiments for validating hypotheses, collecting data, and getting feedback.

For instance, if you have a new feature in mind and want to ensure there is interest, you can utilize such MVP types as fake doors . Make a short demo recording of the feature and place it on your landing page to track interest or test how many people sign up.

Usability Testing

Similarly, you can run experiments to observe how users interact with the feature, page, product, etc. Usually, such experiments are held on prototype testing platforms with a focus group representing your target visitors. By showing a prototype or early version of the design to users, you can view how people use the solution, where they face problems, or what they don't understand. This may be very helpful if you have hypotheses regarding redesigns and user experience improvements before you move on from prototype to MVP development.

You can even take it a few steps further and build a barebone feature version that people can really interact with, yet you'll be the one behind the curtain to make it happen. There were many MVP examples when companies applied Wizard of Oz or concierge MVPs to validate their hypotheses.

Or you can actually develop some functionality but release it for only a limited number of people to see. This is referred to as a feature flag , which can show really specific results but is effort-intensive. 

What Comes After Hypothesis Validation?

Analysis is what you move on to once you've run the experiment. This is the time to review the collected data, metrics, and feedback to validate (or invalidate) the hypothesis.

You have to evaluate the experiment's results to determine whether your product hypotheses were valid or not. For example, if you were testing two versions of an element design, color scheme, or copy, look into which one performed best.

It is crucial to be certain that you have enough data to draw conclusions, though, and that it's accurate and unbiased . Because if you don't, this may be a sign that your experiment needs to be run for some additional time, be altered, or held once again. You won't want to make a solid decision based on uncertain or misleading results, right?

• If the hypothesis was supported , proceed to making corresponding changes (such as implementing a new feature, changing the design, rephrasing your copy, etc.). Remember that your aim was to learn and iterate to improve.
• If your hypothesis was proven false , think of it as a valuable learning experience. The main goal is to learn from the results and be able to adjust your processes accordingly. Dig deep to find out what went wrong, look for patterns and things that may have skewed the results. But if all signs show that you were wrong with your hypothesis, accept this outcome as a fact, and move on. This can help you make conclusions on how to better formulate your product hypotheses next time. Don't be too judgemental, though, as a failed experiment might only mean that you need to improve the current hypothesis, revise it, or create a new one based on the results of this experiment, and run the process once more.

On another note, make sure to record your hypotheses and experiment results . Some companies use CRMs to jot down the key findings, while others use something as simple as Google Docs. Either way, this can be your single source of truth that can help you avoid running the same experiments or allow you to compare results over time.

Have doubts about how to bring your product to life?

Upsilon's team of pros can help you build a product most optimally.

Final Thoughts on Product Hypotheses

The hypothesis-driven approach in product development is a great way to avoid uncalled-for risks and pricey mistakes. You can back up your assumptions with facts, observe your target audience's reactions, and be more certain that this move will deliver value.

However, this only makes sense if the validation of hypothesis statements is backed by relevant data that'll allow you to determine whether the hypothesis is valid or not. By doing so, you can be certain that you're developing and testing hypotheses to accelerate your product management and avoiding decisions based on guesswork.

Certainly, a failed experiment may bring you just as much knowledge and findings as one that succeeds. Teams have to learn from their mistakes, boost their hypothesis generation and testing knowledge, and make improvements according to the results of their experiments. This is an ongoing process, of course, as no product can grow if it isn't iterated and improved.

If you're only planning to or are currently building a product, Upsilon can lend you a helping hand. Our team has years of experience providing product development services for growth-stage startups and building MVPs for early-stage businesses , so you can use our expertise and knowledge to dodge many mistakes. Don't be shy to contact us to discuss your needs! 

How to Conduct a Product Experiment: Tips, Tools, and Process

How to Build an AI App: The Ultimate Guide

Best Startup Podcasts to Grow and Inspire Your Business

Never miss an update.

4.7 STARS ON G2

Analyze your mobile app for free. No credit card required. 100k sessions.

SHARE THIS POST

Product best practices

Product hypothesis - a guide to create meaningful hypotheses.

13 December, 2023

Growth Manager

Data-driven development is no different than a scientific experiment. You repeatedly form hypotheses, test them, and either implement (or reject) them based on the results. It’s a proven system that leads to better apps and happier users.

Let’s get started.

What is a product hypothesis?

A product hypothesis is an educated guess about how a change to a product will impact important metrics like revenue or user engagement. It's a testable statement that needs to be validated to determine its accuracy.

The most common format for product hypotheses is “If… than…”:

“If we increase the font size on our homepage, then more customers will convert.”

“If we reduce form fields from 5 to 3, then more users will complete the signup process.”

At UXCam, we believe in a data-driven approach to developing product features. Hypotheses provide an effective way to structure development and measure results so you can make informed decisions about how your product evolves over time.

Take PlaceMakers , for example.

PlaceMakers faced challenges with their app during the COVID-19 pandemic. Due to supply chain shortages, stock levels were not being updated in real-time, causing customers to add unavailable products to their baskets. The team added a “Constrained Product” label, but this caused sales to plummet.

The team then turned to UXCam’s session replays and heatmaps to investigate, and hypothesized that their messaging for constrained products was too strong. The team redesigned the messaging with a more positive approach, and sales didn’t just recover—they doubled.

Types of product hypothesis

1. counter-hypothesis.

A counter-hypothesis is an alternative proposition that challenges the initial hypothesis. It’s used to test the robustness of the original hypothesis and make sure that the product development process considers all possible scenarios. 

For instance, if the original hypothesis is “Reducing the sign-up steps from 3 to 1 will increase sign-ups by 25% for new visitors after 1,000 visits to the sign-up page,” a counter-hypothesis could be “Reducing the sign-up steps will not significantly affect the sign-up rate.

2. Alternative hypothesis

An alternative hypothesis predicts an effect in the population. It’s the opposite of the null hypothesis, which states there’s no effect. 

For example, if the null hypothesis is “improving the page load speed on our mobile app will not affect the number of sign-ups,” the alternative hypothesis could be “improving the page load speed on our mobile app will increase the number of sign-ups by 15%.”

3. Second-order hypothesis

Second-order hypotheses are derived from the initial hypothesis and provide more specific predictions. 

For instance, “if the initial hypothesis is Improving the page load speed on our mobile app will increase the number of sign-ups,” a second-order hypothesis could be “Improving the page load speed on our mobile app will increase the number of sign-ups.”

Why is a product hypothesis important?

Guided product development.

A product hypothesis serves as a guiding light in the product development process. In the case of PlaceMakers, the product owner’s hypothesis that users would benefit from knowing the availability of items upfront before adding them to the basket helped their team focus on the most critical aspects of the product. It ensured that their efforts were directed towards features and improvements that have the potential to deliver the most value. 

Improved efficiency

Product hypotheses enable teams to solve problems more efficiently and remove biases from the solutions they put forward. By testing the hypothesis, PlaceMakers aimed to improve efficiency by addressing the issue of stock levels not being updated in real-time and customers adding unavailable products to their baskets.

Risk mitigation

By validating assumptions before building the product, teams can significantly reduce the risk of failure. This is particularly important in today’s fast-paced, highly competitive business environment, where the cost of failure can be high.

Validating assumptions through the hypothesis helped mitigate the risk of failure for PlaceMakers, as they were able to identify and solve the issue within a three-day period.

Data-driven decision-making

Product hypotheses are a key element of data-driven product development and decision-making. They provide a solid foundation for making informed, data-driven decisions, which can lead to more effective and successful product development strategies. 

The use of UXCam's Session Replay and Heatmaps features provided valuable data for data-driven decision-making, allowing PlaceMakers to quickly identify the problem and revise their messaging approach, leading to a doubling of sales.

How to create a great product hypothesis

Map important user flows

Identify any bottlenecks

Look for interesting behavior patterns

Turn patterns into hypotheses

Step 1 - Map important user flows

A good product hypothesis starts with an understanding of how users more around your product—what paths they take, what features they use, how often they return, etc. Before you can begin hypothesizing, it’s important to map out key user flows and journey maps that will help inform your hypothesis.

To do that, you’ll need to use a monitoring tool like UXCam .

UXCam integrates with your app through a lightweight SDK and automatically tracks every user interaction using tagless autocapture. That leads to tons of data on user behavior that you can use to form hypotheses.

At this stage, there are two specific visualizations that are especially helpful:

Funnels : Funnels are great for identifying drop off points and understanding which steps in a process, transition or journey lead to success.

In other words, you’re using these two tools to define key in-app flows and to measure the effectiveness of these flows (in that order).

Average time to conversion in highlights bar.

Step 2 - Identify any bottlenecks

Once you’ve set up monitoring and have started collecting data, you’ll start looking for bottlenecks—points along a key app flow that are tripping users up. At every stage in a funnel, there’s going to be dropoffs, but too many dropoffs can be a sign of a problem.

UXCam makes it easy to spot dropoffs by displaying them visually in every funnel. While there’s no benchmark for when you should be concerned, anything above a 10% dropoff could mean that further investigation is needed.

How do you investigate? By zooming in.

Step 3 - Look for interesting behavior patterns

At this stage, you’ve noticed a concerning trend and are zooming in on individual user experiences to humanize the trend and add important context.

The best way to do this is with session replay tools and event analytics. With a tool like UXCam, you can segment app data to isolate sessions that fit the trend. You can then investigate real user sessions by watching videos of their experience or by looking into their event logs. This helps you see exactly what caused the behavior you’re investigating.

For example, let’s say you notice that 20% of users who add an item to their cart leave the app about 5 minutes later. You can use session replay to look for the behavioral patterns that lead up to users leaving—such as how long they linger on a certain page or if they get stuck in the checkout process.

Step 4 - Turn patterns into hypotheses

Once you’ve checked out a number of user sessions, you can start to craft a product hypothesis.

This usually takes the form of an “If… then…” statement, like:

“If we optimize the checkout process for mobile users, then more customers will complete their purchase.”

These hypotheses can be tested using A/B testing and other user research tools to help you understand if your changes are having an impact on user behavior.

Product hypothesis emphasizes the importance of formulating clear and testable hypotheses when developing a product. It highlights that a well-defined hypothesis can guide the product development process, align stakeholders, and minimize uncertainty.

UXCam arms product teams with all the tools they need to form meaningful hypotheses that drive development in a positive direction. Put your app’s data to work and start optimizing today— sign up for a free account .

You might also be interested in these;

Product experimentation framework for mobile product teams

7 Best AB testing tools for mobile apps

A practical guide to product experimentation

5 Best product experimentation tools & software

How to use data to challenge the HiPPO

Ardent technophile exploring the world of mobile app product management at UXCam.

Get the latest from UXCam

Stay up-to-date with UXCam's latest features, insights, and industry news for an exceptional user experience.

Related articles

What is product engagement (and how to improve it).

Learn the essence of product engagement and explore strategies to enhance user interaction, fostering loyalty and driving...

5 Examples of Product Strategy and How to Create One

Learn how to create a winning plan for your own product with these five inspiring examples of product...

Product Management

12 best product analytics tools and software 2024.

Discover the top product analytics tools and learn how to extract valuable insights, optimize performance, and drive growth with these powerful...

Jonas Kurzweg

Growth Lead

Shipping Your Product in Iterations: A Guide to Hypothesis Testing

Glancing at the App Store on any phone will reveal that most installed apps have had updates released within the last week. Software products today are shipped in iterations to validate assumptions and hypotheses about what makes the product experience better for users.

By Kumara Raghavendra

Kumara has successfully delivered high-impact products in various industries ranging from eCommerce, healthcare, travel, and ride-hailing.

PREVIOUSLY AT

A look at the App Store on any phone will reveal that most installed apps have had updates released within the last week. A website visit after a few weeks might show some changes in the layout, user experience, or copy.

Today, software is shipped in iterations to validate assumptions and the product hypothesis about what makes a better user experience. At any given time, companies like booking.com (where I worked before) run hundreds of A/B tests on their sites for this very purpose.

For applications delivered over the internet, there is no need to decide on the look of a product 12-18 months in advance, and then build and eventually ship it. Instead, it is perfectly practical to release small changes that deliver value to users as they are being implemented, removing the need to make assumptions about user preferences and ideal solutions—for every assumption and hypothesis can be validated by designing a test to isolate the effect of each change.

In addition to delivering continuous value through improvements, this approach allows a product team to gather continuous feedback from users and then course-correct as needed. Creating and testing hypotheses every couple of weeks is a cheaper and easier way to build a course-correcting and iterative approach to creating product value .

What Is Hypothesis Testing in Product Management?

While shipping a feature to users, it is imperative to validate assumptions about design and features in order to understand their impact in the real world.

This validation is traditionally done through product hypothesis testing , during which the experimenter outlines a hypothesis for a change and then defines success. For instance, if a data product manager at Amazon has a hypothesis that showing bigger product images will raise conversion rates, then success is defined by higher conversion rates.

One of the key aspects of hypothesis testing is the isolation of different variables in the product experience in order to be able to attribute success (or failure) to the changes made. So, if our Amazon product manager had a further hypothesis that showing customer reviews right next to product images would improve conversion, it would not be possible to test both hypotheses at the same time. Doing so would result in failure to properly attribute causes and effects; therefore, the two changes must be isolated and tested individually.

Thus, product decisions on features should be backed by hypothesis testing to validate the performance of features.

Different Types of Hypothesis Testing

A/b testing.

One of the most common use cases to achieve hypothesis validation is randomized A/B testing, in which a change or feature is released at random to one-half of users (A) and withheld from the other half (B). Returning to the hypothesis of bigger product images improving conversion on Amazon, one-half of users will be shown the change, while the other half will see the website as it was before. The conversion will then be measured for each group (A and B) and compared. In case of a significant uplift in conversion for the group shown bigger product images, the conclusion would be that the original hypothesis was correct, and the change can be rolled out to all users.

Multivariate Testing

Ideally, each variable should be isolated and tested separately so as to conclusively attribute changes. However, such a sequential approach to testing can be very slow, especially when there are several versions to test. To continue with the example, in the hypothesis that bigger product images lead to higher conversion rates on Amazon, “bigger” is subjective, and several versions of “bigger” (e.g., 1.1x, 1.3x, and 1.5x) might need to be tested.

Instead of testing such cases sequentially, a multivariate test can be adopted, in which users are not split in half but into multiple variants. For instance, four groups (A, B, C, D) are made up of 25% of users each, where A-group users will not see any change, whereas those in variants B, C, and D will see images bigger by 1.1x, 1.3x, and 1.5x, respectively. In this test, multiple variants are simultaneously tested against the current version of the product in order to identify the best variant.

Before/After Testing

Sometimes, it is not possible to split the users in half (or into multiple variants) as there might be network effects in place. For example, if the test involves determining whether one logic for formulating surge prices on Uber is better than another, the drivers cannot be divided into different variants, as the logic takes into account the demand and supply mismatch of the entire city. In such cases, a test will have to compare the effects before the change and after the change in order to arrive at a conclusion.

However, the constraint here is the inability to isolate the effects of seasonality and externality that can differently affect the test and control periods. Suppose a change to the logic that determines surge pricing on Uber is made at time t , such that logic A is used before and logic B is used after. While the effects before and after time t can be compared, there is no guarantee that the effects are solely due to the change in logic. There could have been a difference in demand or other factors between the two time periods that resulted in a difference between the two.

Time-based On/Off Testing

The downsides of before/after testing can be overcome to a large extent by deploying time-based on/off testing, in which the change is introduced to all users for a certain period of time, turned off for an equal period of time, and then repeated for a longer duration.

For example, in the Uber use case, the change can be shown to drivers on Monday, withdrawn on Tuesday, shown again on Wednesday, and so on.

While this method doesn’t fully remove the effects of seasonality and externality, it does reduce them significantly, making such tests more robust.

Test Design

Choosing the right test for the use case at hand is an essential step in validating a hypothesis in the quickest and most robust way. Once the choice is made, the details of the test design can be outlined.

The test design is simply a coherent outline of:

• The hypothesis to be tested: Showing users bigger product images will lead them to purchase more products.
• Success metrics for the test: Customer conversion
• Decision-making criteria for the test: The test validates the hypothesis that users in the variant show a higher conversion rate than those in the control group.
• Metrics that need to be instrumented to learn from the test: Customer conversion, clicks on product images

In the case of the product hypothesis example that bigger product images will lead to improved conversion on Amazon, the success metric is conversion and the decision criteria is an improvement in conversion.

After the right test is chosen and designed, and the success criteria and metrics are identified, the results must be analyzed. To do that, some statistical concepts are necessary.

When running tests, it is important to ensure that the two variants picked for the test (A and B) do not have a bias with respect to the success metric. For instance, if the variant that sees the bigger images already has a higher conversion than the variant that doesn’t see the change, then the test is biased and can lead to wrong conclusions.

In order to ensure no bias in sampling, one can observe the mean and variance for the success metric before the change is introduced.

Significance and Power

Once a difference between the two variants is observed, it is important to conclude that the change observed is an actual effect and not a random one. This can be done by computing the significance of the change in the success metric.

In layman’s terms, significance measures the frequency with which the test shows that bigger images lead to higher conversion when they actually don’t. Power measures the frequency with which the test tells us that bigger images lead to higher conversion when they actually do.

So, tests need to have a high value of power and a low value of significance for more accurate results.

While an in-depth exploration of the statistical concepts involved in product management hypothesis testing is out of scope here, the following actions are recommended to enhance knowledge on this front:

• Data analysts and data engineers are usually adept at identifying the right test designs and can guide product managers, so make sure to utilize their expertise early in the process.
• There are numerous online courses on hypothesis testing, A/B testing, and related statistical concepts, such as Udemy , Udacity , and Coursera .
• Using tools such as Google’s Firebase and Optimizely can make the process easier thanks to a large amount of out-of-the-box capabilities for running the right tests.

Using Hypothesis Testing for Successful Product Management

In order to continuously deliver value to users, it is imperative to test various hypotheses, for the purpose of which several types of product hypothesis testing can be employed. Each hypothesis needs to have an accompanying test design, as described above, in order to conclusively validate or invalidate it.

This approach helps to quantify the value delivered by new changes and features, bring focus to the most valuable features, and deliver incremental iterations.

• How to Conduct Remote User Interviews [Infographic]
• A/B Testing UX for Component-based Frameworks
• Building an AI Product? Maximize Value With an Implementation Framework

Further Reading on the Toptal Blog:

• Evolving UX: Experimental Product Design with a CXO
• How to Conduct Usability Testing in Six Steps
• 3 Product-led Growth Frameworks to Build Your Business
• A Product Designer’s Guide to Competitive Analysis

Understanding the basics

What is a product hypothesis.

A product hypothesis is an assumption that some improvement in the product will bring an increase in important metrics like revenue or product usage statistics.

What are the three required parts of a hypothesis?

The three required parts of a hypothesis are the assumption, the condition, and the prediction.

Why do we do A/B testing?

We do A/B testing to make sure that any improvement in the product increases our tracked metrics.

What is A/B testing used for?

A/B testing is used to check if our product improvements create the desired change in metrics.

What is A/B testing and multivariate testing?

A/B testing and multivariate testing are types of hypothesis testing. A/B testing checks how important metrics change with and without a single change in the product. Multivariate testing can track multiple variations of the same product improvement.

Kumara Raghavendra

Dubai, United Arab Emirates

Member since August 6, 2019

About the author

World-class articles, delivered weekly.

By entering your email, you are agreeing to our privacy policy .

Toptal Product Managers

• Artificial Intelligence Product Managers
• Blockchain Product Managers
• Business Systems Analysts
• Cloud Product Managers
• Data Science Product Managers
• Digital Marketing Product Managers
• Digital Product Managers
• Directors of Product
• E-commerce Product Managers
• Enterprise Product Managers
• Enterprise Resource Planning Product Managers
• Freelance Product Managers
• Interim CPOs
• Jira Product Managers
• Kanban Product Managers
• Lean Product Managers
• Mobile Product Managers
• Product Consultants
• Product Development Managers
• Product Owners
• Product Portfolio Managers
• Product Strategy Consultants
• Product Tour Consultants
• Robotic Process Automation Product Managers
• Robotics Product Managers
• SaaS Product Managers
• Salesforce Product Managers
• Scrum Product Owner Contractors
• Web Product Managers
• View More Freelance Product Managers

Join the Toptal ® community.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

How to write an effective hypothesis

Hypothesis validation is the bread and butter of product discovery. Understanding what should be prioritized and why is the most important task of a product manager. It doesn’t matter how well you validate your findings if you’re trying to answer the wrong question.

A question is as good as the answer it can provide. If your hypothesis is well written, but you can’t read its conclusion, it’s a bad hypothesis. Alternatively, if your hypothesis has embedded bias and answers itself, it’s also not going to help you.

There are several different tools available to build hypotheses, and it would be exhaustive to list them all. Apart from being superficial, focusing on the frameworks alone shifts the attention away from the hypothesis itself.

In this article, you will learn what a hypothesis is, the fundamental aspects of a good hypothesis, and what you should expect to get out of one.

The 4 product risks

Mitigating the four product risks is the reason why product managers exist in the first place and it’s where good hypothesis crafting starts.

The four product risks are assessments of everything that could go wrong with your delivery. Our natural thought process is to focus on the happy path at the expense of unknown traps. The risks are a constant reminder that knowing why something won’t work is probably more important than knowing why something might work.

These are the fundamental questions that should fuel your hypothesis creation:

Is it viable for the business?

Is it relevant for the user, can we build it, is it ethical to deliver.

Is this hypothesis the best one to validate now? Is this the most cost-effective initiative we can take? Will this answer help us achieve our goals? How much money can we make from it?

Has the user manifested interest in this solution? Will they be able to use it? Does it solve our users’ challenges? Is it aesthetically pleasing? Is it vital for the user, or just a luxury?

Do we have the resources and know-how to deliver it? Can we scale this solution? How much will it cost? Will it depreciate fast? Is it the best cost-effective solution? Will it deliver on what the user needs?

Is this solution safe both for the user and for the business? Is it inclusive enough? Is there a risk of public opinion whiplash? Is our solution enabling wrongdoers? Are we jeopardizing some to privilege others?

Over 200k developers and product managers use LogRocket to create better digital experiences

There is an infinite amount of questions that can surface from these risks, and most of those will be context dependent. Your industry, company, marketplace, team composition, and even the type of product you handle will impose different questions, but the risks remain the same.

How to decide whether your hypothesis is worthy of validation

Assuming you came up with a hefty batch of risks to validate, you must now address them. To address a risk, you could do one of three things: collect concrete evidence that you can mitigate that risk, infer possible ways you can mitigate a risk and, finally, deep dive into that risk because you’re not sure about its repercussions.

This three way road can be illustrated by a CSD matrix :

Certainties

Suppositions.

Everything you’re sure can help you to mitigate whatever risk. An example would be, on the risk “how to build it,” assessing if your engineering team is capable of integrating with a certain API. If your team has made it a thousand times in the past, it’s not something worth validating. You can assume it is true and mark this particular risk as solved.

To put it simply, a supposition is something that you think you know, but you’re not sure. This is the most fertile ground to explore hypotheses, since this is the precise type of answer that needs validation. The most common usage of supposition is addressing the “is it relevant for the user” risk. You presume that clients will enjoy a new feature, but before you talk to them, you can’t say you are sure.

Doubts are different from suppositions because they have no answer whatsoever. A doubt is an open question about a risk which you have no clue on how to solve. A product manager that tries to mitigate the “is it ethical to deliver” risk from an industry that they have absolute no familiarity with is poised to generate a lot of doubts, but no suppositions or certainties. Doubts are not good hypothesis sources, since you have no idea on how to validate it.

A hypothesis worth validating comes from a place of uncertainty, not confidence or doubt. If you are sure about a risk mitigation, coming up with a hypothesis to validate it is just a waste of time and resources. Alternatively, trying to come up with a risk assessment for a problem you are clueless about will probably generate hypotheses disconnected with the problem itself.

That said, it’s important to make it clear that suppositions are different from hypotheses. A supposition is merely a mental exercise, creativity executed. A hypothesis is a measurable, cartesian instrument to transform suppositions into certainties, therefore making sure you can mitigate a risk.

How to craft a hypothesis

A good hypothesis comes from a supposed solution to a specific product risk. That alone is good enough to build half of a good hypothesis, but you also need to have measurable confidence.

More great articles from LogRocket:

• How to implement issue management to improve your product
• 8 ways to reduce cycle time and build a better product
• What is a PERT chart and how to make one
• Discover how to use behavioral analytics to create a great product experience
• Explore six tried and true product management frameworks you should know
• Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

You’ll rarely transform a supposition into a certainty without an objective. Returning to the API example we gave when talking about certainties, you know the “can we build it” risk doesn’t need validation because your team has made tens of API integrations before. The “tens” is the quantifiable, measurable indication that gives you the confidence to be sure about mitigating a risk.

What you need from your hypothesis is exactly this quantifiable evidence, the number or hard fact able to give you enough confidence to treat your supposition as a certainty. To achieve that goal, you must come up with a target when creating the hypothesis. A hypothesis without a target can’t be validated, and therefore it’s useless.

Imagine you’re the product manager for an ecommerce app. Your users are predominantly mobile users, and your objective is to increase sales conversions. After some research, you came across the one click check-out experience, made famous by Amazon, but broadly used by ecommerces everywhere.

You know you can build it, but it’s a huge endeavor for your team. You best make sure your bet on one click check-out will work out, otherwise you’ll waste a lot of time and resources on something that won’t be able to influence the sales conversion KPI.

You identify your first risk then: is it valuable to the business?

Literature is abundant on the topic, so you are almost sure that it will bear results, but you’re not sure enough. You only can suppose that implementing the one click functionality will increase sales conversion.

During case study and data exploration, you have reasons to believe that a 30 percent increase of sales conversion is a reasonable target to be achieved. To make sure one click check-out is valuable to the business then, you would have a hypothesis such as this:

We believe that if we implement a one-click checkout on our ecommerce, we can grow our sales conversion by 30 percent

This hypothesis can be played with in all sorts of ways. If you’re trying to improve user-experience, for example, you could make it look something like this:

We believe that if we implement a one-click checkout on our ecommerce, we can reduce the time to conversion by 10 percent

You can also validate different solutions having the same criteria, building an opportunity tree to explore a multitude of hypothesis to find the better one:

We believe that if we implement a user review section on the listing page, we can grow our sales conversion by 30 percent

Sometimes you’re clueless about impact, or maybe any win is a good enough win. In that case, your criteria of validation can be a fact rather than a metric:

We believe that if we implement a one-click checkout on our ecommerce, we can reduce the time to conversion

As long as you are sure of the risk you’re mitigating, the supposition you want to transform into a certainty, and the criteria you’ll use to make that decision, you don’t need to worry so much about “right” or “wrong” when it comes to hypothesis formatting.

That’s why I avoided following up frameworks on this article. You can apply a neat hypothesis design to your product thinking, but if you’re not sure why you’re doing it, you’ll extract nothing out of it.

What comes after a good hypothesis?

The final piece of this puzzle comes after the hypothesis crafting. A hypothesis is only as good as the validation it provides, and that means you have to test it.

If we were to test the first hypothesis we crafted, “we believe that if we implement a one-click checkout on our ecommerce, we can grow our sales conversion by 30 percent,” you could come up with a testing roadmap to build up evidence that would eventually confirm or deny your hypothesis. Some examples of tests are:

A/B testing — Launch a quick and dirty one-click checkout MVP for a controlled group of users and compare their sales conversion rates against a control group. This will provide direct evidence on the effect of the feature on sales conversions

Customer support feedback — Track any inquiries or complaints related to the checkout process. You can use organic user complaints as an indirect measure of latent demand for one-click checkout feature

User survey — Ask why carts were abandoned for a cohort of shoppers that left the checkout step close to completion. Their reasons might indicate the possible success of your hypothesis

Effective hypothesis crafting is at the center of product management. It’s the link between dealing with risks and coming up with solutions that are both viable and valuable. However, it’s important to recognize that the formulation of a hypothesis is just the first step.

The real value of a hypothesis is made possible by rigorous testing. It’s through systematic validation that product managers can transform suppositions into certainties, ensuring the right product decisions are made. Without validation, even the most well-thought-out hypothesis remains unverified.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #product strategy
• #project management

Stop guessing about your digital experience with LogRocket

Recent posts:.

How to use — but not abuse — frameworks

While frameworks have clear benefits, it’s important to understand how and when to use them, as they are often overused or used in the wrong context or setting.

Key lessons from failed products

All the metrics, data, and analysis you made will make a difference, but success isn’t always directly proportional to the effort you put in.

Leader Spotlight: Aligning to a ‘healthy days’ North Star, with Nupur Srivastava

Nupur Srivastava, COO of Included Health, talks about using the number of days a member considers themselves healthy as a North Star.

Understanding and leveraging customer sentiment

Customer sentiment is about understanding the customer. It delves into why customers behave the way they do and what matters to them.

Leave a Reply Cancel reply

• Product Management Tutorial
• What is Product Management
• Product Life Cycle
• Product Management Process
• General Availability
• Product Manager
• PM Interview Questions
• Courses & Certifications
• Project Management Tutorial
• Agile Methodology
• Software Engineering Tutorial
• Software Development Tutorial
• Software Testing Tutorial

How do you define and measure your product hypothesis?

• What Is Product Hunt and How Do You Use It?
• How to define a Target Market for a Product?
• How to measure product-market fit
• How to Ensure Your Product Meets User Needs
• Product-Market Fit : Definition, Importance and Example
• What is Product Discovery? | Definition and Overview
• What is Product Marketing? Strategy, Importance and Evolution
• Challenges in Product Management and How to Overcome them.
• What is a Product Portfolio Strategy and How to Develop It?
• How to Become an AI Product Manager?
• Product Segmentation: Definition, Importance and Examples
• How to Become a Product Manager Without Experience ?
• Product Research: Definition, Importance, and Stages
• What does a Product Manager do?
• Difference Between Product Design and Product Development
• How to Write a Research Hypothesis- Step-By-Step Guide With Examples
• Measurement of Area, Volume and Density
• Means and Function of Production
• Difference between Program and Product

Hypothesis in product management is like making an educated guess or assumption about something related to a product, such as what users need or how a new feature might work. It’s a statement that you can test to see if it’s true or not, usually by trying out different ideas and seeing what happens. By testing hypotheses, product managers can figure out what works best for the product and its users, helping to make better decisions about how to improve and develop the product further.

Table of Content

What Is a Hypothesis in Product Management?

How does the product management hypothesis work, how to generate a hypothesis for a product, how to make a hypothesis statement for a product, how to validate hypothesis statements:, the process explained what comes after hypothesis validation, final thoughts on product hypotheses, product management hypothesis example, conclusion: product hypothesis, faqs: product hypothesis.

In product management, a hypothesis is a proposed explanation or assumption about a product, feature, or aspect of the product’s development or performance. It serves as a statement that can be tested, validated, or invalidated through experimentation and data analysis. Hypotheses play a crucial role in guiding product managers’ decision-making processes, informing product development strategies , and prioritizing initiatives. In summary, hypotheses in product management serve as educated guesses or assertions about the relationship between product changes and their impact on user behaviour or business outcomes.

Product management hypotheses work by guiding product managers through a structured process of identifying problems, proposing solutions, and testing assumptions to drive product development and improvement. Here’s how the process typically works:

How does the product management hypothesis work

• Identifying Problems : Product managers start by identifying potential problems or opportunities for improvement within their product. This could involve gathering feedback from users, analyzing data, conducting market research, or observing user behaviour.
• Formulating Hypotheses : Based on the identified problems or opportunities, product managers formulate hypotheses that articulate their assumptions about the causes of these issues and potential solutions. Hypotheses are typically written as clear, testable statements that specify what the expected outcomes will be if the hypothesis is true.
• Designing Experiments : Product managers design experiments or tests to validate or invalidate their hypotheses. This could involve implementing changes to the product, such as introducing new features, modifying existing functionalities, or adjusting user experiences. Experiments may also involve collecting data through surveys, interviews, user testing, or analytics tools.
• Setting Success Metrics : Product managers define success metrics or key performance indicators (KPIs) that will be used to measure the effectiveness of the experiments. These metrics should be aligned with the goals of the hypothesis and provide quantifiable insights into whether the proposed solution is achieving the desired outcomes.
• Executing Experiments : Product managers implement the planned changes or interventions in the product and monitor their impact on the defined success metrics. This could involve conducting A/B tests, where different versions of the product are presented to different groups of users, or running pilot programs to gather feedback from a subset of users.

Generating a hypothesis for a product involves systematically identifying potential problems, proposing solutions, and formulating testable assumptions about how changes to the product could address user needs or improve performance. Here’s a step-by-step process for generating hypotheses:

How to Generate a Hypothesis for a Product

• Start by gaining a deep understanding of your target users and their needs, preferences, and pain points. Conduct user research, including surveys, interviews, usability tests, and behavioral analysis, to gather insights into user behavior and challenges they face when using your product.
• Review qualitative and quantitative data collected from user interactions, analytics tools, customer support inquiries, and feedback channels. Look for patterns, trends, and recurring issues that indicate areas where the product may be falling short or where improvements could be made.
• Clarify the goals and objectives you want to achieve with your product. This could include increasing user engagement, improving retention rates, boosting conversion rates, or enhancing overall user satisfaction. Align your hypotheses with these objectives to ensure they are focused and actionable.
• Brainstorm potential solutions or interventions that could address the identified user needs or pain points. Encourage creativity and divergent thinking within your product team to generate a wide range of ideas. Consider both incremental improvements and more radical changes to the product.
• Evaluate and prioritize the potential solutions based on factors such as feasibility, impact on user experience, alignment with strategic goals, and resource constraints. Focus on solutions that are likely to have the greatest impact on addressing user needs and achieving your objectives.

To make a hypothesis statement for a product, follow these steps:

• Identify the Problem : Begin by identifying a specific problem or opportunity for improvement within your product. This could be based on user feedback, data analysis, market research, or observations of user behavior.
• Define the Proposed Solution : Determine what change or intervention you believe could address the identified problem or opportunity. This could involve introducing a new feature, improving an existing functionality, changing the user experience, or addressing a specific user need.
• Formulate the Hypothesis : Write a clear, specific, and testable statement that articulates your assumption about the relationship between the proposed solution and its expected impact on user behavior or business outcomes. Your hypothesis should follow the structure: If [proposed solution], then [expected outcome].
• Specify Success Metrics : Define the key metrics or performance indicators that will be used to measure the success of your hypothesis. These metrics should be aligned with your objectives and provide quantifiable insights into whether the proposed solution is achieving the desired outcomes.
• Consider Constraints and Assumptions : Take into account any constraints or assumptions that may affect the validity of your hypothesis. This could include technical limitations, resource constraints, dependencies on external factors, or assumptions about user behavior.

Validating hypothesis statements in product management involves testing the proposed solutions or interventions to determine whether they achieve the desired outcomes. Here’s a step-by-step guide on how to validate hypothesis statements:

• Design Experiments or Tests : Based on your hypothesis statement, design experiments or tests to evaluate the proposed solution’s effectiveness. Determine the experimental setup, including the control group (no changes) and the experimental group (where the proposed solution is implemented).
• Define Success Metrics : Specify the key metrics or performance indicators that will be used to measure the success of your hypothesis. These metrics should be aligned with your objectives and provide quantifiable insights into whether the proposed solution is achieving the desired outcomes.
• Collect Baseline Data : Before implementing the proposed solution, collect baseline data on the identified metrics from both the control group and the experimental group. This will serve as a reference point for comparison once the experiment is conducted.
• Implement the Proposed Solution : Implement the proposed solution or intervention in the experimental group while keeping the control group unchanged. Ensure that the implementation is consistent with the hypothesis statement and that any necessary changes are properly documented.
• Monitor and Collect Data : Monitor the performance of both the control group and the experimental group during the experiment. Collect data on the defined success metrics, track user behavior, and gather feedback from users to assess the impact of the proposed solution.

After hypothesis validation in product management , the process typically involves several key steps to leverage the findings and insights gained from the validation process. Here’s what comes after hypothesis validation:

• Data Analysis and Interpretation : Once the hypothesis has been validated (or invalidated), product managers analyze the data collected during the experiment to gain deeper insights into user behavior, product performance, and the impact of the proposed solution. This involves interpreting the results in the context of the hypothesis statement and the defined success metrics.
• Documentation of Findings : Document the findings of the hypothesis validation process, including the outcomes of the experiment, key insights gained, and any lessons learned. This documentation serves as a valuable reference for future decision-making and helps ensure that knowledge is shared across the product team and organization.
• Knowledge Sharing and Communication : Communicate the results of the hypothesis validation process to relevant stakeholders, including product team members, leadership, and other key decision-makers. Share insights, lessons learned, and recommendations for future action to ensure alignment and transparency within the organization.
• Iterative Learning and Adaptation : Use the insights gained from hypothesis validation to inform future iterations of the product development process . Apply learnings from the experiment to refine the product strategy, adjust feature priorities, and make data-driven decisions about product improvements.
• Further Experimentation and Testing : Based on the validated hypothesis and the insights gained, identify new areas for experimentation and testing. Continuously test new ideas, features, and hypotheses to drive ongoing product innovation and improvement. This iterative process of experimentation and learning helps product managers stay responsive to user needs and market dynamics.

product hypotheses serve as a cornerstone of the product management process, guiding decision-making, fostering innovation, and driving continuous improvement. Here are some final thoughts on product hypotheses:

• Foundation for Experimentation : Hypotheses provide a structured framework for formulating, testing, and validating assumptions about product changes and their impact on user behavior and business outcomes. By systematically testing hypotheses, product managers can gather valuable insights, mitigate risks, and make data-driven decisions.
• Focus on User-Centricity : Effective hypotheses are rooted in a deep understanding of user needs, preferences, and pain points. By prioritizing user-centric hypotheses, product managers can ensure that product development efforts are aligned with user expectations and deliver meaningful value to users.
• Iterative and Adaptive : The process of hypothesis formulation and validation is iterative and adaptive, allowing product managers to learn from experimentation, refine their assumptions, and iterate on their product strategies over time. This iterative approach enables continuous innovation and improvement in the product.
• Data-Driven Decision Making : Hypothesis validation relies on empirical evidence and data analysis to assess the impact of proposed changes. By leveraging data to validate hypotheses, product managers can make informed decisions, mitigate biases, and prioritize initiatives based on their expected impact on key metrics.
• Collaborative and Transparent : Formulating and validating hypotheses is a collaborative effort that involves input from cross-functional teams, stakeholders, and users. By fostering collaboration and transparency, product managers can leverage diverse perspectives, align stakeholders, and build consensus around product priorities.

Here’s an example of a hypothesis statement in the context of product management:

• Problem: Users are abandoning the onboarding process due to confusion about how to set up their accounts.
• Proposed Solution: Implement a guided onboarding tutorial that walks users through the account setup process step-by-step.
• Hypothesis Statement: If we implement a guided onboarding tutorial that walks users through the account setup process step-by-step, then we will see a decrease in the dropout rate during the onboarding process and an increase in the percentage of users completing account setup.
• Percentage of users who complete the onboarding process
• Time spent on the onboarding tutorial
• Feedback ratings on the effectiveness of the tutorial

Experiment Design:

• Control Group: Users who go through the existing onboarding process without the guided tutorial.
• Experimental Group: Users who go through the onboarding process with the guided tutorial.
• Duration: Run the experiment for two weeks to gather sufficient data.
• Data Collection: Track the number of users who complete the onboarding process, the time spent on the tutorial, and collect feedback ratings from users.

Expected Outcome: We anticipate that users who go through the guided onboarding tutorial will have a higher completion rate and spend more time on the tutorial compared to users who go through the existing onboarding process without guidance.

By testing this hypothesis through an experiment and analyzing the results, product managers can validate whether implementing a guided onboarding tutorial effectively addresses the identified problem and improves the user experience.

In conclusion, hypothesis statements are invaluable tools in the product management process, providing a structured approach to identifying problems, proposing solutions, and validating assumptions. By formulating clear, testable hypotheses, product managers can drive innovation, mitigate risks, and make data-driven decisions that ultimately lead to the development of successful products.

Q. What is the lean product hypothesis?

Lean hypothesis testing is a strategy within agile product development aimed at reducing risk, accelerating the development process, and refining product-market fit through the creation and iterative enhancement of a minimal viable product (MVP).

Q. What is the product value hypothesis?

The value hypothesis centers on the worth of your product to customers and is foundational to achieving product-market fit. This hypothesis is applicable to both individual products and entire companies, serving as a crucial element in determining alignment with market needs.

Q. What is the hypothesis for a minimum viable product?

Hypotheses for minimum viable products are testable assumptions supported by evidence. For instance, one hypothesis to validate could be whether people will be interested in the product at a certain price point; if not, adjusting the price downwards may be necessary.

Please Login to comment...

Similar reads.

• Dev Scripter 2024
• Dev Scripter
• Product Management

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

12 min read

Value Hypothesis 101: A Product Manager's Guide

Talk to Sales

Humans make assumptions every day—it’s our brain’s way of making sense of the world around us, but assumptions are only valuable if they're verifiable . That’s where a value hypothesis comes in as your starting point.

A good hypothesis goes a step beyond an assumption. It’s a verifiable and validated guess based on the value your product brings to your real-life customers. When you verify your hypothesis, you confirm that the product has real-world value, thus you have a higher chance of product success. 

What Is a Verifiable Value Hypothesis?

A value hypothesis is an educated guess about the value proposition of your product. When you verify your hypothesis , you're using evidence to prove that your assumption is correct. A hypothesis is verifiable if it does not prove false through experimentation or is shown to have rational justification through data, experiments, observation, or tests. 

The most significant benefit of verifying a hypothesis is that it helps you avoid product failure and helps you build your product to your customers’ (and potential customers’) needs. 

Verifying your assumptions is all about collecting data. Without data obtained through experiments, observations, or tests, your hypothesis is unverifiable, and you can’t be sure there will be a market need for your product. 

A Verifiable Value Hypothesis Minimizes Risk and Saves Money

When you verify your hypothesis, you’re less likely to release a product that doesn’t meet customer expectations—a waste of your company’s resources. Harvard Business School explains that verifying a business hypothesis “...allows an organization to verify its analysis is correct before committing resources to implement a broader strategy.” 

If you verify your hypothesis upfront, you’ll lower risk and have time to work out product issues. 

UserVoice Validation makes product validation accessible to everyone. Consider using its research feature to speed up your hypothesis verification process. 

Value Hypotheses vs. Growth Hypotheses 

Your value hypothesis focuses on the value of your product to customers. This type of hypothesis can apply to a product or company and is a building block of product-market fit . 

A growth hypothesis is a guess at how your business idea may develop in the long term based on how potential customers may find your product. It’s meant for estimating business model growth rather than individual products. 

Because your value hypothesis is really the foundation for your growth hypothesis, you should focus on value hypothesis tests first and complete growth hypothesis tests to estimate business growth as a whole once you have a viable product.

4 Tips to Create and Test a Verifiable Value Hypothesis

A verifiable hypothesis needs to be based on a logical structure, customer feedback data , and objective safeguards like creating a minimum viable product. Validating your value significantly reduces risk . You can prevent wasting money, time, and resources by verifying your hypothesis in early-stage development. 

A good value hypothesis utilizes a framework (like the template below), data, and checks/balances to avoid bias. 

1. Use a Template to Structure Your Value Hypothesis 

By using a template structure, you can create an educated guess that includes the most important elements of a hypothesis—the who, what, where, when, and why. If you don’t structure your hypothesis correctly, you may only end up with a flimsy or leap-of-faith assumption that you can’t verify. 

A true hypothesis uses a few guesses about your product and organizes them so that you can verify or falsify your assumptions. Using a template to structure your hypothesis can ensure that you’re not missing the specifics.

You can’t just throw a hypothesis together and think it will answer the question of whether your product is valuable or not. If you do, you could end up with faulty data informed by bias , a skewed significance level from polling the wrong people, or only a vague idea of what your customer would actually pay for your product. 

A template will help keep your hypothesis on track by standardizing the structure of the hypothesis so that each new hypothesis always includes the specifics of your client personas, the cost of your product, and client or customer pain points. 

A value hypothesis template might look like: 

[Client] will spend [cost] to purchase and use our [title of product/service] to solve their [specific problem] OR help them overcome [specific obstacle]. 

An example of your hypothesis might look like: 

B2B startups will spend $500/mo to purchase our resource planning software to solve resource over-allocation and employee burnout.

By organizing your ideas and the important elements (who, what, where, when, and why), you can come up with a hypothesis that actually answers the question of whether your product is useful and valuable to your ideal customer. 

2. Turn Customer Feedback into Data to Support Your Hypothesis  

Once you have your hypothesis, it’s time to figure out whether it’s true—or, more accurately, prove that it’s valid. Since a hypothesis is never considered “100% proven,” it’s referred to as either valid or invalid based on the information you discover in your experiments or tests. Additionally, your results could lead to an alternative hypothesis, which is helpful in refining your core idea.

To support value hypothesis testing, you need data. To do that, you'll want to collect customer feedback . A customer feedback management tool can also make it easier for your team to access the feedback and create strategies to implement or improve customer concerns. 

If you find that potential clients are not expressing pain points that could be solved with your product or you’re not seeing an interest in the features you hope to add, you can adjust your hypothesis and absorb a lower risk. Because you didn’t invest a lot of time and money into creating the product yet, you should have more resources to put toward the product once you work out the kinks. 

On the other hand, if you find that customers are requesting features your product offers or pain points your product could solve, then you can move forward with product development, confident that your future customers will value (and spend money on) the product you’re creating. 

A customer feedback management tool like UserVoice can empower you to challenge assumptions from your colleagues (often based on anecdotal information) which find their way into team decision making . Having data to reevaluate an assumption helps with prioritization, and it confirms that you’re focusing on the right things as an organization.

3. Validate Your Product 

Since you have a clear idea of who your ideal customer is at this point and have verified their need for your product, it’s time to validate your product and decide if it’s better than your competitors’. 

At this point, simply asking your customers if they would buy your product (or spend more on your product) instead of a competitor’s isn’t enough confirmation that you should move forward, and customers may be biased or reluctant to provide critical feedback. 

Instead, create a minimum viable product (MVP). An MVP is a working, bare-bones version of the product that you can test out without risking your whole budget. Hypothesis testing with an MVP simulates the product experience for customers and, based on their actions and usage, validates that the full product will generate revenue and be successful.  

If you take the steps to first verify and then validate your hypothesis using data, your product is more likely to do well. Your focus will be on the aspect that matters most—whether your customer actually wants and would invest money in purchasing the product.

4. Use Safeguards to Remain Objective 

One of the pitfalls of believing in your product and attempting to validate it is that you’re subject to confirmation bias . Because you want your product to succeed, you may pay more attention to the answers in the collected data that affirm the value of your product and gloss over the information that may lead you to conclude that your hypothesis is actually false. Confirmation bias could easily cloud your vision or skew your metrics without you even realizing it. 

Since it’s hard to know when you’re engaging in confirmation bias, it’s good to have safeguards in place to keep you in check and aligned with the purpose of objectively evaluating your value hypothesis. 

Safeguards include sharing your findings with third-party experts or simply putting yourself in the customer’s shoes.

Third-party experts are the business version of seeking a peer review. External parties don’t stand to benefit from the outcome of your verification and validation process, so your work is verified and validated objectively. You gain the benefit of knowing whether your hypothesis is valid in the eyes of the people who aren’t stakeholders without the risk of confirmation bias. 

In addition to seeking out objective minds, look into potential counter-arguments , such as customer objections (explicit or imagined). What might your customer think about investing the time to learn how to use your product? Will they think the value is commensurate with the monetary cost of the product? 

When running an experiment on validating your hypothesis, it’s important not to elevate the importance of your beliefs over the objective data you collect. While it can be exciting to push for the validity of your idea, it can lead to false assumptions and the permission of weak evidence. 

Validation Is the Key to Product Success

With your new value hypothesis in hand, you can confidently move forward, knowing that there’s a true need, desire, and market for your product.

Because you’ve verified and validated your guesses, there’s less of a chance that you’re wrong about the value of your product, and there are fewer financial and resource risks for your company. With this strong foundation and the new information you’ve uncovered about your customers, you can add even more value to your product or use it to make more products that fit the market and user needs. 

If you think customer feedback management software would be useful in your hypothesis validation process, consider opting into our free trial to see how UserVoice can help.

Heather Tipton

Start your free trial.

What Is Product Management Hypothesis?

• 1.  What Is Product Management?
• 2.  What Is a Software Product?
• 3.  Software Product Manager
• 4.  Product Owner
• 5.  Product Management Life Cycle
• 6.  Product Management Roadmap
• 7.  Product Management Software and Tools
• 8.  Product Backlog
• 9.  Product Management OKRs
• 10.  Product Requirements Documents
• 11.  Product Management Metrics and KPIs Explained
• 12.  Product Analytics
• 13.  Comprehensive Guide to Lean Product Management
• 14.  Best Product Management Resources for Product Managers
• 15.  Practical Product Management Templates
• 16.  FAQ
• 17.  Glossary of Product Management Terms

The path to creating a great product can be riddled with unknowns.

To create a successful product that delivers value to customers, product teams grapple with many questions such as:

• Who is our ideal customer?
• What is the most important product feature to build?
• Will customers like a specific feature?

Using a scientific process for product management can help funnel these assumptions into actionable and specific hypotheses. Then, teams can validate their ideas and make the product more valuable for the end-user.

In this article, we’ll learn more about the product management hypothesis and how it can help create successful products consistently.

Product management hypothesis definition

Product management hypothesis is a scientific process that guides teams to test different product ideas and evaluate their merit. It helps them prioritize their finite energy, time, development resources, and budget.

To create hypotheses , product teams can be inspired by multiple sources, including:

• Observations and events happening around them
• Personal opinions of team members
• Earlier experiences of building and launching a different product
• An evaluation and assessment that leads to the identification of unique patterns in data

The most creative ideas can come when teams collaborate. When ideas are identified and expanded, they become hypotheses.

How does the product management hypothesis work?

A method has as many variations as its users. The product management hypothesis has evolved over the years, but here is a brief outline of how it works.

• Identify an idea, assumption, or observation.
• Question the idea or observation to learn more about it.
• Create an entire hypothesis and explain the idea, observation, or assumption.
• Outline a prediction about the hypothesis.
• Test the prediction.
• Review testing results to iterate and create new hypotheses

Product management hypothesis checklist

When time is limited, teams cannot spend too long creating a hypothesis.

That’s why having a well-planned product management checklist can help in identifying good hypotheses quickly. A good hypothesis is an idea or assumption that:

• Is believed to be true, but whose merit needs to be assessed
• Can be tested in many ways
• Is expected to occur in the near future
• Can be true or false
• Applies to the ideal end-users of the product
• Is measurable and identifiable

Product management hypothesis example

Here’s a simple template to outline your product management hypothesis:

• The core idea, assumption, or observation 
• The potential impact this idea will have
• Who will this idea impact the most?
• What will be the estimated volume and nature of the impact?
• When will the idea and its impact occur? 

Here’s an example of a product management hypothesis:

• Idea: We want to redesign the web user interface for a SaaS product to increase conversions
• Potential impact: This redesign targets to increase conversions for new users 
• The audience of impact: Showcase the redesign only to new users to understand the impact on conversions (there’s no point in showing this to existing users since the goal here is new user conversions)
• Impact volume: The targeted volume of the redesign-led conversions will be 35%
• Time period: The redesign testing would take three weeks, starting from August 15

Stop guessing which feature or product to prioritize and build. Use the product management hypothesis as a guide to finding your next successful product or feature ideas. 

Get a free Wrike trial to create more products that deliver business impact and delight your customers.

Further reading

How to Create a Product Roadmap

Product Backlog

Product Owner

Product Life Cycle

• Product Management Strategy
• Defining Software Product Strategy
• Product Management Launch Plan
• Product Management Goals
• Product Roadmap

Product Requirements

• Defining Product Specifications
• Writing Software Requirements
• Product Design Requirement Document

Product Management Team And Roles

• Product Management Hierarchy
• Product Management Team and Roles
• Role of a Product Management Lead
• Role of a Product Management Specialist
• Product Manager vs Software Engineer
• Technical Product Manager vs Product Manager
• How to Become a Product Owner
• Project Manager vs Project Owner
• Importance of The Product Owner

Product Management Software & Tools

• Product Management Dashboard
• Product Management Maturity Model
• Product Management Software
• Product Management Workflow

What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget? —Eric Ries, The Lean Startup [1]

An Epic is a significant solution development initiative.

Portfolio epics are typically cross-cutting, typically spanning multiple Value Streams and PIs . To accelerate learning and development and reduce risk, SAFe recommends applying the Lean Startup build-measure-learn cycle for these epics.

This article describes the portfolio epic’s definition, approval, and implementation. Agile Release Train (ART) and Solution Train epics, which follow a similar pattern, are described briefly at the end of this article.

There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics advance the  Architectural Runway  to support upcoming business or technical needs.

It’s important to note that epics are not merely a synonym for projects; they operate quite differently, as Figure 1 highlights.

SAFe discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup Cycle discussed later in this article (Figure 6).

Defining Epics

Since epics are some of the most significant enterprise investments, stakeholders must agree on their intent and definition. Figure 2 provides an epic hypothesis statement template for capturing, organizing, and communicating critical information about an epic.

Epics above the approval Guardrail are made visible, developed, and managed through the  Portfolio Kanban system, where they proceed through various states of maturity until they’re approved or rejected. Before being committed to implementation, epics require analysis. Epic Owners take responsibility for the critical collaborations needed for Business Epics, while  Enterprise Architects  typically guide the Enabler epics that support the technical considerations for business epics.

Creating the Lean Business Case

The result of the epic analysis is a Lean business case (Figure 3).

The LPM reviews the Lean business case to make a go/no-go decision for the epic. Once approved, portfolio epics move to the Ready state of the Portfolio Kanban. When capacity and budget become available from one or more ARTs, the Epic is pulled into implementation. The Epic Owner is responsible for working with Product  and  Solution Management  and  System Architects  to split the epic into Features or Capabilities during backlog refinement. Epic Owners help prioritize these items in their respective backlogs and have ongoing responsibilities for their development and follow-up.

Defining the MVP

Analysis of an epic includes the definition of a Minimum Viable Product (MVP) for the epic. In the context of SAFe, an MVP is an early and minimal version of a new product or business  Solution  used to prove or disprove the epic hypothesis. Unlike storyboards, prototypes, mockups, wireframes, and other exploratory techniques, the MVP is an actual product that real customers can use to generate validated learning.

Estimating Epic Costs

As Epics progress through the Portfolio Kanban, the LPM team will eventually need to understand the potential investment required to realize the hypothesized value. This analysis requires a meaningful estimate of the cost of the MVP, and the forecasted cost of the full implementation should the epic hypothesis be proven true.

• The  MVP cost  ensures the portfolio is budgeting enough money to prove or disprove the Epic hypothesis. It helps ensure that LPM makes sufficient investments in innovation aligned with Lean budget guardrails.
• The forecasted implementation cost considers ROI analysis, helping determine if the business case is sound, and allows the LPM team to prepare for potential adjustments to value stream budgets.

The Epic owner determines the amount of the MVP’s investment in collaboration with other key stakeholders. This investment should be sufficient to prove or disprove the MVP’s hypothesis. Once approved, the value stream cannot spend more than the defined investment cost to build and evaluate the MVP. If the value stream has evidence that this cost will be exceeded during epic implementation, further work on the epic should be discussed with LPM before exceeding the MVP’s estimated cost.

Estimating Implementation Cost

Considerable strategic efforts often require collaboration with external Suppliers to develop Solutions. The MVP and the anticipated full implementation cost estimates should include internal costs and forecasted external Supplier expenses.

Estimating epics in the early stages can be challenging since there is limited data and learning at this point. As illustrated in Figure 4, ‘T-shirt sizing’ is a simple way to estimate epics, especially in the early stages:

• A cost range is established for each t-shirt size using historical data
• The gaps in the cost ranges reflect the uncertainty of estimates and avoid excessive discussion around edge cases
• Each portfolio must determine the relevant cost range for the t-shirt sizes

The Epic Owner can incrementally refine the total implementation cost as the MVP is built and learning occurs.

Supplier Costs

An epic investment often includes the contribution and cost from suppliers, whether internal or external. Ideally, enterprises engage external suppliers via Agile contracts, which supports estimating the costs of a supplier’s contribution to a specific epic. For more on this topic, see the Agile Contracts  extended guidance article.

Forecasting an Epic’s Duration

While it can be challenging to forecast the duration of an epic implemented by a mix of internal ARTs and external suppliers, an understanding of the forecasted duration of the epic is critical to the proper functioning of the portfolio.

Like an epic’s cost, its duration isn’t easy to forecast as it includes several components, such as internal duration, supplier duration, and the collaborations and interactions between the internal and external teams. Practically, unless the epic is wholly outsourced, LPM can focus on forecasts of the internal ARTs affected by the epic, as they are expected to coordinate work with external suppliers.

Forecasting an epic’s duration requires an understanding of three data points:

• An epic’s estimated size in story points for each affected ART can also be calculated using T-shirt sizes and replacing the cost range with a story point range.
• The historical velocity of the impacted ARTs.
• The percent (%) capacity allocation that ARTs can dedicate to working on the epic. This allocation typically results from negotiation between Product and Solution Management, Epic Owners, and LPM.

In the example shown in Figure 5, a portfolio has a substantial enabler epic that affects three ARTs, and LPM seeks to gain an estimate of the forecasted number of PIs.

ART 1 has estimated the epic’s size as 2,000 – 2,500 points. Product Management determines that ART 1 can allocate 40% of total capacity toward implementing its part of the epic. With a historical velocity of 1,000 story points per PI, ART 1 forecasts between five to seven PIs for the epic.

After repeating these calculations for each ART, the Epic Owner can see that some ARTs will likely be ready to release on demand earlier than others. However, the forecasted duration to deliver the entire epic across all ARTs will likely be between six and eight PIs. If this forecast does not align with business needs, negotiations such as adjusting capacity allocations or increasing the budget for suppliers will ensue. The Epic Owner updates the forecasted completion once work begins on the epic.

Implementing Epics

The SAFe Lean startup strategy recommends a highly iterative build-measure-learn cycle for product innovation and strategic investments. This approach for implementing epics provides the economic and strategic advantages of a Lean startup by managing investment and risk incrementally while leveraging the flow and visibility benefits of SAFe (Figure 6).

Gathering the data necessary to prove or disprove the epic hypothesis is highly iterative. These iterations continue until a data-driven result is obtained or the teams consume the entirety of the MVP budget. In general, the result of a proven hypothesis is an MVP suitable for continued investment by the value streams. Otherwise, any further investment requires the creation of a new epic.

After it’s approved for implementation, the Epic Owner works with the Agile Teams  to begin the development activities needed to realize the business outcomes hypothesis for the epic:

• If the hypothesis is true , the epic enters the persevere state, which will drive more work by implementing additional features and capabilities. ARTs manage any further investment in the epic via ongoing WSJF feature prioritization of the ART Backlog . Local features identified by the ART, and those from the epic, compete during routine WSJF reprioritization.
• If the hypothesis is false , Epic Owners can decide to pivot by creating a new epic for LPM review or dropping the initiative altogether and switching to other work in the backlog.

After evaluating an epic’s hypothesis, it may or may not be considered a portfolio concern. However, the Epic Owner may have ongoing stewardship and follow-up responsibilities.

Lean budgets’ empowerment and decentralized decision-making depend on Guardrails for specific checks and balances. Value stream KPIs and other metrics also support guardrails to keep the LPM informed of the epic’s progress toward meeting its business outcomes hypothesis.

ART and Solution Train Epics

Epics may originate from local ARTs or Solution Trains, often starting as initiatives that warrant LPM attention because of their significant business impact or initiatives that exceed the epic threshold. ART and Solution Train epics may also originate from portfolio epics that must be split to facilitate incremental implementation. Like any other epics, ART and Solution Train epics deserve a Lean business case that captures these significant investments’ purpose and expected benefits. The ART and Solution Train Backlogs article describes methods for managing the flow of local epics that do not meet the criteria for portfolio attention.

Last update: 6 September 2023

Privacy Overview

Hypothesis Driven Product Management

• Post author By admin
• Post date September 23, 2020
• No Comments on Hypothesis Driven Product Management

What is Lean Hypothesis Testing?

“The first principle is that you must not fool yourself and you are the easiest person to fool.” – Richard P. Feynman

Lean hypothesis testing is an approach to agile product development that’s designed to minimize risk, increase the speed of development, and hone business outcomes by building and iterating on a minimum viable product (MVP).

The minimum viable product is a concept famously championed by Eric Ries as part of the lean startup methodology. At its core, the concept of the MVP is about creating a cycle of learning. Rather than devoting long development timelines to building a fully polished end product, teams working through lean product development build, in short, iterative cycles. Each cycle is devoted to shipping an MVP, defined as a product that’s built with the least amount of work possible for the purpose of testing and validating that product with users.

In lean hypothesis testing, the MVP itself can be framed as a hypothesis. A well-designed hypothesis breaks down an issue into a  problem, solution, and result.

When defining a good hypothesis, start with a meaningful problem: an issue or pain-point that you’d like to solve for your users. Teams often use multiple qualitative and quantitative sources to the scope and describe this problem.

How do you get started?

Two core practices underlie lean:

• Use of the scientific method and
• Use of small batches. Science has brought us many wonderful things.

I personally prefer to expand the Build-Measure-Learn loop into the classic view of the scientific method because I find it’s more robust. You can see that process to the right, and we’ll step through the components in the balance of this section.

The use of small batches is critical. It gives you more shots at a successful outcome, particularly valuable when you’re in a high risk, high uncertainty environment.

A great example from Eric Ries’ book is the envelope folding experiment: If you had to stuff 100 envelopes with letters, how would you do it? Would you fold all the sheets of paper and then stuff the envelopes? Or would you fold one sheet of paper, stuff one envelope? It turns out that doing them one by one is vastly more efficient, and that’s just on an  operational  basis. If you don’t actually know if the envelopes will fit or whether anyone wants them (more analogous to a startup), you’re obviously much better off with the one-by-one approach.

So, how do you do it? In 6 simple (in principle) steps :

• Start with a strong idea , one where you’ve gone out a done customer strong discovery which is packaged into testable personas and problem scenarios. If you’re familiar with design thinking, it’s very much about doing good work in this area.
• Structure your idea(s)  in a testable format (as hypotheses).
• Figure out how you’ll prove or disprove  these hypotheses with a minimum of time and effort. 
• Get focused on testing your hypotheses  and collecting whatever metrics you’ll use to make a conclusion.
• Conclude and decide ; did you prove out this idea and is it time to throw more resources at it? Or do you need to reformulate and re-test?
• Pivot or persevere ; If you’re pivoting and revising, the key is to make sure you have a strong foundation in customer discovery so you can pivot in a smart way based on your understanding of the customer/user.

By using a hypothesis-driven development process you:

• Articulate your thinking
• Provide others with an understanding of your thinking
• Create a framework to test your designs against
• Develop a standard way of documenting your work
• Make better stuff

Free Template: Lean Hypothesis template

Eric Ries: Test & experiment, turn your feeling into a hypothesis

5 case studies on experimentation :.

• Adobe takes a customer-centric to innovating Photoshop
• Test Paper prototypes to save time and money: the Mozilla case study
• Walmart.ca increases on-site conversions by 13%
• Icons8 web app. Redesign based on usability testing.
• Experiments at Airbnb
• Tags Hypothesis Driven

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

A Business Hypothesis: How to Improve Your Outcomes When Deciding

“So, Tom. Can you explain what your business hypothesis was?”

“No,” came the curt reply.

“Okay, so let me understand this. You’ve got an increase in conversion rates — which, don’t get me wrong, is good — but you're not sure why. Is that right?”

“I made several changes last week, so it must have been one of them...”

“Yes, but which one?” I questioned.

Tom looked flustered as he searched for a plausible story. “The truth is Tom, you don’t know and that isn’t helping us increase conversion.”

I’ve lost count of the times I’ve had conversations like this.

Tom was like so many other entrepreneurs who like to tinker.

Often driven by limited evidence, people like Tom make changes based on supposition . Their starting point comes from what they read online. If survivorship bias had a smell, entrepreneurial homes would reek like a field being fertilized with manure.

What they lack is a theory—a rational argument for why they are making a change. A business hypothesis explains that if you make a change, then this should be the outcome.

Unlike Tom, when you work from a hypothesis, you have a proposed explanation of what you expect to happen. You use good experiments to test your theory, giving you a conclusion that could stand up in court (if needed).

In this article, I will explain how I helped Tom incorporate a hypothesis-led approach into his way of working. You will have the foundations to begin using hypotheses as a framework in your work.

Let’s dig in.

What is a Hypothesis?

A hypothesis is a statement of your expectation of making a change. It's taking what you think will happen and framing it as an experiment to record the result.

As the Economist, Milton Friedman said:

The only relevant test of the validity of a hypothesis is comparison of prediction with experience.

Now a business hypothesis goes a stage further.

Through good experiments, It captures the expected value that the change will create. It enshrines the return on investment that demonstrates the opportunity on offer.

The ROI also creates an objective measure, giving a baseline to measure the outcome.

So, in summary, a hypothesis is:

• A hypothesis is a testable statement that reflects your predictions.
• It offers a theory of what might happen based on our experiences and knowledge.
• It is testable so that you can measure the outcome against your prediction.

Not Hypothesising: A Wasted Opportunity

Tom was trying to experiment, but not in a data-driven way.

When I began consulting with Tom, he gave me a long list of different things he had tried. He wanted to increase conversion so he changed the button users click on.  Tom had tried different button sizes, various shapes, colours, and the copy — the list was lengthy.

But he had no idea whether they worked or not.

He had this pretty line graph with peaks and troughs. He tried to argue these were due to the changes he had made. But without a starting hypothesis, I shot down his argument.

“You’re not making fact-based decisions ”, I told Tom. “ Even worse, you’re declaring success subjectively when you lack supporting evidence to back you up. You are wasting the opportunities you have infront of you.”

In truth, Tom was aflected by survivirship bias, confirmation bias , and outcome bias . Although he wasn’t taking a wild guess, Tom was taking insights from some ‘expert’ and using that to guide what he should change and when.

It’s a common sight among those who fail to be data-driven.

Without a hypothesis,  Tom was defeating any hope of progress other than success via a fluke.

I remembered what Gavin, an old accountant friend of mine once said:

Businesses are often successful in spite of themselves and rather than because of themselves.

By not defining the outcome Tom wanted or expected, he was no different to the businesses Gavin talked about.

Tom wasn't making the most of the opportunities he had. He was wasting them.

A Business Hypothesis Approach

Before we could get to the process of creating and testing hypotheses, we needed to improve the presentation of data.

To do this, I set up some XmR charts to track the metrics Tom wanted to focus on.

We looked at higher-level metrics:

• Website Visitors
• Email subscribers
• Conversion rate
• Page views per visitor
• Bounce rate

These charts revealed what I suspected. None of the improvements Tom had made caused the numbers to move outside of routine variation (If you don’t know about routine variation, you need to digest this: Becoming Data Driven, From First Principles ).

We needed to move away from looking for potential explanations.

Conversely, our goal was to create a parameter meaning we had a provable explanation.

To do this, I told Tom we should change how he worked.

From now on, he had to write down every change before he made it. He would announce the anticipated results, providing us with enough evidence to determine the accuracy of the hypothesis.

Within each hypothesis, a clear value proposition would be evident giving Tom further justification to experiment. This framework would allow him to become a data-driven decision-maker.

It would bring an end to wasted opportunities.

The Building Blocks Behind The Theory

As I mentioned, for Tom to make this business hypothesis-led approach work, he needed a system to guide him through the different phases.

So I set this up as a simple database in Notion.

Let me explain how it works:

The Null Hypothesis

You begin with a null hypothesis. It’s a statement of your baseline performance which we are saying can’t be changed.

The Alternative Hypothesis

The alternative hypothesis is a statement showing how we might disprove the null hypothesis in specific detail.

Over a pre-determined period, the conditions of the alternative hypothesis are put to the test. Providing there is sufficient evidence, then the null hypothesis is proven to be wrong. Importantly, if the alternative hypothesis isn’t proven then the null hypothesis stands until you create a second hypothesis to test.

“This is Epic!”

First, it was a beep.

A subtle notification telling me I had a message.  Before I had a chance to read it, the phone started ringing. It was Tom.

“Oh my god!”

“It worked.” “What worked”, I replied.

“The hypothesis thingy you got me to write. It worked.” “This is epic!” Tom declared with delight.

Before he got too carried away, I took a breath and asked Tom to explain in more detail why he was so excited.

Tom explained breathlessly that his alternative hypothesis had been proven. Changing the primary heading and sub-title had increased conversion. Excitedly, he talked me through the null hypothesis.

It said: Readers subscribe to the newsletter via forms on the website at an average rate of 0.58%, with a routine variation between 0.4% and 1.2%.

The alternative hypothesis was as follows:   If we change the text on the button from ‘subscribe’ to ‘try free’ then the conversion rate will increase to an average rate of 1%, thus changing the routine variation figures.

The results sustained over 4 weeks revealed an average rate of 1.2%.

Tom’s delight was clear. “Now I can tell what I changed and I have the proof to say with utter conviction, it worked!”

Concluding Thoughts

As Tom quickly discovered, there is no hiding with a hypothesis.

Thoughtless, unvalidated changes can create a lot of wasted opportunities. Before I introduced the Process Behaviour Chart, Tom wasted hours making changes he couldn’t substantiate.

Now, he could prove his theories with this experimentalist approach. A business hypothesis framework that quantified his ideas and objectively qualified his successes or failures. Subjectivity was from a distant past.

That’s why this approach works so well in a business.

Businesses are full of data. So entrepreneurs like Tom can become data-driven. They can make changes because they have hard facts to give them a precision level of appreciation for what is happening.

And if all this sounds a bit too structured and rigid, you might be right.

But does it work?

To find an answer I’ll direct you to a piece I wrote about the way Elon Musk makes decisions. In this article about feedback loops , you’ll find a hypothesis at the heart of the action . Here, the step towards progress is a test which creates a feedback loop.

Without the business hypothesis-led approach, Elon would not be where he is today.

An important hypothesis can develop longer-term thinking and create interest in planning a more thoughtful approach to the next steps.

That’s the real value for me.

Becoming data-driven — through a business hypothesis — leads you to meaningful change that will positively help your business.

How do you formulate a strong business hypothesis?

• Start by identifying a specific business problem or opportunity.
• Clearly define your independent and dependent variables. What factors are you testing?
• Craft your hypothesis as an if-then statement. For instance, “If we reduce response time in customer service, then customer satisfaction will improve.”

Why is hypothesis testing crucial for business decisions?

• Hypothesis testing allows businesses to validate assumptions before implementing strategies.
• By testing hypotheses, organizations can avoid costly mistakes and allocate resources effectively.
• For instance, before launching a new product, a company can test its assumptions about market demand through hypothesis testing.

What are null and alternative hypotheses in business research?

• The null hypothesis (H₀) represents the status quo or no effect. It assumes that any observed differences are due to random chance.
• The alternative hypothesis (Hₐ) proposes a specific effect or relationship. It challenges the null hypothesis.
• In business, these hypotheses guide statistical tests to determine whether evidence supports a change or effect.

What is a good example of a business hypothesis in action?

At the core of Elon Musk's decision-making process is a hypothesis. Every decision he makes, he seeks to test a theory which allows him to make progress. It is a fine example of a effective decision-making .

Related Articles

Reasoning from First Principles: How to Master Solving Hard Problems

How to Avoid Damage from Your Biases - Write Your Decisions Down

Reflective Decision-Making: Thinking Your Way to a Better Decision

Become a wiser decision-maker in just 5 minutes per week..

• Skip to main content
• Skip to FDA Search
• Skip to in this section menu
• Skip to footer links

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you're on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

U.S. Food and Drug Administration

•   Search
•   Menu
• News & Events from CFSAN
• CFSAN Constituent Updates

FDA Update on the Post-market Assessment of Tara Flour

Constituent update.

May 15, 2024

Today, the U.S. Food and Drug Administration (FDA) posted on its website its determination that tara flour in human food does not meet the Generally Recognized As Safe (or GRAS) standard and is an unapproved food additive. The FDA’s assessment of the ingredient is detailed in a memo added to the agency’s public inventory . Increased transparency of our assessment of ingredients in the food supply is part of our approach to enhance food chemical safety .

Under the Federal Food, Drug, and Cosmetic (FD&C) Act , any ingredient used or intended for use in food must be authorized by the FDA for use as a food additive unless that use is Generally Recognized As Safe or GRAS by qualified experts or meets a listed exception to the food additive definition in the FD&C Act. An unapproved food additive is deemed to be unsafe under the FD&C Act.

In 2022, Daily Harvest used tara flour in a leek and lentil crumble product which was associated with roughly 400 adverse event reports. The firm took prompt action to voluntarily recall the product and conduct their own root cause analysis, during which they identified tara flour as a possible contributor to the illnesses. To date, the FDA has found no evidence that tara flour caused the outbreak; however, it did prompt the agency to evaluate the regulatory status of this food ingredient.

The FDA’s evaluation revealed that there is not enough data on the use of tara flour in food, or a history of its safe use, to consider it GRAS. There is no food additive regulation authorizing the use of tara flour in food.  Uses of food ingredients that are not GRAS, not authorized as food additives, and not excepted from the Federal Food, Drug, and Cosmetic (FD&C) Act ’s food additive definition are unapproved food additives. Food that is, or contains, an unsafe food additive is considered adulterated.

FDA’s Continued Monitoring of Tara Flour in the Food Supply

Manufacturers who are considering using tara flour as an ingredient in food are responsible for ensuring that its use is safe and lawful and are encouraged to consult with the FDA. At this time, the FDA is not aware of evidence that shows that tara flour is a food ingredient being developed domestically or that there are any products containing tara flour that are currently being manufactured in the U.S.

The FDA instituted screening at ports of entry for tara flour used as an ingredient in imported food or imported for sale in bulk. The agency has not detected any recent shipments of tara flour in imported products as of today.

The FDA remains committed to monitoring new ingredients in the food supply to ensure they meet relevant safety standards. The FDA’s assessment of chemicals in the food supply is part of our commitment to food safety and public health.

Additional Information

• Post-market Determinations that the Use of a Substance is Not GRAS
• FDA Update on Post-market Assessment of Certain Food Ingredients
• Understanding How the FDA Regulates Food Additives and GRAS Ingredients

Subscribe to CFSAN Constituent Updates

Get email updates delivered to your inbox.

• My View My View
• Following Following
• Saved Saved

Pro-Kremlin activist couple quit Germany, move to Russia

• Medium Text

Sign up here.

Reporting by Mari Saito Editing by Christian Lowe and Gareth Jones

Our Standards: The Thomson Reuters Trust Principles. New Tab , opens new tab

World Chevron

World hits streak of record temperatures as UN warns of 'climate hell'

Each of the past 12 months ranked as the warmest on record in year-on-year comparisons, the EU's climate change monitoring service said on Wednesday, as U.N. Secretary-General António Guterres called for urgent action to avert "climate hell".

Mobile Menu Overlay

The White House 1600 Pennsylvania Ave NW Washington, DC 20500

FACT SHEET: Biden- ⁠ Harris Administration Announces New Principles for High-Integrity Voluntary Carbon   Markets

Since Day One, President Biden has led and delivered on the most ambitious climate agenda in history, including by securing the Inflation Reduction Act, the largest-ever climate investment, and taking executive action to cut greenhouse gas emissions across every sector of the economy. The President’s Investing in America agenda has already catalyzed more than $860 billion in business investments through smart, public incentives in industries of the future like electric vehicles (EVs), clean energy, and semiconductors. With support from the Bipartisan Infrastructure Law, CHIPS and Science Act, and Inflation Reduction Act, these investments are creating new American jobs in manufacturing and clean energy and helping communities that have been left behind make a comeback.

The Biden-Harris Administration is committed to taking ambitious action to drive the investments needed to achieve our nation’s historic climate goals – cutting greenhouse gas emissions in half by 2030 and reaching net zero by 2050. President Biden firmly believes that these investments must create economic opportunities across America’s diverse businesses – ranging from farms in rural communities, to innovative technology companies, to historically- underserved entrepreneurs.

As part of this commitment, the Biden-Harris Administration is today releasing a Joint Statement of Policy and new Principles for Responsible Participation in Voluntary Carbon Markets (VCMs) that codify the U.S. government’s approach to advance high-integrity VCMs. The principles and statement, co-signed by Treasury Secretary Janet Yellen, Agriculture Secretary Tom Vilsack, Energy Secretary Jennifer Granholm, Senior Advisor for International Climate Policy John Podesta, National Economic Advisor Lael Brainard, and National Climate Advisor Ali Zaidi, represent the U.S. government’s commitment to advancing the responsible development of VCMs, with clear incentives and guardrails in place to ensure that this market drives ambitious and credible climate action and generates economic opportunity.

The President’s Investing in America agenda has crowded in a historic surge of private capital to take advantage of the generational investments in the Inflation Reduction Act and Bipartisan Infrastructure Law. High-integrity VCMs have the power to further crowd in private capital and reliably fund diverse organizations at home and abroad –whether climate technology companies, small businesses, farmers, or entrepreneurs –that are developing and deploying projects to reduce carbon emissions and remove carbon from the atmosphere. However, further steps are needed to strengthen this market and enable VCMs to deliver on their potential. Observers have found evidence that several popular crediting methodologies do not reliably produce the decarbonization outcomes they claim. In too many instances, credits do not live up to the high standards necessary for market participants to transact transparently and with certainty that credit purchases will deliver verifiable decarbonization. As a result, additional action is needed to rectify challenges that have emerged, restore confidence to the market, and ensure that VCMs live up to their potential to drive climate ambition and deliver on their decarbonization promise. This includes: establishing robust standards for carbon credit supply and demand; improving market functioning; ensuring fair and equitable treatment of all participants and advancing environmental justice, including fair distribution of revenue; and instilling market confidence.

The Administration’s Principles for Responsible Participation announced today deliver on this need for action to help VCMs achieve their potential. These principles include:

• Carbon credits and the activities that generate them should meet credible atmospheric integrity standards and represent real decarbonization.
• Credit-generating activities should avoid environmental and social harm and should, where applicable, support co-benefits and transparent and inclusive benefits-sharing.
• Corporate buyers that use credits should prioritize measurable emissions reductions within their own value chains.
• Credit users should publicly disclose the nature of purchased and retired credits.
• Public claims by credit users should accurately reflect the climate impact of retired credits and should only rely on credits that meet high integrity standards.
• Market participants should contribute to efforts that improve market integrity.
• Policymakers and market participants should facilitate efficient market participation and seek to lower transaction costs.

The Role of High-Quality Voluntary Carbon Markets in Addressing Climate Change President Biden, through his executive actions and his legislative agenda, has led and delivered on the most ambitious climate agenda in history. Today’s release of the Principles for Responsible Participation in Voluntary Carbon Markets furthers the President’s commitment to restoring America’s climate leadership at home and abroad by recognizing the role that high- quality VCMs can play in amplifying climate action alongside, not in place of, other ambitious actions underway.

High-integrity, well-functioning VCMs can accelerate decarbonization in several ways. VCMs can deliver steady, reliable revenue streams to a range of decarbonization projects, programs, and practices, including nature-based solutions and innovative climate technologies that scale up carbon removal. VCMs can also deliver important co-benefits both here at home and abroad, including supporting economic development, sustaining livelihoods of Tribal Nations, Indigenous Peoples, and local communities, and conserving land and water resources and biodiversity. Credit-generating activities should also put in place safeguards to identify and avoid potential adverse impacts and advance environmental justice.

To deliver on these benefits, VCMs must consistently deliver high-integrity carbon credits that represent real, additional, lasting, unique, and independently verified emissions reductions or removals. Put simply, stakeholders must be certain that one credit truly represents one tonne of carbon dioxide (or its equivalent) reduced or removed from the atmosphere, beyond what would have otherwise occurred. In addition, there must be a high level of “demand integrity” in these markets. Credit buyers should support their purchases with credible, scientifically sound claims regarding their use of credits. Purchasers and users should prioritize measurable and feasible emissions reductions within their own value chains and should not prioritize credit price and quantity at the expense of quality or engage in “greenwashing” that undercuts the decarbonization impact of VCMs. The use of credits should complement, not replace, measurable within-value-chain emissions reductions.

VCMs have reached an inflection point. The Biden-Harris Administration believes that VCMs can drive significant progress toward our climate goals if action is taken to support robust markets undergirded by high-integrity supply and demand. With these high standards in place, corporate buyers and others will be able to channel significant, necessary financial resources to combat climate change through VCMs. A need has emerged for leadership to guide the development of VCMs toward high-quality and high-efficacy decarbonization actions. The Biden-Harris Administration is stepping up to meet that need.

Biden-Harris Administration Actions to Develop Voluntary Carbon Markets

These newly released principles build on existing and ongoing efforts across the Biden-Harris Administration to encourage the development of high-integrity voluntary carbon markets and to put in place the necessary incentives and guardrails for this market to reach its potential. These include:

• Creating New Climate Opportunities for America’s Farmers and Forest Landowners. Today, The Department of Agriculture’s (USDA) Agricultural Marketing Service (AMS) published a Request for Information (RFI) in the Federal Register asking for public input relating to the protocols used in VCMs. This RFI is USDA’s next step in implementing the Greenhouse Gas Technical Assistance Provider and Third-Party Verifier Program as part of the Growing Climate Solutions Act. In February 2024, USDA announced its intent to establish the program, which will help lower barriers to market participation and enable farmers, ranchers, and private forest landowners to participate in voluntary carbon markets by helping to identify high-integrity protocols for carbon credit generation that are designed to ensure consistency, effectiveness, efficiency, and transparency. The program will connect farmers, ranchers and private landowners with resources on trusted third-party verifiers and technical assistance providers. This announcement followed a previous report by the USDA, The General Assessment of the Role of Agriculture and Forestry in the U.S. Carbon Markets , which described how voluntary carbon markets can serve as an opportunity for farmers and forest landowners to reduce emissions. In addition to USDA AMS’s work to implement the Growing Climate Solutions Act, USDA’s Forest Service recently announced $145 million inawards under President Biden’s Inflation Reduction Act to underserved and small- acreage forest landowners to address climate change, while also supporting rural economies and maintaining land ownership for future generations through participation in VCMs.
• Conducting First-of-its-kind Credit Purchases. Today, the Department of Energy (DOE) announced the semifinalists for its $35 million Carbon Dioxide Removal Purchase Pilot Prize whereby DOE will purchase carbon removal credits directly from sellers on a competitive basis. The Prize will support technologies that remove carbon emissions directly from the atmosphere, including direct air capture with storage, biomass with carbon removal and storage, enhanced weathering and mineralization, and planned or managed carbon sinks. These prizes support technology advancement for decarbonization with a focus on incorporating environmental justice, community benefits planning and engagement, equity, and workforce development. To complement this effort, the Department of Energy also issued a notice of intent for a Voluntary Carbon Dioxide Removal Purchase Challenge, which proposes to create a public leaderboard for voluntary carbon removal purchases while helping to connect buyers and sellers.
• Advancing Innovation in Carbon Dioxide Removal (CDR) Technology. Aside from direct support for voluntary carbon markets, the Biden-Harris Administration is investing in programs that will accelerate the development and deployment of critical carbon removal technologies that will help us reach net zero. For example, DOE’s Carbon Negative Shot pilot program provides $100 million in grants for small projects that demonstrate and scale solutions like biomass carbon removal and storage and small mineralization pilots, complementing other funding programs for small marine CDR and direct air capture pilots. DOE’s Regional Direct Air Capture Hubs program invests up to $3.5 billion from the Bipartisan Infrastructure Law in demonstration projects that aim to help direct air capture technology achieve commercial viability at scale while delivering community benefits. Coupled with DOE funding to advance monitoring, measurement, reporting, and verification technology and protocols and Department of the Treasury implementation of the expanded 45Q tax credit under the Inflation Reduction Act, the U.S. is making comprehensive investments in CDR that will enable more supply of high- quality carbon credits in the future.
• Leading International Standards Setting. Several U.S. departments and agencies help lead the United States’ participation in international standard-setting efforts that help shape the quality of activities and credits that often find a home in VCMs. The Department of Transportation and Department of State co-lead the United States’ participation in the Carbon Offsetting and Reduction Scheme for International Aviation (CORSIA), a global effort to reduce aviation-related emissions. The Department of State works bilaterally and with international partners and stakeholders to recognize and promote best practice in carbon credit market standard-setting—for example, developing the G7’s Principles for High-Integrity Carbon Markets and leading the United States’ engagement on designing the Paris Agreement’s Article 6.4 Crediting Mechanism . The U.S. government has also supported a number of initiatives housed at the World Bank that support the development of standards for jurisdictional crediting programs, including the Forest Carbon Partnership Facility and the Initiative for Sustainable ForestLandscapes, and the United States is the first contributor to the new SCALE trust fund.
• Supporting International Market Development. The U.S. government is engaged in a number of efforts to support the development of high-integrity VCMs in international markets, including in developing countries, and to provide technical and financial assistance to credit-generating projects and programs in those countries. The State Department helped found and continues to coordinate the U.S. government’s participation in the LEAF Coalition , the largest public-private VCM effort, which uses jurisdictional-scale approaches to help end tropical deforestation. The State Department is also a founding partner and coordinates U.S. government participation in the Energy Transition Accelerator, which is focused on sector-wide approaches to accelerate just energy transitions in developing markets. USAID also has a number of programs that offer financial aid and technical assistance to projects and programs seeking to generate carbon credits in developing markets, ensuring projects are held to the highest standards of transparency, integrity, reliability, safety, and results and that they fairly benefit Indigenous Peoples and local communities. This work includes the Acorn Carbon Fund, which mobilizes $100 million to unlock access to carbon markets and build the climate resilience of smallholder farmers, and supporting high-integrity carbon market development in a number of developing countries. In addition, the Department of the Treasury is working with international partners, bilaterally and in multilateral forums like the G20 Finance Track, to promote high-integrity VCMs globally. This includes initiating the first multilateral finance ministry discussion about the role of VCMs as part of last year’s Asia Pacific Economic Cooperation (APEC) forum.
• Providing Clear Guidance to Financial Institutions Supporting the Transition to Net Zero. In September 2023, the Department of the Treasury released its Principles for Net- Zero Financing and Investment to support the development and execution of robust net- zero commitments and transition plans. Later this year, Treasury will host a dialogue on accelerating the deployment of transition finance and a forum on further improving market integrity in VCMs.
• Enhancing Measuring, Monitoring, Reporting, and Verification (MMRV) The Biden-Harris Administration is also undertaking a whole-of-government effort to enhance our ability to measure and monitor greenhouse gas (GHG) emissions, a critical function underpinning the scientific integrity and atmospheric impact of credited activities. In November 2023, the Biden-Harris Administration released the first-ever National Strategy to Advance an Integrated U.S. Greenhouse Gas Measurement, Monitoring, and Information System , which seeks to enhance coordination and integration of GHG measurement, modeling, and data efforts to provide actionable GHG information. As part of implementation of the National Strategy, federal departments and agencies such as DOE, USDA, the Department of the Interior, the Department of Commerce, and the National Aeronautics and Space Administration are engaging in collaborative efforts to develop, test, and deploy technologies and other capabilities to measure, monitor, and better understand GHG emissions.
• Advancing Market Integrity and Protecting Against Fraud and Abuse. U.S. regulatory agencies are helping to build high-integrity VCMs by promoting the integrity of these markets. For example, the Commodity Futures Trading Commission (CFTC) proposed new guidance at COP28 to outline factors that derivatives exchanges may consider when listing voluntary carbon credit derivative contracts to promote the integrity, transparency, and liquidity of these developing markets. Earlier in 2023, the CFTC issued a whistleblower alert to inform the American public of how to identify and report potential Commodity Exchange Act violations connected to fraud and manipulation in voluntary carbon credit spot markets and the related derivative markets. The CFTC also stood up a new Environmental Fraud Task Force to address fraudulent activity and bad actors in these carbon markets. Internationally, the CFTC has also promoted the integrity of the VCMs by Co-Chairing the Carbon Markets Workstream of the International Organization of Securities Commission’s Sustainable Finance Task Force, which recently published a consultation on 21 good practices for regulatory authorities to consider in structuring sound, well-functioning VCMs.
• Taking a Whole-of-Government Approach to Coordinate Action. To coordinate the above actions and others across the Administration, the White House has stood up an interagency Task Force on Voluntary Carbon Markets. This group, comprising officials from across federal agencies and offices, will ensure there is a coordinated, government- wide approach to address the challenges and opportunities in this market and support the development of high-integrity VCMs.

The Biden-Harris Administration recognizes that the future of VCMs and their ability to effectively address climate change depends on a well-functioning market that links a supply of high-integrity credits to high-integrity demand from credible buyers. Today’s new statement and principles underscore a commitment to ensuring that VCMs fulfill their intended purpose to drive private capital toward innovative technological and nature-based solutions, preserve and protect natural ecosystems and lands, and support the United States and our international partners in our collective efforts to meet our ambitious climate goals.

Stay Connected

We'll be in touch with the latest information on how President Biden and his administration are working for the American people, as well as ways you can get involved and help our country build back better.

Opt in to send and receive text messages from President Biden.