Today, modern product teams need to get user input at scale to create user-facing experiences that delight and bring value.
Yet, there’s a disconnect between how teams create products and how they learn from users. Getting access to user insights takes weeks, usually relying on face-to-face interviews or equally long video recordings.
To solve this central pain point of building products, we’re excited to introduce the Rapid Testing Framework to help you test, learn, and act faster by getting user insights at every stage of the process.
Let’s start by looking at why learning fast is important for organizational success and why we need a new way to approach building products today.
Why learning fast and early is important
Over the past 20 years, the product development world transitioned from waterfall to agile development processes as startups started adopting the Lean methodology to deliver products to market faster.
Six-month-long projects were soon replaced by smaller, monthly deliverables as the product development process transitioned to an incremental approach to delivering software. This led to a dramatic increase in the speed of shipping new products, but most importantly, increased our opportunities to learn from our users.
Learning— and failing—enables teams to adjust their trajectory quicker by understanding what works and what doesn’t. The capacity of a company to adjust is what makes it successful. Doing this at a rapid, constant pace allows organizations to remain relevant and continue delivering value to customers. In the face of today’s increased customer expectations, speed is a competitive advantage.
76% of consumers expect companies to understand their needs and expectations.
But when you only learn after the work is completed, most of the building cycle is an act of faith. Waiting until launch to understand if the feature, copy, or designs work with your target audience—and collect insights on how to improve—produces slow-paced organizations that can’t meet the needs of their customers at a satisfactory rate.
After more than 20 years, we're faster at building but we're still not better at learning faster and avoiding rework.
The cost of learning too late
In order to derisk the building process and address this learning gap, companies have historically invested in user research. This translated into more researchers joining product departments. However, research is a slow, limited, and expensive pursuit. It takes around 120+ hours to complete a research study and costs between $12,000 and $18,000 (Source).
Additionally, research is also underrepresented and has limited buy-in in most organizations. As a result, product teams have to rely on limited or no data to make decisions. And the numbers show it:
- 55% of teams have a research budget of less than $99/month
- The most typical researcher-to-designer-to-developer ratio is 1:5:50 (Source)
- 42% of companies don’t collect feedback from their customers (Source)
Which leaves product teams learning too little, too late.
The single biggest driver of business impact is the strength of an organization’s learning culture.
Josh Bersin, President Bersin by Deloitte
In the existing product build process, every learning opportunity comes at the cost of a full building cycle. In a piece titled “Why Software Fails” for the IEEE Spectrum, Robert N. Charette reports that 40-50% of programmers’ time is spent on avoidable rework. Unfortunately, this only scraps the surface of the total cost of learning too late. The cost of releasing the wrong product, copy, UX, or feature also includes:
- The cost of rework accounted for the entire product team
- An increased cost of support required to manage incoming inquiries and complaints
- The cost of lost business from customers churning and not converting
- The cost of brand damage from frustrated users
“Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage,” continues Robert N. Charette in that above-mentioned article. Shouldn’t there be a better way to build products today?
Meet rapid testing, a way to test and learn throughout the product build cycle
The modern, agile teams of today need faster access to user input to form a complete understanding of their users at each stage of the process. Nowadays, to keep up with the nature of building software, everyone in the organization needs to be able to test and learn from users. That’s where rapid testing comes in.
Rapid testing is a decision-making framework in which every product decision is made with input from users. The goal of rapid testing is to remove all the guesswork from building digital products by relying on insights from users every step of the way. Rapid testing is not about making everyone a researcher—it's about allowing testing to happen in every department.
How rapid testing changes the way you build
With rapid testing, every user-facing experience is exposed to users as it’s being created. When you incorporate rapid testing into your team’s workflow, you can test and learn from users fast and iterate on the final experience until it’s ready for launch.
Rapid testing changes the way your team builds products because it:
- Makes testing a team sport
- Democratizes data inside your organization
- Builds institutional knowledge
First, when you implement rapid testing in your product building process, every department becomes accountable to one another. Everyone is responsible for testing their work and incorporating user insights into their output. The result is a validated process from beginning to end with product managers only adding proven features to the roadmap, designers sharing fully tested designs, and marketers publishing tested copy and messaging. Like a relay race, each sprinter trusts the one before him.
Rapid testing enables the democratization of data inside organizations as each department has access to user insights.
This iterative process prevents your team from building the wrong thing by giving everyone in the team access to user input and actionable learnings. Rapid testing enables the democratization of data inside organizations as each department has access to user insights.
Teams that test and learn rapidly build institutional knowledge about what works and what doesn’t over time.
Last but not least, the more consistently you test and acquire user input, the more nuanced your understanding becomes. Consequently, teams that test and learn rapidly build institutional knowledge about what works and what doesn’t over time.
Now that you understand the benefits of rapid testing let’s see how you and your team can implement it with the Rapid Testing Framework.
The Rapid Testing Framework
Rapid testing is based on the application of the continuous testing principles to the entire building process—from idea to release. To make rapid testing possible, every organizational department is responsible for testing their part of the process. This is supported by The Rapid Testing Framework.
In the Rapid Testing Framework, every point of decision becomes a testable input. Problems, concepts, designs, copy—all of these are testable inputs that need to be validated before launch.
To get started with rapid testing, the design and product development process is broken down into small, testable inputs to enable learning every step of the way through iterative loops. The iteration loop begins once a testable input has been identified.
How to implement the Rapid Testing Framework: IOTA loops
In the system of Greek numerals, an Iota is the smallest amount possible. In the Rapid Testing Framework, an IOTA is the smallest meaningful iteration loop. The name stands for Input, Objective, Test, and Analysis. Let’s look at these steps in detail.
Every IOTA loop is defined by the following elements:
- Input: What decision do we need to make that needs to be tested?
- Objective: Which quantifiable metric(s) should we reach to validate the decision?
- Test: What setup do we need to use to collect actionable data at scale?
- Analysis: Was the objective achieved, or do we need to test again?
The product building process is made up of small decisions that are diffused across an organization and make up the final product. And so the testing process starts with an input—a decision that needs to be made. The decision can range from the feature to build, the copy to use, the user interface to design, or the pricing to offer. For all these decisions, user insight is key.
Examples of questions that teams may use as testable inputs are:
- "Which feature idea should we build?"
- "Is this user flow working?"
- “Is the design easy to use?”
- "Which message speaks best to our audience?"
Once the input has been established, the next step is to set the objective. This is the key result(s) that should be reached to validate—or invalidate—the decision. Setting the objective before you start testing is essential. If the results match the objective of the input, the decision can be made and the next phase can start.
The test is the setup necessary to collect the data you need. Whether that is a user survey, customer interview, or usability test—the third stage of the IOTA loop is setting and creating the test.
Finally, in the analysis part, the data is assessed to determine the next steps. If the results of the test match the objectives of the input, the decision can be made and the next phase can start. If not, a cycle of iteration follows until the objective is reached or the decision invalidated.
Maze, the product research platform for modern, agile teams
Maze is the Product Research Platform that enables rapid testing and gives modern teams actionable user insights, in a matter of hours. Made for user-facing experiences, teams can test remotely, autonomously, and collaboratively and see results transform into the metrics that matter. Unlike qualitative testing tools that rely on expensive and time-consuming moderated research, Maze empowers anyone to test. From usability tests to user surveys, teams can democratize the entire testing process and make user insights accessible, company-wide.