Introduction
In my experience across various industries, one of the most common and challenging issues I've encountered is the quality of requirements. Whether you're tasked with delivering a data pipeline, a data model, or a dashboard, poor requirements can make your job significantly more difficult.
When requirements are unclear or incomplete, your day-to-day work can turn into guesswork, often leading to wrong assumptions and more iterations with the customer. The most troubling aspect isn't just the decrease in productivity, but the erosion of trust between you and your customer.
Unfortunately, there isn't a one-size-fits-all solution for gathering requirements. The process can vary widely based on factors such as the maturity of your customer, the complexity of the domain, the means of communication, and the type of data product you're working on.
Despite these challenges, there are key areas you can focus on to improve the quality of your requirements and avoid common pitfalls.
Common Language
Customers or end-users of a data product are usually domain experts, while you bring a technical perspective. This difference can create a communication gap that needs careful attention.
One common issue is domain-specific terminology. Customers may use this terminology to describe their requirements, but these terms often conceal complexities that need to be translated into data terms. Maintaining a terms dictionary can help streamline communication and ensure everyone is on the same page.
Defining What is Best for the Customer
Sometimes, customers may not fully understand their own needs. They might want to make their department or team data-driven, which is a strategic goal but often lacks specifics. If the customer can't clearly articulate what they want, you need to guide them through the process. This involves asking the right questions and resisting the urge to fill in the gaps yourself. This is one of the trickiest parts of the job.
Customer Focus on What, Data Professional on How
When assessing requirements, the focus should be on identifying the problems that need solving and the available data sources. The customer should focus on what they need, and you should focus on how to deliver it. They can choose the 'how' from the options you provide, but it's your job to outline those options.
Understanding the Context is Vital
Building a solid understanding of the context is crucial. Knowing how the product you're asked to build will be used provides valuable guidance. Developing a basic understanding of the domain helps you step into your customer's shoes and work backward from domain initiatives to technical solutions. Keeping the bigger picture in mind can save hours of investigation and multiple iterations with the customer.
Requirements are Not Instructions
It's important to remember that requirements are not instructions. You need to step out of your comfort zone and understand how the data describes the domain. The actual instructions for building the data product are for you to determine, not the customer.
Managing Iterations
While agile frameworks that support iterations are common, the number of iterations should be just enough to gather the necessary information. This means you need to be well-prepared for each meeting with the customer to make the most of each interaction.
Conclusion
Poor requirements can lead to numerous shortcomings, including unnecessary iterations and wasted effort. By paying attention to these critical areas, you can improve the quality of your requirements and deliver data products that truly meet your customer's needs. This not only enhances productivity but also builds trust and establishes you as a professional in your field. At the end of the day, consistently striving to improve your requirement-gathering skills will lead to better outcomes.
