A look at how data science is being integrated into product teams
The job of a product team is to provide value to customers quickly. What ultimately matters is determining what will provide the most value (referred to as "Discovery"), followed by having it built and shipped (called "Delivery"). Data science is used heavily on both sides of this equation.
Unless your product teams work with a skilled data partner, they may be vulnerable to a variety of pitfalls, from the mundane to the existential:
Making decisions based on incorrect (outdated, inaccurate, incomplete) data.
Taking a very challenging approach to answering a question that could be handled much more simply and elegantly.
Validating hypotheses by answering adjacent, incomplete, or fuzzy questions.
Making flawed/unprovable hypotheses in the first place.
Overlooking insights that could lead to new hypotheses.
Integrate the Project and Product cycles:
Let us now look at how product teams perform the Discovery and Delivery activities with the help of data partners.
It is driven by the feature. Every feature, whether shipped or not, will go through a more-or-less structured development process. The majority of the time, product teams spend here.
Team-driven. The project cycle is surrounded by the product cycle. It is ill-defined, poorly understood, and rarely formalized. Product teams, on the other hand, add the most value here.
Setting up your team for success: Three steps for the data science chief:
How would you describe your team? Creating a successful organizational chart:
Data partners should function similarly to design partners, reporting to the function and assessing their impact on product teams.
Data teams, like design teams, require peer criticism, but the best analysis, like the best design, is useless if no one uses it.
This sense of self reflects the level of successful collaboration and outcome ownership required for success.
Set product-oriented objectives:
Whatever success tracking system or goal system you choose to use to discuss career development within the data organization, make sure it is based on the product team's outputs rather than the outputs of the data partner in question.
Set your outcome goals and look for high-signal correlates in your partners' behavior that tend to lead to those outcomes.
Be aware of both long-term outcomes and short-term proxy behaviors in order to catch mistakes early while keeping your eyes on the prize.
Here are two case studies to watch out for:
The project & product cycles of their teams are not effectively synchronized.
Data in your organization is used to quell curiosity, not to drive decisions.
When you combine products and data, you attempt to influence culture. People must alter their thinking about transforming ideas into features, as well as how they evaluate decisions and strive for success.
Once you understand how change occurs in your organization, try to implement it through the same channels, steer it toward the typical catalysts, and avoid the typical impediments.