Getting feedback on data science projects

Share this article

Are you wondering who to ask for feedback on your data science projects? Or maybe you are more interested in hearing about different methods you can use to solicit feedback? Well either way, you are in the right place! In this article we discuss everything you need to know about gathering feedback on data science projects.

First we talk about what stakeholders you should request feedback from when you are working on data science projects. This includes a discussion of which topics you should discuss with each stakeholder group. After that we talk about methods you can use to solicit feedback on your projects. Finally we discuss milestones in the project lifecycle where you should solicit feedback on your work.

Who to ask for feedback on data science projects?

What groups of stakeholders should you consider when you are looking for feedback on a data science project? Here are the main groups you should consult when you are looking for feedback on a data science project. We will provide more information on what topics you should cover with each group in the following section

Your data team
Business stakeholders
Leadership
Software engineers
Data engineers or data platform engineers
Other data teams

Your data team

Who is in this group? Data professionals who are on your direct or indirect team.
When to consult with this group? Every project
What to discuss with this group? This group should be reviewing your code and documents to check for technical accuracy, adherence to best practices, and adherence to company conventions. This is also a great group to reach out to if you are creating a presentation or document for a broader group and you want a second pair of eyes to make sure everything makes sense.

Business stakeholders

Who is in this group? Business stakeholders who will be utilizing the output of the project or who have important domain knowledge about the area you are working in.
When to consult with this group? Every project
What to discuss with this group? This group should be consulted to ensure that you are aligned on the problem that needs to be solved, the constraints that the solution needs to meet, and the way that the solution will be used. This group can also answer any questions you have about the application area to ensure that you have enough domain knowledge to create an effective solution.

Leadership

Who is in this group? The leadership team that oversees the area where the results of the project will be used. In a smaller company, this might be the leadership team for the broader company. In a larger company, this might be the leadership team for a certain department or business unit.
When to consult with this group? Every project
What to discuss with this group? This group should be consulted to ensure that the project aligns with company strategy and priorities. This review might happen as part of a larger roadmap review with a department or business unit.

Software engineers

Who is in this group? Software engineers who build core products for the company.
When to consult with this group? When you are working on data products that will integrate directly with their products. For example, if you are creating an API to surface the results of a machine learning model within an engineering-owned product.
What to discuss with this group? This group should be consulted to ensure that all parties are aligned on the interface between the data product you will be producing and the engineering-owned product it will be interfacing with. You should also discuss whether there are any additional constraints that your solution has to adhere to.

Data engineers or data platform engineers

Who is in this group? Software engineers or data professionals who build platforms and tooling that support other data professionals.
When to consult with this group? When there are special requirements that need to be supported for a project. For example, if you are going to beta test a new feature on the data platform or if there are concerns about a particularly resource intensive job.
What to discuss with this group? This group should be consulted to determine the technical feasibility of the solution you plan on implementing.

Other data teams

Who is in this group? Data professionals who are not in your direct or indirect team.
When to consult with this group? When there are dependencies between your projects, when they may be able to utilize a data product you are building, and when they have worked on similar projects before.
What to discuss with this group? If there are dependencies between projects that are being worked on by different teams, the teams involved should give each other feedback to ensure that timelines and priorities are aligned. If a team has interest in using the output of your project, that team should be consulted to understand the problem they need a solution for and the constraints they are bound to. If you are consulting with a team who has worked on a similar project before, you should discuss any setbacks they encountered and any advice they may have.

How to get feedback on data science projects

How should you solicit feedback on your data science projects? Here are a few different methods you can use to solicit feedback on data science projects.

Roadmap documents. Creating a roadmap document is a great way to get feedback on whether you are working on the right projects and solving the right problems. This type of document typically contains an overview of the projects that you plan on working on along with a very rough estimate of the timeframe where you will work on them. The grain of your roadmap document will vary from team to team. For teams that work on shorter term projects, a roadmap document might contain information on multiple different projects. If your team works on more complex and longer term projects, then you might have a single roadmap document that lays out the timeline for different components of a larger project.
Project proposal documents. Project proposal documents are great for making sure everyone is aligned on what problem is going to be solved and what the constraints of the solution are. These documents might contain information like the intended outcomes of the project, what is (and is not) included in the scope of the project, and what business metrics the project aims to improve. This document should be written before work is started on the project, so it does not need to contain technical details on how the project will be implemented. That being said, it may contain information on technical constraints that need to be considered when developing a solution.
System design or technical design documents. The technical design document is a more appropriate place for technical details on how the project will be implemented. This document should be created after you have started to do some exploration around how the solution will be implemented. This document should include a high level overview of the technical implementation of the project and the tools that will be utilized. It should explain the main decision point that came up when working through the technical design, the tradeoffs that needed to be considered, and the choices that were ultimately made.
Asynchronous status updates. It is also useful to have a document or documentation system that can be used to provide asynchronous updates on the status of a project. Even if you are having regular check-in meetings to provide status updates, it is useful to have written updates that others can refer back to.
Code review and pair programming sessions. Code review and pair programming sessions can be used to provide technical feedback on the code that has been written and any products that have been built.
Meetings. Finally, you can schedule meetings to ask for feedback on different aspects of your projects. We recommend relying primarily on documents and asynchronous updates when possible and reserving meetings for situations where more complex decisions need to be made.

When to get feedback on data science projects

When should you get feedback on your data science projects? Here are some recommendations for when you should seek feedback on data science projects.

Milestones where you should seek feedback

There are a few major milestones in the project lifecycle where you should seek feedback from your stakeholders. Here are some examples of such milestones.

When prioritizing projects. The first milestone where you should seek feedback on a data science project is when you are prioritizing projects against one another and building out your roadmap. At this point, you should consult with leadership and your business stakeholders to understand which projects are most important to the business. It may be useful to create a formal roadmap document where you lay out the proposed projects that the team will work on.
When scoping projects. The next milestone where you should seek feedback on a data science project is when you are defining the scope of the work that will be completed. At this point, it is important to clarify exactly what that problem you are going to solve is and what constraints you will be working within. We recommend writing a proposal document for your project and getting feedback on the proposal from business stakeholders. This is also a good time to check in with technical counterparts across data science, data engineering, and software engineering teams to discuss feasibility and additional requirements.
Once you have determined how the project will be implemented. The next milestone where you should seek feedback on your project is after you build out a simple proof of concept or conduct any exploration you need to do in order to understand how you will implement your project. This is a great time to get feedback from both technical and non-technical stakeholders on the current solution you have chosen and whether it is appropriate for the problem. This is a great time to create a technical design document for the full system you intend to build out to get feedback on for project stakeholders.

Regular check-ins and ongoing feedback

In addition to seeking feedback at defined milestones, you should also have regular check-ins or status updates throughout the lifecycle of your project. Priorities can change quickly, so it is important to keep a line of communication open with your stakeholders.

You should have regular check-ins with your business stakeholders to ensure that priorities have not changed and the solution you are working on will continue to be useful. These regular check-ins can happen through meetings or through offline updates that are published to a document or documentation system.

You should also have regular code reviews and check ins with technical stakeholders to get feedback on the technical aspects of your project. Our recommendation here is to start out with offline code and document review. If there are questions that need to be addressed or discussions that need to be had after an asynchronous review, then you can schedule a meeting to cover those topics.

Check out our article on data science best practices for all of our best recommendations on how to increase the efficacy of data science teams.