Skip to main content

Principle #2: Embrace Change

Harness changing requirements and creative input from all stakeholders for competitive advantage.

Change is inevitable. What is true in software engineering in general is doubly true for building data products. Working with multiple sources of data brings in a number of additional stakeholders and draws internal and external governance scrutiny. That means requirements can quickly change or may not be known until a data product implementation is well on its way.

Why Data Product Implementations Resist Change​

data product processes that rely on detailed planning and long development cycles tend to resist change because it is highly disruptive to the process. If a change in requirements invalidates weeks of meticulous planning, it is understandable why a team would try to ignore the change rather than go back to the planning phase. And who knows if legal was serious about their PII directive....

However, resisting change endangers the success of the entire project and is often the reason data products do not deliver value.
In addition, resisting change often goes hand-in-hand with an effort to limit the amount of feedback the team is subject to which can shut out important input.

Build Data Products with Change in Mind​

We find that development teams which embrace and optimize their infrastructure for change tend to deliver successful data products faster and at lower cost. In addition, they are at a competitive advantage because they can harness creative input from all parts of the organization.

In order to embrace change, the development process should:

  • Keep development cycles short so that feedback and change can be incorporated quickly.
  • Prioritize continuous requirements and problem space refinements over detailed planning.
  • Allow team members to interface directly with customers and key stakeholder in order to shorten feedback cycles and avoid loss of information in long communication chains.