Amer's Blog

Product development (and by consequence any software-centered development) is a tricky process, in which you always need to make sure that you’re not only adding complexity but you also can control it.  When it comes to complexity controlling, we should focus primarily on 3 pillars: Scope of change Change cost Escape options Scope of change When we think about a new feature, or a new data stream that will be added to the product scope, we should take the time to think about the scope of change. Which parts of the product will be affected by that change? It doesn’t hurt to think a little bit on the negative side: What could be broke down by such a change? How this new complexity is going to be integrated? Thinking about such aspects might give you at least high-level perspective on the affected areas, and thus you can pay more attention to those areas to make sure the complexity is still maintained and under control. Change Cost Think about that like you’re going to be wrong, even i...

Data is crucial for any product development process that aim to be customer-centric and human-first data-driven process. Product managers and teams aim to acquire as much data as they can get to learn more about their customers behavior and hence improve the product key outcomes.  When it comes to data, many product teams struggle figuring out the best approach to be data-driven, and to best use their data pipelines and digital footprints. However, being data-driven isn't a simple thing, and require much effort from the team to understand where and how they can structure this data flow.   But, can data-driven be misleading sometimes? In this short article, I'm going to unleash 1 aspect that can be misleading sometimes for any product team and that can lead to false conclusions about product situation. Being falsely data-driven is more dangerous than being non data-driven at all! Vanity metrics as an example Every metric we choose to act upon can be a vanity metric, a term...