feature hypothesis template

The ART of SAFe

Applying Lean and Agile techniques at scale to bring about effective, sustainable improvement in Culture, Execution and Business Results

Monday, January 8, 2018

Effective feature templates for safe, introduction, how much detail is needed, and by when.

• Prior to WSJF assessment
• Prior to PI Planning

Feature Canvas

New Product: “The current state of the [domain] has focussed primarily on [customer segments, pain points, etc]. What existing products/services fail to address is [this gap] Our product/service will address this gap by [vision/strategy] Our initial focus will be [this segment]”

Existing Product: “Our [service/product] is intended to achieve [these goals]. We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”

“We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]”.

Sample Completed Canvas

A glimpse at how you might visualise your next WSJF estimation workshop

Detail beyond the Canvas

• User Journeys:  Some framing UX exploration is often very useful in preparing a Feature, and makes a great support to teams during PI planning.  
• Architectural Impact Assessment: Some form of deliberate architectural consideration of the potential impact of the feature is critical in most complex environments.  It should rarely be more than a page – I find a common approach is one to two paragraphs of text accompanied by a high level sequence diagram identifying expected interactions between architectural layers.
• Change Management Impacts: How do we get from deployed software to realised value?  Who will need training?  Are Work Instructions required?  

Tuning your Template

Who completes the canvas/template, 30 comments:.

Awesome work Mark! We have created some for clients too that we can't share. :-(

Thanks for sharing Mark - these are really useful. I really like the hypothesis statements for features and think that this is a major enhancement in SAFE 4.5. I wrote a blog post about it here: http://runningmann.co.za/2017/09/25/the-power-of-feature-hypotheses/ that you might be interested in.

These are awesome Mark. Thanks for sharing

Thanks for sharing your experience on this area with the community Mark. Feature Templates are a very common requirement for Agile practitioners, maybe you can persuade the SAFe community to include an artefact like this in the framework.

Information was good,i like your post. Looking forward for more on this topic. product management

This is great! Do you have the template format available so we don't have to replicate?

great stuff, how would you differentiate this from SAFe Epics

Other problems include editing resistance, lack of or significantly delayed communications and lack of professionalism. website

I discovered your blog site site on the search engines and check several of your early posts. Always maintain up the very good operate. I recently additional increase Rss to my MSN News Reader. Looking for toward reading much more on your part later on!… apple tablet mockup

I genuinely treasure your work , Great post. ipad mockups

When I originally commented I clicked the -Notify me when new surveys are added- checkbox and from now on every time a comment is added I buy four emails with similar comment. Perhaps there is any way you are able to eliminate me from that service? Thanks! web design company san francisco

Good post and a nice summation of the problem. My only problem with the analysis is given that much of the population joined the chorus of deregulatory mythology, given vested interest is inclined toward perpetuation of the current system and given a lack of a popular cheerleader for your arguments, I’m not seeing much in the way of change. web design company san francisco

Cutting up pictures, reestablishing of old photos, working around with watermarks, and other progressed tips and deceives can likewise be found in a high caliber and significant Adobe photograph shop instructional exercise. Professional graphic design

Very efficiently written information. It will be beneficial to anybody who utilizes it, including me. Keep up the good work. For sure i will check out more posts. This site seems to get a good amount of visitors. essay writing service

Their willingness to partner with us has been great. UI design agency

Hey enormous stuff or pleasant information you are offering here. best branding agencies

Nice blog Mark How can I get a downloadable version of this Canvas?

I think you can make video about it. If you want to promote your channel on youtube you can buy youtube subscribers for it

Thanks for this incredible information. I think you could make a video about feauture templates for sale and post it on Instagram. By the way if you want to get more followers for your profile, you can repeatly use the help of https://viplikes.net/buy-instagram-followers to quickly boost their number.

Socialize Club- Buy Facebook live stream views cheap in price but high in quality.We provide you with 100% Real Facebook live stream views delivered at your facebook live video instantly.

Packaging should function as a barrier to air, water vapor, dust, and other contaminants. Because food items might be in liquid form, they must be leak-proof to avoid loss during transportation. BOPP film supplier

percetakan buku online di jakarta percetakan murah jakarta percetakan online jakarta percetakan Jakarta timur cetak murah jakarta cetak online jakarta digital printing jakarta print murah jakarta jasa print murah cetak buku murah di jakarta timur

I use the aforementioned off-page SEO techniques and am currently seeing the results of my labors with page 1 Google search engine rankings. For example, Deanna Hibbs, a full-time working mother, discovered internet marketing while searching for a work schedule other than 9 to 5. SEO philadelphia

thank you for share an informative blog article with us. kitimesblog

Essential phases

This comment has been removed by the author.

Produk Elektronik Terbaik Saat Ini Bahan dapur memasak ikan Bumbu dapur ayam goreng Menjual bahan dapur Shin Tae Yong coah terbaik sepanjang masa Justin hubner bek andalan timnas indonesia Nathan Tjoe a on bek bule berdarah indonesia yang membela timnas Jualan tanpa modal hanya dengan perlengkapan dapur

The Feature Writing Canvas

The Feature Writing Canvas offers a comprehensive template for the formulation of features to anyone working in a Scaled Agile environment in order to deliver real value to end users.

When to use The Feature Writing Canvas

As a Product Manager, Product Owner or Solution Architect working in a Scaled Agile environment, features are a key element in defining what is implemented. Thus, the quality of the definition of features is key to deliver real value with each feature. And this not only for internal clients (who are often important stakeholders), but first and foremost for the end user.

The Feature Writing Canvas is of use in many ways:

As a guide for the Product Manager/Owner to clarify the actual needs when talking to business sponsors / clients

For the whole team during a PI Planning session, should questions on the (pre-) defined work to do arise

As a compass for inspect & adopt or review & improvement sessions, to check the impact of the way features are described on the delivered outcomes

How does The Feature Writing Canvas work?

You will be guided through three main categories:

Beneficiaries: Even if it can be tough to achieve for larger IT projects, it is key to know who the end users of your work will be and resultant to know what their needs are. For this reason, do not only follow the client’s lead on his requirements, but challenge them using the questions in this part of the canvas regarding the end users.

Benefit hypothesis: Use as a standard the wording If (proposition), then (benefit) for describing the benefit hypotheses as it describes the value you expect it to deliver. Writing a feature, use this part of the canvas to challenge yourself by asking the added questions.

Acceptance criteria: Use part of the canvas to challenge your defined acceptance criteria and relate them to the benefit hypotheses.

• Research & Design
• Agile Workflows
• Strategy & Planning

Submit your template →

Do you have a great board to share with the world? We' ll help you turn it into a template to share with the community.

Similar templates

8 Different Ways to Organize Your Backlog

Content Strategy - Fours Steps Process

Product Launch Board

Prototypical Feature Template

The Running Mann

Humorous Anecdotes, Observations & Accounts of Marathon Running & Agile Adventures.

The Power of Feature Hypotheses

One of the improvements SAFe version 4.5 introduced was incorporating practices from “ The Lean Startup ” into the framework – specifically the use of benefit hypothesis statements into features and epics. This is a story of how well this worked for us.

We were worried about the standard of feature writing across our teams and also wanted to bring them up to speed with the SAFe 4.5 feature hypothesis thinking. Therefore, we organised a Friday afternoon “Lunch and Learn” session for interested team members.

The main objective was to go over a practical example from one of our feature teams and convert an existing feature into a ‘ valuable feature hypothesis statement ‘.

[If you are unfamiliar with the Lean Startup concept of hypotheses, please see supporting post:  Using Hypothesis Statements for Features in Software Development ]

Getting A Feature Benefit Hypothesis Statement

We started with the feature captured below that, no disrespect to team, was not very well written. The definition I like to use for a well written feature is that: ‘ someone outside the team can read it once and understand what needs to be done ’. At this stage I don’t even think that most of the team understood the feature.

Luckily we had the product owner (PO) in the room. We asked him a few probing questions that went something like this.

Team: Why are we doing this change? What is the benefit? PO: We need to update the audit report fields for our customers. Team: Why do they need the additional fields. PO: So that customers can check for errors before they submit them to us for processing. Team: Why do they check for errors? How does this work? PO: All customers have a QA person or someone similar checking these reports to prevent errors being processed. When errors get missed and processed, it wastes time and causes a lot of frustration. Team: So what exactly is the current problem? PO: Today, customer auditors can’t see all the relevant information on the audit reports for cross-checking and referencing so many errors are still processed. Team: What is the intended result of this change? PO: We’ll reduce the error rate by 95%. [And BAM! We get our hypothesis]

Interesting takeout: The PO did not come right out with the “95% error reduction” even though it was in his head from the start – it required a conversation to get his knowledge shared with the rest of the team. This is part of the magic of conversation within collocated teams – and the importance of having a PO who works with the team.

The benefit hypothesis makes the “why” clear to without having to write a long document. Everyone in the room quickly came to the same understanding as to what needed to be done and why. A well worded hypothesis statement helps remove ambiguities and focuses the team on what really needs to be done. [To understand why “why?” is important – see Simon Sinek’s TED Talk below.]

The other (perhaps even more) positive outcome is that it gives “purpose” to the teams’ work. I asked the group, “Would you rather (a) update some fields on an audit report or (b) reduce error rates by 95%?” – unsurprisingly there was unanimous agreement that (b) was the more exciting option.

“Reducing error rates by 95%” gives meaning to the team’s work. I am unlikely to go home and proudly tell my kids I updated some fields on an audit report. But telling them that I helped reduce foreign exchange error rates by 95% makes my job as a developer on a transactional banking system sound sexy and important!

Feature Acceptance Criteria & Slicing

We then moved onto the feature acceptance criteria (AC). The simple way I view feature AC is, “ How will we UAT the feature to know that it’s complete and fit for purpose? ” (as opposed to user story AC which are the actual unit test cases).

If you are not able to write clear AC you don’t know enough to proceed with the feature so this was a good test of the strength of our feature hypothesis. Once again it was an interesting and valuable discussion with participants throwing various questions at the PO. A summary is below:

Which countries are in scope?

The PO initially said “all countries”. Further conversation sliced it down to two countries (South Africa and Uganda) where there was definite current need – from there it made sense to split the feature into one for each country. South Africa had the most urgent need so we focused on that and the lower priority Uganda feature went onto the backlog (where it will remain until it becomes priority). The requirement that the initial feature for South Africa be scalable for other countries was included as a non-functional requirement.

Attempted slipping in of a production defect

The PO tried to slip a production defect into the AC (the format of the onscreen and printed reports are different). The team deftly managed to slice the defect off the feature (the defect fix is roughly the same size as the eventual feature). The valid defect was added to the team backlog (where the PO can prioritise it against other work to determine when it will get fixed).

Attempted scope creep

The PO also tried to slip a new requirement into the AC – the ability to be able to save audit reports as a .pdf file. Once again the team deftly convinced the PO that this was not part of the minimum viable product (MVP) by referring to the hypothesis statement (i.e. we don’t need to save to .pdf to test the hypothesis). The valid requirement was also added to the team backlog (and the PO gets to decide when it’s priority enough to be built).

Interesting takeout: In my opinion, the PO was doing his job perfectly – trying to get as much as possible into the feature to maximise the customer benefit. Because he’s part of the overall team having the conversation he gets to understand the trade-offs involved with different decisions. When posed with the question, “Do you want to have the feature done in 2 weeks if we just do MVP or do you want to wait for 2 months if we do ‘ all this other stuff ‘?” a good PO will always go for “ small and fast “.

By reducing the feature to a single (highest priority) country and omitting other requirements that (whilst important) had no impact on the hypothesis statement, the feature ended up being at least 10 times smaller than if we’d tried to include everything. Slicing the feature down to get the most value with the least amount of work drastically increases the speed with which it can be built and dramatically reduces risk.

The team left the room knowing exactly what needed to be done. More importantly everyone had agreed on what didn’t need to be done “right now” (i.e. in the next sprint) because they were not MVP (however these requirements have been added to the team backlog and can be done when the PO prioritises them). The PO was also part of all the decisions taken so he should get no nasty surprises when the feature is presented back as “done”.

Conclusion: Super-Quick Delivery

The best part of this story was that two weeks later when I asked the team “How’s the feature going?”, the reply was “It’s already done.”

The team was able to fully design, build and test a valuable feature in less than two weeks (fitting easily into a 2-week sprint). In the past a feature like this would usually take 12 months to deliver (see the supporting post “ 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery “). By slicing the feature down to its true MVP and the team knowing exactly what was needed and why, the feature flew through the development value stream.

Of course, now the real test is to measure whether our hypothesis proves true and we successfully reduce the error rate by 95% – let’s hope so! We’ll know pretty soon…

The actual reduction in client error rates was 80%. As it stands this has been deemed sufficient. There are no plans to build additional features to further reduce the error rates (as there have been higher priority features to work on). Likewise, the production defect has not been fixed (and may never be) since it has never been a priority compared to other more beneficial work.

I delivered a presentation on “The Power of Feature Hypotheses” at Agile Africa 2018 using this and other examples. Here is the video link from the conference:  https://youtu.be/CUVX1AiqQak?list=PLp6xQ3fl72zIu8FJjDtBUFUS0w1FPQhPZ

I am also more than happy to submit a speaker proposal for your conference. Feel free to contact me via email: [email protected] or Twitter @runningmann100 /  @StuartDMann .

4 Replies to “The Power of Feature Hypotheses”

• Pingback: 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery - The Running Mann
• Pingback: Using Hypothesis Statements for Features in Software Development - The Running Mann

Good account of what we discussed in the session and what was learnt. Going forward it will definitely provide a mechanism for us to access information on the sessions to further unpack.

• Pingback: How George Costanza, Frogger & a Craving For Sushi Help Explain Features & User Stories - The Running Mann

Leave a Reply Cancel reply

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

Please enable JavaScript to submit this form.

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

Jeff Gothelf

Your cart is currently empty!

How I break down hypotheses to make them easier to test

For years I’ve been advocating for teams to reframe their product and feature ideas as hypotheses. There are four reasons:

• Hypotheses reflect the real world doubt inherent in digital product development
• Hypotheses change the definition of done from “works as designed” to achieving an outcome
• Hypotheses tie every feature idea to a specific target user
• Writing a believable hypothesis for your feature idea is the first test of that idea

When teams start writing hypotheses for the first time, though, they end up writing huge hypotheses. The scope of the hypothesis makes it difficult if not impossible to test. Here’s how I work through a big hypothesis to break it down into testable components. 

First, I break the feature down into individual steps

Here’s the hypothesis template that I use:

We believe that [this outcome]

Will be achieved if [these people]

Attain this [goal/benefit]

With [this feature] .

A consumer lending team I was working with recently wrote this hypothesis for a new mortgage application process they were working on:

We believe we will increase mortgage application completion rates by 55% if first time homebuyers don’t have to prepare any documents upfront with a broadly integrated, end-to-end mortgage application process . 

I said to them, “Great! Go test that.” They looked at me and smiled. They knew there was no way to test this whole thing in one attempt. And it quickly dawned on them that they didn’t know where to start. 

The first thing I did was ask them to break down the components that made up the “broadly integrated, end-to-end mortgage application process.” This they could do!

The hypothetical system will:

• Not ask for any client documentation up front
• National credit reporting agencies
• Payroll systems
• Real estate sales systems
• Other lending systems
• Social networks
• MLS (US real estate database)
• Geographic and address databases
• Include AI integration that will parse all of the relevant user data and provide practical next steps in the mortgage application process

Next, I asked them to think through the various risks involved in each of these components. What’s the most important thing to learn about each of them? The team chimed in with answers that varied from the valuable (Will anyone want this?) to the technical (Can we build this?) to the practical (How long might this take to build?). 

Anytime you’re building a new system, regardless of how technically complex it might be, testing the value of the idea is the best place to start. If no one wants it, it doesn’t matter how hard or easy it is to build it. 

Next, I identify the learning goal

The team settled on a value question – will first time home buyers feel comfortable starting and completing a mortgage application process without having to do any preparation in advance? Most people assume this is an onerous process and one that doesn’t make that heavy of a request may seem sketchy, untrustworthy or worse, fraudulent. 

Notice how far we’ve already come. We started with “end to end integrated system” and are now already focusing on a very specific step in the customer journey. Will people even give this thing a shot?

Now that we had a question, I asked the team to tell what they wanted to learn about the question. They made a list:

• What makes a mortgage application system trustworthy?
• What do you expect the process to be? How long should it take?
• What would make a mortgage application process seem untrustworthy?
• What would make you abandon a mortgage application?
• Does AI enhance or erode the trustworthiness of a mortgage application process?

There were more questions but this list gave us a clear direction. We needed to get a better sense of what first time homebuyers trust a mortgage lending system. 

Finally, I can design a simple experiment

If, “What’s the most important thing we need to learn next?” is the opening question in our test and learn loop, “What’s the least amount of work we need to do to learn that?” is the closing question. When we started out, the hypothesis was so huge the only realistic answer to the second question was, “build the whole thing” – the riskiest and most expensive way to find out if something works as we hoped. 

Now, however, we have a clear question around the trustworthiness of mortgage application systems. The smallest thing we can do to learn that seems much more feasible. We can easily:

• Interview first time home buyers before they apply for mortgages
• Interview them after they’ve applied and/or bought a home
• Observe users as they apply for mortgages

The data the team collects with these experiments starts to inform other risks they’ve identified and they have a better direction of where to head next. Each time a cycle is complete, the questions come up again, “What’s the next most important thing we need to learn?” We take another part of the hypothesis and work through it. In a perfect world we derisk the whole thing and build it over time. In the real world, we’ll adjust our plans, pivot and in some cases decide not to build the thing at all. 

Practice makes perfect

The more I work with teams, the more hypotheses they write, the better they get at them. They become more specific, smaller and, most importantly, testable. However, most teams will start with huge hypotheses. The process I’ve described here has worked for me week over week for nearly 15 years in breaking these down with teams to get them unstuck and moving forward in their discovery and delivery process. I hope it works for you too. 

Jeff Gothelf’s books provide transformative insights, guiding readers to navigate the dynamic realms of user experience, agile methodologies, and personal career strategies.

Who Does What By How Much?

Sense and Respond

Lean vs. Agile vs. Design Thinking

Forever Employable

3 responses to “How I break down hypotheses to make them easier to test”

Hi Jeff, just noticed that in your first paragraph you appear to have accidentally made a rogue “4th reason” out of what I understand to be the first sentence of your next paragraph. Thought you might like to know 🙂 Great article by the way! Might use it to teach my students about how to construct and break down their hypotheses and RQs.

Fixed! Good catch. 🙂

[…] Gothelf on breaking down hypotheses for new […]

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. One cutting-edge approach involves graph-based RAG , which enhances decision-making by integrating graph data structures for more accurate and contextually relevant results. 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! 

40+ Fundamental Product Discovery Questions Founders Should Answer

Is No-Code MVP Development Worth It?

Why to Outsource MVP Software Development in 2025

Never miss an update.