Data-Driven Retrospective for Your Data in 4 Steps
When focusing on consulting for small to medium size startups, you run into issues that big companies are not familiar with. Another scenario for big companies is that they are in full awareness of the situation but since it takes too much effort to modify the architecture or process, it’s being postponed over and over.
The relatively flexible approach of a startup enables you to investigate your flow and to find the gap between your current state and the wishful state. In this post, I will be focusing on data validation and the availability of the right data for the right team to optimize the answer to some important business questions. It can also be useful to reveal any hidden bug you may have in your flow.
Like products, processes also require an MVP, so please start small. Do it by choosing a specific area or a feature that is responsible for a reasonable amount of data you want to cover. Examples can vary from a problematic piece of code to a flow that is known to be having a low performance. Take the data it reproduces in a specific timeframe and try this exercise on it.
This is something I did as part of my last role and at the end of the mini-project, I presented my conclusions on a deck to both the CTO and the CEO.
1. Data mapping
Take an Excel or a Google Sheet file and map the data objects in your scope. Each line will represent an object containing a value, and each column represents its type/business value/state along the pipeline from the end-user(the initial collection of the value) to the dashboard(modified value is being read from the database).
Choose a legend of colors to resemble the functionality, purpose, input, or output of the data objects. Then, color each line respectively, to present a certain division.
2. Data visualization — current state
Using diagrams.net and driven by the colored sheet in step 1, draw a UML-like diagram, showing the breakdown of the values in the system architecture design. Meaning, if for example, different data fields are coming from different resources — you probably colored them differently in step 1. Then here, as part of our drawing, you will classify the objects of different purposes or in different steps of the pipeline.
3. Data visualization — future state
After examining the current state we will gather a focus group. It can be the Head of Product, the Squad responsible for this product, or any other group of smart and involved people to work together to come up with the wishful state and a plan to get there. It can be drawn on a whiteboard during the meeting sessions but eventually, you should put it on a clear diagram as well.
4. Defining the new flow and action items
Having a clear diagram of the final state allows us a visual representation of our goal. Now what is left is to make a list of action items, decide on their order, priority, and sensitivity, and assign it to the relevant executer.
In my case, a few weeks after it was completed(the full process, not the MVP), one of the major products dropped off the roadmap, and so my plan was no longer relevant. But, the mapping of all data fields available in the system came in very handy in a lot of decision making gatherings and when mentoring new employees. Just to emphasize how useful it is even if just for documentation and explanation.
This showcases that when working in a start-up, plans change, focus changes, and you should be dynamic and adapt to the change. But remember this- you definitely should look into the existing data and use it to plan your future. That way you will have a lot fewer surprises along the way.
