Build the right product with results-driven development
When developing a product, it’s important to ensure that you’re not only building things the right way, but that you’re building the right product. These two goals don’t have to be mutually exclusive.
In this post, I’ll detail two development processes: test-driven development and results-driven development. These concepts, when used together, can achieve both goals.
What is test-driven development?
In 2002, Kent Beck, the creator of extreme programming (XP), released the book, Test-Driven Development: By Example. The concept was simple: In order to start writing code, you must first write a test that defines what success looks like for a given requirement. You then run the test, but because you haven't written any code yet, the test fails. It's at that point you start developing just enough code to pass the test.
Test-driven development (TDD) helps produce high-quality code that is tightly aligned to requirements. However, TDD doesn’t tell you if the requirement you selected to write the test against is of any value, or if the resulting product you create will be of any value to the end user. This is where results-driven development (RDD) comes in.
With RDD, you start by defining the result you want. You then create the means to measure those results through metrics, and evaluate whether you've achieved your results. Since you haven't started creating a product, you won't achieve any results at first. It's only at this point that you start iterating on your product. As a result, you produce the least amount of product necessary to achieve the results you want.
With TDD, you continually evaluate the value of your code, while RDD continually evaluates the value of your product. With RDD, results drive the design of the product—they determine whether the product is valuable. Until the results are met, the product is considered useless.
Results-driven development: A practical example
Results-driven development starts by specifying a result, defined as a specific, measurable, and realistic goal you want to achieve. A common approach to defining a result is through metrics. For example, let’s say that you want to create a digital bank. Since you don't have a product yet, you need to start small and grow. It's important that you don't attempt to boil the ocean. Setting an overwhelming goal from the beginning will impede progress, create waste and ultimately result in failure.
It’s also important to distinguish between a result and a vision. Your vision might be to create the best digital banking experience. How you achieve that vision is driven by your results. It's more important to show progress towards a vision through results than to make auspicious claims that demonstrate little or no progress.
For our example, let's set ourselves a simple goal of successfully on-boarding and retaining one client account. To be effective, results should be incremental and focused. You can always set a new goal once you've reached your desired result.
After setting your goal, you then need to determine how to measure this result. In this example, the primary metric is the number of active accounts, which is simple to measure. However, as you continue to build your product, you’ll want to consider additional metrics, such as the on-boarding drop-off rate, account closure rate and user account activity. Build these metrics into the product from the beginning so that you can verify that the product is meeting the market's needs.
Now that you’ve identified metrics to define your goal, you can start building your product and defining the backlog. Prioritize the effort to create your metrics in the initial release so that you can continually evaluate whether you've reached your goal. Once you've measured results, you can start building functionality in a hypothesis-driven way to experiment and iterate on ideas. After each feature release, evaluate the status of your results and decide whether to iterate on the product more or move on to another goal.
Test-driven development and results-driven development: A symbiotic relationship
Results-driven development creates products with high-quality requirements that have strong product-market fit and produce minimal waste. However, that’s not to say that one framework is better than the other. The following table shows how the framework used to create TDD aligns with RDD.
Where TDD challenges you to define your test before you start writing code, RDD challenges you to define your result before you start creating a product. RDD encourages you to adopt an iterative approach to building products by using inspect-and-adapt principles. It's a key component of a Minimum Viable Feature (MVF), Minimum Viable Products (MVP), and Minimum Marketable Products (MMP) release strategy for validating assumptions, measuring results and iterating on feedback. The combination of results-driven development and test-driven development ensures that you build the product right and you build the right product.