This is Ahmed Sulaiman's personal blog with notes and thoughts on design, engineering, and building products.
Closing Feedback Loops is the most important thing you can do to build relationships. Be it a customer, your team-member, or a friend. It's a basis for any communication, internal or external.
During the early days of the product, heavy reliance on analytics can bring more harm than benefits. Why would you use proxies instead of talking to people? I believe the answer is the wrong interpretation of analytics purpose.
Reaching a feature parity across platforms is often considered a positive thing. But when followed blindly, this option costs more for the company and the users. You got to analyze the unique business circumstances first.
Small day-to-day improvements are usually left unnoticed over Big Moments. But no Moment can happen without consistently putting in the work. Without recognizing those tiny iterations, we block ourselves from reaching the next Milestone to celebrate.
Where do you think technical debt comes from? Why random feature opportunities tend to overshadow long-term goals? For product teams the answer is delayed gratification. And the only way to fight it is to time travel.
Overcommunication is commonly used for sharing "important" internal updates. It sounds compiling because it feels safe. But in reality, this is a literal definition of spam. And what people usually do with spam? They ignore it.
Every redesign inevitably makes some people miserable. They didn't see it coming. Now they need to re-learn how to use your product again. We can do better.
Building in Public movement created an enormous pool of insights for the indie makers community. I have one problem with the term, though, that lies in its misleading name.
The majority of PMs believe that nobody reads Internal Release Notes. At the same time, the majority of PM maintain them and recommend to others as a solution for internal communication problems. Why is it?
Overview of how Passive Information Consumption approach to communication can increase the team's productivity and wellbeing.
Whenever you make the product "easier to use" for the customers, you make it harder to maintain for the engineering team. Easy-to-use products are expensive to make. It's important to be mindful of that and take only relevant complexity.
Extend the iOS Simulator by building a plugin for it. A dynamic loader and simctl allow injecting custom code into the Simulator. With that, you can modify its behavior.