Feature Hoarding

One of my recent professional failures was a project I got assigned to. It was one year in the making without ever seeing the production light. When I saw the situation and the amount of assumptions that were made, I made my first priority to release and test it with users. Unfortunately this desire to wrap things up and release got resisted by the stakeholders, believing that all those missing features were necessary. One ops guy even said to me “it is just a few case statements”, not understanding the complexity of software and how the smallest changes can lead to big delays.

Shopify recently released a new version of their iPad POS software that was missing being able to connect to the credit card reader. When my business partner told me about it I said they told me about the new app last year, at some point you have to stop building and prepare for the release even if it is not fully ready. To their credit they made the upgrade optional and so you could stay on the old version until you feel confident to switch.

There is a tendency in many parts of the industry to not emphasize shipping the software but rather making sure that everything is figured out from the beginning. The truth of the matter is no one cares about your software. And the second truth is you will never figure it out. So ship the goddamn thing and get real user feedback instead of just hoarding features. Because hoarding is the illness that kills many bright ideas.

The PM’s Dilemma

A friend sent me this tweet recently and it hit hard

Since moving to Europe, I only experienced non-process oriented roles when I worked for Booking.com, and when I worked for Zalando reporting to Henning. Those were the most fulfilling experiences for me as a product manager. We were truly customer centric and doing whatever it takes to create great products. And we were seeing the results.

When I talk to friends I trust at other companies, they are suffering the same. Over time I am becoming skeptical of how the PM job is being portrayed vs how it actually is. You get interviewed for your ability to solve complex product problems and how they influence users yet – most of the time – you end up with a road map from the top and your job becomes constant negotiations with everyone to clear dependencies. I use the Arabic word مسلكاتى. I can’t find a descriptive enough word in English, if you have suggestions leave them in the comments.

Anyways, finding an empowered product team as Marty Cagan likes to call them is becoming really a challenge, and it is becoming one of the areas I hope to build a model for myself that allows me to find and be able to join them, until then I have to live with the PM dilemma of being the guy who clear out dependencies and establish processes المسلكاتى.

From Excellent to Terrible

I recently contacted GitHub customer support. For some reason on their rating form they ask you to rate the service from Excellent to Terrible and not the other way around as most services do. It is almost like asking to rate something from 5 to 1 instead of 1 to 5.

I wonder why they made this decision.

Kindle Reading Insights

I didn’t know there is a way inside the Kindle app to see insights about my reading habits. I never care to quantify my reading but I can imagine many who care about it.

I don’t know why I was reading a lot in November
No idea what I was reading in that period

Just do something on paint

A practice I noticed Amazon doing on few pages of the website is just using a dirty image to communicate something instead of doing proper HTML.

Since those are mostly internal pages for logged in users, I doubt they do this to avoid scraping or something. It looks to me they are just being frugal on resources and someone on the team would just open Microsoft paint and do something.

I like it. It is counterintuitive. And that’s why they are worth a trillion.

Inside the mind of a product manager: How as an engineer you can convince your product manager with your awesome ideas?

Everyone talks about thinking like an engineer but no one talks about thinking like a product manager. One common misconception developers think is that we just block their ideas. While there is an element of truth to product managers saying no a lot, maybe it would make sense to clarify why this happens and how can you get around it.

As with all humans, you should start by understanding product managers’ desires and incentives. Product managers are driven by building products used by the target users that lead to driving business results. The more the users and the bigger results, the more they are happy (As long as it is being perceived internally/externally as driven by the team with this PM). This leads to a certain way of thinking whenever PMs hear new ideas, regardless of where they are coming from.

The first thing that pops into a product manager’s brain when someone pitches an idea is who is this for? The reason to this is because if the idea targets a segment of users the product manager cares about, the more likely they would be open to listen more. To know where this segment lies in priority is more art than science. It requires a mix of asking the product manager who does she care about and the developer having some sense of which user segments are more important. Data is your friend. The bigger the segment, the better.

Then comes the problem. The reason product managers annoyingly ask what is the problem we are trying to solve (other than trying to appear smarter in meetings) is because by understanding the problem, the better they can assess whether it is worth solving. You should also be prepared to answer why is it a problem? Because many times it can be a problem just for you, or it can be not painful enough that it is worth solving. Sometimes the pain is obvious, other times you have to be persuasive enough to convince others. You can do this by looking into the data and showing how it leads to users churning because of the problem, you can demo how shitty it is to get something done, or you can use one of the customers to lobby for you. The bigger the pain, the better.

Ok, you have made it this far. There is a good user segment that has a pain that needs to be addressed, now let’s talk about your awesome idea. Many times developers think that the product manager should have a strong opinion about the best solution, and many times product managers think they should have a strong opinion as well. The truth of the matter is there are only three things that matter when discussing a solution: 1) Does it solve the problem? 2) Is it feasible? 3) When can it be achieved? If the answer to 1 and 2 is yes, and the answer to 3 is soon enough, then you are too close to getting your idea through.

Last but not least, what is the business result? You can sell a dollar ($1) for eighty five cents ($.85) and I guarantee you, you will have a big enough segment that strongly feels the pain of wanting more money, it would be feasible and within reasonable time to solve it by giving them $1 if they give you $.85, but the result is the company will go bankrupt. You don’t want this to happen and therefore you want to make sure that your awesome idea will deliver positive business results, even if you don’t care about business. The simple way to think of it is imagining writing a report to the big bosses after this is released, what would the PM wants to write there? Think of the company and team objectives and what needs to be achieved. The bigger the results, the better.

All of this you need to apply while being aware of the current priorities. At the end there is a finite time and infinite number of items the team has to work on, the stronger the arguments on each of the previously mentioned points, the higher it ranks in the list of priorities.

In a nutshell: Big pain, to big number of users, with a feasible solution, within reasonable duration, that leads to a business result, and you won the product manager’s heart.

Thanks to Muaaz Saleem and Vicky Gkouta for reviewing drafts of this

Product Monday: Projects Collaboration

A product work colleague asked how to measure collaboration in the context of a project. What do people mean when they say “Let’s decide how we will work together”?

As usual, I gave a lengthy answer as to what I think. Here I am open sourcing it.

I think there are two main elements to this statement “Let’s decide how we will work together” in the context of projects.

1- Communication: How frequent project members communicate and what are the ceremonies involved? Will there be a standup and planning? Will only heads/PMs sync up on certain things and everyone sync up on other things? The key is to find the balance between being informed vs distracted.

2- Decisions: How decisions are made? This is the more dangerous one that people try to hide under the rug. Most projects don’t go as planned and many times there are no clear decision makers or decision criteria. This is where conflicts arise and escalations happen. There is no single answer to what’s the right thing to do as it always depends on a big number of variables like the project, the teams, and the stakeholders. One thing that helps me always is to think ahead of problems and raise them earlier. It makes me sound pessimistic but it does no harm if I turn to be wrong. If I am right the project benefits and people would have less reaction to problems as they were already anticipated.

At the end collaboration for me is measured by how close are we getting towards the result. And I am using the word “result” because I sometimes feel people consider delivery as the goal. To me it is a mean to achieve a result. If we can achieve the result without having meetings or with having more meetings I am ok with it. If not then we are not collaborating well enough, and there is a problem.

Product Monday: Screenshots

I test many products and take screenshots all the time. This is helpful as it serves as a reference when you want to design something similar.

Timing is key. Some experiences like onboarding or messages only happen once. You need to screenshot before you react.

Here are some examples of screenshots I took recently.

YouTube has different pricing for premium depending on whether you buy the subscription from the web or the app.

During summer, Google changed the font, spacing, and animation of displaying the stops on Maps for iOS. What I felt would’ve been useful was making the S icon to the left move as your location changes to the next stop. This would have been better to tell me where I am.

LinkedIn has a well designed onboarding experience to its mentorship program.

YouTube tries to measure the effectiveness of its ads on your buying behavior. Here it is asking which toothpaste I bought recently. The one I checked is the one I saw an ad on YouTube.

WhatsApp asks you if you want to change your number once you insert a new sim card. I like the copy that explains everything will be migrated. Smooth.

Take screenshots. It is a good habit for free education.

Product Monday: The meetings music

Managing by influence is not easy. One way to ease your job is to be likable. It is an art more than science.

One small trick I learned from a fellow product manager was that he always played music at the beginning and end of team meetings. It was a nice gesture creating a friendly atmosphere. This was his track.


I don’t do it all the time, but if you do, be careful if you have overly serious attendees. They won’t like it and might have opposite effect.

What would be your track?