Data Syndrome
Meanderings of Russell Jurney @rjurney
-
Agile Data Product Development
New product teams are exciting.
You have a grand vision for a game changing product. There is excitement and chatter around different features and how to build them. Everyone wants to sell everyone else on their idea. With the spectrum of skills of a data product team, the possibilities are endless.
Spanning so many disciplines, building web products is inherently collaborative. To collaborate, teams need direction: every team member passionately and stubbornly pursuing a common goal. To get that direction you require consensus.
Consensus
Building and maintaining consensus while collaborating is the hardest part of building software. The principal risk in software product teams is building to different blueprints. Clashing visions result in un-cohesive holes that sink products.
Most applications are mocked before they are built: product managers conduct market research while designers iterate mocks with feedback from prospective users. These mocks serve as a common blueprint for the team. Real-world requirements change even when our data is static, as we learn from our users and conditions change. So these mocks must change with time. Agile methods were created to facilitate implementation of evolving mocks, and to replace subsets of mockups with real working systems as soon as possible.
Agile Data
Typical web products - those driven by forms backed by predictable, constrained transaction data in relational databases - have fundamentally different properties than products featuring mined data. In CRUD applications, data is relatively consistent. The models are predictable and changing them is a product decision. The data’s opinion is irrelevant, and the product team is free to impose its will on the model to match the business logic of the application.
In interactive products driven by mined data, none of that holds. Real data is dirty. Mining always involves dirt. If the data isn’t dirty, it wouldn’t be data mining. Even carefully extracted and refined mined information can be fuzzy and unpredictable. Presenting it on the consumer internet requires long labor and great care. In data products, the data is ruthlessly opinionated.
This means the waterfall model has no application. It also means that mocks are an insufficient blueprint to establish consensus in software teams. Mocks of data products are a specification of the application without it’s essential character: the true value of the information being presented. Mocks as blueprints make assumptions about complex data models they have no reasonable basis for. When specifying lists of recommendations, mocks often mislead. When mocks specify full-blown interactions, they do more than that. They suppress reality and promote assumption.
And yet we know that good design and user experience are about minimizing assumption. What are we to do?
The Mission
The goal of agile product development is to identify the essential character of an application and to build that first, before continuing to add features. This imparts agility to the project, making it more likely to satisfy its real, essential requirements as they evolve. In data products, that essential character will surprise you. If it doesn’t, you are either doing it wrong, or your data isn’t very interesting. Information has context, and when that context is interactive, insight is not predictable. Building agile data products means staging an environment where reproducible insights occur, are reinforced, and are extended up the value stack.
That value stack (as outlined by @petewarden) looks like this:
Skipping steps undermines your ability to proceed further. That makes step one of building data products an interactive prototype highlighting the most interesting things you know about the data you are mining. This prototype must be iteratively improved until it is ready to ship. That means you must select tools and platforms that facilitate such development. It means that mocks serve as broad concept for ideas around presentation, as strategies for presenting the data, and not as blueprints. A mock applied as a wrapper around your data in the form of a minimum interesting product is a starting blueprint for what the application will eventually become when you launch it after many iterations - a minimum viable product. Such a ‘prototype’ with unrefined data is a thing around which consensus can be built, as all stakeholders experience the same reality. It is easy to misinterpret mocks. Less so, working software. Frequent releases used by real end users maintain this consensus. A working blueprint has been achieved, and the team can collaborate efficiently.
Conclusion
Between that first step and your grand vision, leveraging the diverse skills of a product team on a rich dataset imparts unparalleled freedom of creation. Interesting relationships can be discovered, new datasets introduced, trends highlighted, recommendations inferred and actions associated. With a skilled team, the right platform and a rich dataset, the hardest part of the process can be limiting the scope of incremental releases to essential changes that maximize learning.
Good data products are snowballs, rolling down the hill, gathering momentum. In the process of building, the character of your product will change. You can no more specify it up front than you can the diameter or density of a growing snowball from the top of a hill. Let the snowball roll and grow into what it wants to become, that thing that will most satisfy your users.
Start small. Ship a landing page today. Experiment in public. Get people signing up and clicking. Connect your users to the value of the information at your disposal and help them take actions that benefit them on that basis.
