What I’ve Learned as a Data Science and Analytics Leader
With Data Expert, Joe Pope
Joe Pope has overseen analytics and business intelligence projects for Amazon and the NBA. He shares a candid perspective from his own experience.
How do you see AI evolving the roles of data scientists and analytics experts by 2027?
As of March 2026, every data professional is in some state of fear, if not sheer panic, of being replaced partially or fully by AI. This is not wholly unjustified, given recent waves of mass layoffs. However, I believe this panic to be temporary, as data teams are already seeing AI as a new tool to learn and master as a matter of doing business.
Data Analysis
In my readings and in my own tests, I have seen AI capable of “one-shot” completion of common data analysis tasks, with minimal use of skills or prompting. However, it would be incredibly short-sighted for a stakeholder to take these results and present them to internal leadership or external clients before extensive validation.
We still need data professionals to carefully craft the prompts and choose the right skills or tools for any serious analysis. We will need custom-crafted guardrails, tests, and validations. We need ground-truth datasets created, ad hoc queries reviewed, and Excel files produced, by hand, to ensure that the AI is doing what we think it should be doing.
This means more work on the front- and back-end of an insight’s development timeline. Ultimately, this will save time and effort when building any scaled insight, particularly those designed to be run multiple times on some regular cadence.
Data Science
I see tremendous value to data scientists, who can use AI to test various methods, models, and approaches to solve a specific business problem quicker. This type of work is useful for “enhanced prototyping,” and could result in better, more accurate models than what a data scientist might otherwise come up with themselves.
Consider a classification problem, in which the Python scikit-learn library alone offers over 20 models (logistic regression, knn, SVMs, decision trees, neural nets, etc). For those unfamiliar with Python, this library fuses machine learning into Python with just a couple of lines of code. AI can help the data scientists break out of what they have previously used and are comfortable with and pinpoint the best model and solution for the problem. AI can easily build out a boilerplate starting point in data science tools like Jupyter Notebooks as well.
SUBSCRIBE TO OUR FREE MONTHLY NEWSLETTER
Data Ops and Data Oops
Again, more emphasis needs to be placed on the AI/Machine Learning Ops work to ensure steps aren’t skipped, data leakage isn’t occurring, and other gremlins are avoided.
I have seen a few “SQL bots” (bots that build queries based on natural language prompts) in production, and I am skeptical of any use case where the user inputs natural language and a fully-formed and accurate query table pops out. These SQL bots are great for demonstrating first principles, or showcasing one step of solving a larger problem. They can give you a general query that can “find users that abandoned a shopping cart on a retail site,” but will struggle in your production database when you tell it to “find users who were actively browsing on our retail site in the last 2 years, and have previously purchased from BrandX, and abandoned a shopping cart.”
A major reason is that your mileage will vary greatly based on how clear and logical your data and schema are built and documented. Since messy data seems to be the norm and not the exception, it is safe to say that most data teams will struggle with this. This also suggests an opportunity in the market for analytical engineering and data modelers to add immediate value. Clean, well built schemas with proper governance and documentation are an accelerant for serious AI data work.
What’s a valuable lesson you learned from a project failure that still influences your best practices today?
I have successfully completed dozens, if not hundreds, of reports, dashboards, KPIs, spreadsheets, machine learning models, and other data products over the years. I can barely remember what I did or what worked well on most of them. On the other hand, the projects that I failed to complete or that went sideways I do recall quite clearly. Here are a few lessons that still haunt me:
QA Your Work
If possible, have another human review (what we formally call “peer review”) what you did and what you produced. If that isn’t possible because of deadlines or resource constraints, give yourself a business day, or at least an hour break, and then review your results again with fresh eyes.
If you really want input from your team, have a brainstorming session and do all discussion upfront during your design phase. Any other great ideas after that should be added to the roadmap after you launch v1.0.
Ask for Help, But Do It the Right Way
I once built a lookalike model while at Amazon and would chat about it to other data scientists on my team over lunch. I talked to one person, who had a great suggestion to improve my model. Hurray! The next day, someone else had a great suggestion on how to handle outliers. Hurray! After the third colleague mentioned yet another improvement I realized that if I just went around and talked to every co-worker, they would all give me some small suggestion and I would never stop developing this thing.
While it’s great to work with smart people who have great ideas, the reality is that my model did not really need all of this incremental improvement. You will hit a point diminishing returns fairly quickly. If you really want input from your team, have a brainstorming session and do all discussion upfront during your design phase. Any other great ideas after that should be added to the roadmap after you launch v1.0.
Don’t Make Assumptions During the Design or Planning Phase
I had a failed project that took up way too many months of my time at Amazon. I had made some assumptions on what data would be accessible in the backend of a new platform that had been launched when building my own roadmap. As it turns out, the data I needed was not accessible when I needed it, and the partner team that could unblock me was now starved of resources. I would not be getting my data anytime soon. This was a rude wake-up call, and I realized that I should have confirmed what data I could access before I did any development work at all. My assumptions caused me to greatly scale back the output of this project, and I had to build cumbersome workarounds instead.
Slower Is Faster
In general, I have found that I bump into more issues and headaches when I try to complete a project as quickly as possible. When I rely on tried and true frameworks like using a Data Science Lifecycle or CRISP-PM approach and when I move slowly but steadily, the projects are done correctly, with only minor improvements needed after end user feedback has been received. When I try to gogogo designdeveloplaunch as fast as possible, steps are skipped, quality is sacrificed, and more iterations are needed to ship something usable.
Always Communicate Progress
I have never had a stakeholder tell me I am providing too many updates on a data product they desperately need. Alternatively, I have received negative feedback that I did not communicate enough, even on weeks when nothing was happening or I was waiting (or still waiting) for another team to unblock my work. You should always set up regular meetings with your stakeholders and tell them what is happening, even if it is nothing at all. Be sure to align with your stakeholder on what communication cadence they prefer, so you can properly manage expectations.
Sales and Account teams know their customers. That is their job. When you understand that customer better too, you will likewise serve your stakeholders better too. This helps make sure everyone is “rowing the boat in the same direction.”
How do you foster collaboration between technical data teams and non-technical stakeholders like sales or creative leads?
At Amazon Advertising I directly supported non-technical teams in Sales, Account Management, and Marketing. In most cases, your partner teammates are telling you some distilled version of a request they received from the client. Therefore, wherever possible or practical, get yourself in front of the client. If you don’t have clients, then get in front of an end-user. Whoever is directly ingesting or using your data, find them and talk to them. I would often learn more in casual conversation before or after a formal meeting than I would in the meeting itself.
I recognize that some organizations have a culture with strong silos erected, and it’s not always so easy to go against the grain. You may need to have your manager work this out with another manager, but you don’t need to attend every single meeting with a client either. Find some regular cadence (monthly, quarterly, etc) so you can be in direct conversation with the consumers of your data.
All of this will make you better at your job of providing actionable insights. The natural byproduct is that you will ultimately improve collaboration with non-technical stakeholders, partly from “being in the trenches” with them, and establishing camaraderie, but also from closing a gap you have with them. Sales and Account teams know their customers. That is their job. When you understand that customer better too, you will likewise serve your stakeholders better too. This helps make sure everyone is “rowing the boat in the same direction.”
I am bullish that AI will help on this front too. Power users of advanced AI tools can spin up prototypes or mock-ups live in front of their non-technical partners. This can lead to innovation as tech and non-tech start riffing on ideas and features to best serve their end users.
Share this on:
About Joe Pope
Joe Pope is based in New York City and has spent the last ten years building data products and scaling insights at organizations like Amazon Advertising, the NBA, and Success Academy. Joe is learning in real-time how AI can fit into a data team’s day-to-day workflow.