Engineering Data Products, Metrics and Algorithms Part 2

In our last post, we discussed getting a goal from high-level stakeholders and making sure it comes to you as a clear and concise statement or one pager.

This makes it easier for data engineers and product developers to see why they are creating what they are creating.
​
So in this step, we will be discussing the data source as well as starting our discussion on the value of designing prototypes. These topics are somewhat hinged on each other. The prototype can only represent metrics based on your data source.
​

​Prototyping

Design a prototype is a key step in developing any product. Now, in this case, I am referring to purely a design and not an MVP. The prototype doesn’t need to be at all functional. Instead, it is more of a tool used to sell to executives. This good is a fake report with somewhat accurate numbers, a set of slides that demonstrate how an application could work, etc. The point is to have something your audience can see and can visualize using. This will help you sell your final product, even before you have it. Oddly enough…this can be more valuable than your actual technical work because if you can’t sell an idea to your stakeholders, it won’t be picked up.

How much time you spend on developing your prototype can also depend on your company culture as well as what the companies focus is. If the company’s focus is to create analytics to sell to other companies, then they will spend a lot of time on prototyping (or at least, they should).

This is because they have to convince the company to continue paying for the product for years to come. Also, if your company is very rigorous when it comes to developing internal tools, then you again, might spend a lot of time designing and prototyping.

However, there are many companies that will draw up a dashboard on a whiteboard and call that the prototype. There is nothing wrong with that, but the final product might not have the same buy-in. This eventually leads to the final product being forgotten quickly. When the stakeholders are forced to be brought into parts of the process, and also forced to dedicate time to it(as long as the product has a clear impact) they will continue to use the tool after it is finished because they will feel more attached as well as understand the product better.

This isn’t a fact that I could quote, or provide research on, but I have at least seen it anecdotally to be true. When the end-users weren’t forced to put time into thinking about the product, they can easily dismiss it in the future. This, in turn, wastes the time of the engineers and the resources of the company.

Prototyping is a key step in the case. It helps crystallize what exactly the data engineers are trying to create and the impact it will have. In addition, it forces the stakeholders to own more than just the concept of the product.

The limitation of what the prototype can be when referring to data products and algorithms is the data source, which will talk about next.

Read The Rest Here

Are You Interested In Learning About Data Science Or Tech?
​
The Advantages Healthcare Providers Have In Healthcare Analytics
25 Of The Best Data Science Courses Online
Learning Data Science: Our Favorite Data Science Books
What Is Data Science Really As Told By An Ex-FAANG Data Scientist
How Algorithms Can Become Unethical and Biased
How To Load Multiple Files With SQL
How To Develop Robust Algorithms
Dynamically Bulk Inserting CSV Data Into A SQL Server
4 Must Have Skills For Data Scientists
SQL Best Practices — Designing An ETL Video