Data products (digital tools fueled by data) are powerful assets for any organization. They're also highly complex: in addition to the infrastructure underlying any digital product, they rely on data (obviously), which means the teams that build them need not just developers and designers but also data scientists.
Because data scientists’ work is in high demand, the standard mode for developing data products involves a handoff: the data scientist creates a model and passes it along to the developers and designers to build from.
But that’s actually not the most efficient way to build data products. In our experience, integrating a data scientist into the product development team throughout the process leads to better products that earn wider adoption and add more business value – and that get built faster.
Making the leap to integrating data scientists into product teams, though, can be challenging. It requires everyone to adjust their normal ways of working. But the outcomes are worth the effort. Here, we outline three key insights that can inspire organizations to embrace this change.
1. A fully integrated team increases speed to value
As the complexity of a project increases, so does the value of having an integrated team.
We’ve experienced the transformative power of integrating teams first hand: years ago, our design and engineering teams worked together in phases, where the design team would hand their work off to engineers, who would transform it into working code. And then there'd be some part-time back-and-forth as the groups worked out kinks.
When we shifted to an integrated-team approach, one of the big questions we had was about cost: how would we justify the cost of keeping the larger team on for the entirety of a project? Put differently, would there be value-adding work for every team member to do throughout the evolution of a project?
Briefly, we found the answer is yes: there is always valuable work to do. What's more, the integrated approach leads to less back-and-forth, which translates to a quicker arrival at a valuable end state.
The same holds true when you add data scientists to the mix.
In the context of creating data products, integrating data scientists into the product team means the team can deliver a product that meets user needs and earns user adoption faster than they’d otherwise be able to.
In other words: integrated product teams can more quickly build and launch solutions that generate new revenue or otherwise drive value for the company.
When data scientists are included throughout the process of data product development, they can see whether their models deliver answers that satisfy users – and tweak those models if not. (While designers adjust UX to manage expectations and devs update the backend so everything functions.)
Of course, integration isn’t as straightforward as that description makes it sound.
In the real world, everyone’s work happens at a different pace. Users offer feedback that designers can incorporate in almost real time. Things move more slowly on the dev side of things: engineers have to build and test code, then make sure it functions as expected. Model development can also be a lengthy process, as data scientists seek to validate their models. But working as a team can help everyone be more efficient.
For example, in a recent engagement, our data science partner was trying to combine a bunch of data we’d sent over from multiple sources. It wasn’t all in the right format or even in a single location. When we met for our regular check-in, they explained this to us and we realized we could be cleaning and formatting the data before we handed it off – in fact, we were able to automate that process. This saved the data scientist a significant amount of time and let the team as a whole iterate much faster.
Now we know to ask upfront about data formatting and delivery to streamline data projects from the get-go. This continual mutual learning helps us adapt as we build and work at the pace we need to for the job we’re doing.
2. A dedicated team performs best
On any given data product project, the biggest expense is usually engineering, which tends to be the team with the largest headcount. But we’ve found that the fastest way to tank a product team’s efficacy is to pull the data scientist onto another project midway through.
Again, this is counterintuitive: the common thinking goes that, once the data model is built, the data scientist’s contribution to a data product is mostly finished. In reality, the opposite is true.
Often, the data scientist who built the model underlying a data product is the best (or only) person equipped to recognize potential problems when testing begins. For example, they might realize, as real-world data starts rolling in during a beta test, that the team has been building with extra assumptions that haven’t been verbalized – and that could impact the functionality of the product.
Or they might support operations tasks, monitoring new data to make sure it doesn’t go in the wrong direction. While engineers are focused on whether the product functions and designers are focused on whether users are satisfied, data scientists can approach early tests with a data analysis mindset, looking for opportunity areas and potential problems.
To do this, of course, there has to be alignment on priorities. When data science leaders are doing capacity planning, they have to buy in to the integrated team model for building data products so that they allocate enough time for a data scientist to collaborate on developing the product through launch.
This often means investing more of a data scientist’s time into product development – but translates to more impactful products that launch sooner and drive value for the organization more quickly.
3. The integrated team model will feel uncomfortable at first
We’re big believers in fully integrated data product teams. But we would be! We’ve been working as fully integrated teams (sans data scientists) using Agile and design thinking principles for years, and we’re all familiar with the ways this approach saves us time when we’re building complex products.
Asking data scientists to weave their work into ours is, in some ways, a huge request.
For one thing, data scientists tend to work in really different ways. While devs and designers aim for tight feedback loops, creating the smallest possible thing and then building and building from there, data scientists’ work isn’t as clearly building block oriented. Product development tends to be extremely pragmatic and extremely user-focused. Data scientists may be more oriented toward long-term goals and unveiling new insights.
Asking data scientists to embrace the product development approach is asking them to work in a way that may make them uncomfortable. But simply acknowledging this reality is useful.
Understanding what data scientists need and how product teams can make their work easier (as in the data formatting example above) can help. For example, engineers can often speed up the feedback process for data scientists by helping them execute different experiments more quickly. Engineers may build tools to help data scientists get data in ways they need it or expedite processing. Or maybe engineers help their data science counterparts build things that test and automate more of their process.
Modeling the product innovation approach can also help: by showing that we can fail fast together and that the learnings we gather can be extremely valuable to our work, we can make the case for this way of working.
An integrated approach helps usher in new value from data products
For many organizations, data is among their most valuable assets. Figuring out how to tap into that data to create new sources of value that drive new revenue streams can be a game changer.
In our experience, the surest path there involves taking a product innovation approach with a team that includes designers, engineers, product managers, and data scientists.
If you’re interested in how you might be able to leverage your organization’s data to power a net-new revenue stream, get in touch. We’d love to help you explore your options.
