Amer's Blog

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

While flying to Munich, watching a video about ‘Finding the right solutions as a product manager through Agile’, it came to my mind the number of different problems that we think we’re solving using Agile! Agile, the most popular software development management framework so far, which came to the scene as the glossary of some curious minds that experienced many problems with the traditional ‘Waterfall’ method. I just was wondering, why at the first place we had problems with the traditional model? And does Agile really solve those? I’ll try to answer both questions from a mixed people/business/process perspective. What problems we had before Agile? I’ll list major 3 problems as I see it: High cost of change.  No innovation-friendly environments.  Illusion of control.  Before we start, some hypotheses that we need to agree on: Software projects are a special type of projects that differs from other types of traditional projects (i.e. Constructions, ...

What are the Design Sprints? Design sprint is a way of mixing best practices from: Agile development, User Experience design, and Software development. They’re more or less a time-boxed sprints (like the normal scrum sprints 2:3 weeks on average) that focus on understating the clients within one perspective (that’s why it’s called a sprint: Focused, Fast, and Fruitful) and market needs in a way that can affect the software releases. They were invented basically on GV labs , to fit in an Agile environment, and to help guiding the team on their releases process. Why they were needed? Fast-based approach doesn’t mean randomly crafted software! Agile was massively consumed among the different types of teams in software industry, it could also influence other parts and industries to adapt some of the practices that makes Agile software development effective. But, having that said, it’s not only about delivering something every 2 weeks, it’s about what we’re going to deliver eve...