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...

Building digital products is a very challenging practice, since it's built on circles of thoughts among: managers, marketers, and engineers. It becomes even more challenging when we need to validate and test our ideas and concepts through out the whole development cycle. Testing and validation isn't necessarily restricted to the technical testing (i.e. writing test cases and run them against the product functionalities), it can be also extended to the scope of validating and testing the ideas even earlier in the cycle. Before any development has taken place. In this article I'm trying to explain more how can we pave the product environment to be more testing-friendly environment across the different stages of product development. What’s the point of measuring stuff we build?  As humans, we tend to measure things around us in order to understand them better. For example: You're always measuring how fast you can get to work on foot vs. by train so that you can ...

Sometimes we hear about Agile in the software industry, which might sound cool from the first glance. Agile encourages the practices that makes the process of crafting software more humanized. But, at the end of the day, the software is built around code, and code is being built by programmers. So, when you think more, what does it mean to Agilize the software building processes (i.e. writing the code base, maintaining it, testing it) you might wonder, how can people do this on a day-to-day basis? If you wondered before, let me please introduce you to Extreme Programming! How XP differs from Scrum? Scrum is a very popular Agile product management framework, that’s more interested in the processes around the software, how people interact and collaborate to get things done. While it’s very focused around software, it doesn’t provide a prescription of writing the code itself, which is the building blocks of the whole thing. XP on the other hand, is a framework that’s more interest...

Digital products are floating around, everywhere, no wonder with all these products out there, there should be a lot of waste. The problem is not that we’re going to have some waste, the problem is how much is that waste out of the whole thing? Most of the products need to solve real painful issues in order for them to succeed and flourish. But more often, the products got stuck in something called ‘Death Cycle’ which was illustrated by David Bland in 2014. So what’s that death cycle? And how can we avoid it? This is what I’m going to tackle in the following lines. What is product death cycle? The product death cycle is a phenomenon happens when no one uses the product and we don’t know why. And based on that we start to take action, but rather than solving the issue, we produce more software that no one uses as well! The 3 corners of the death cycle Customers who don’t use the product . Because they don’t like it, or because they don’t find it really useful. Prod...

Digital products usually hit this plateau phase, where we don't know what to release next? Most business usually have their core features, which they use to drive most of the business revenue, but in order to stay in shape, you need to challenge your processes and learn from them. In the following lines, I'm talking more about 'Learning' activity in an Agile environment, and how to evaluate this core activity?  Learning as a job in software development Software is a set of complex and creative processes that being maintained by creative human individuals. That being said, the process of creating new software is extremely tricky when it comes to predicting the market needs, or in a more Agile terms, what users are after in order to use your software product. To predict, you need knowledge. In order to be knowledgeable, you need to understand your users, hence, you need to learn about them. Your ability to lean specifies to what degree you’ll hit your target. Lea...

Agile & Lean Startup: What was the problem with Agile? Agile was a reaction to the fact that we couldn’t produce software effectively and efficiently. The industry had some hard time addressing the problems with what we called “The waterfall process”. The problem was clearly that the process of building and producing software was difficult and tedious, and moreover, not successful. And how did we addressed it mainly in Agile? It was simple approach: Work iteratively. Shorten the feedback cycle. Evaluate and repeat.  And it was a success! Thanks to Agile, the software delivery process has been enhanced, more projects were able to deliver software to market successfully and in more disciplined way. So? We discovered later that even with successful delivery, more and more software aren’t being used as imagined. We produced and delivered a lot of software, but the users never used it as imagined -or never used it at all. That was a clear indication for people in...