This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice :

205) Build a product with rich mobile enhanced experience across a variety of devices and find that the customers are able to use the product even before going to sleep
206) Build a product with mobile integration of payment methods such as personal wallet and the chore of paying becomes smooth.
207) Build a product that can use digital cards and refill them at will and the product becomes usable at all participating stores increasing adoption via partner networks
208) Build a product with partner sponsored incentives to customers and see the appeal grow as partner network endears itself to the customer more than it would have individually
209) Build a product with little or no ecosystem and the product fails to strike popularity in conferences, exhibitions and symposiums
210) Build a product with little user education and find that the sales booths at an exhibition are not visited.
211) Build a product with very little wording on consequences and see the amazement when users click a button.
212) Build a product that does not warn on consequences and find that the user has just deleted his data.
213) Build a product that does not take any notes the user wants to leave and find that the user does not remember why he took some actions
214) Build a product that does lets users erase their activities and find no record to come to their aid
215) Build a product that works with some users and not with others and find that they have to scratch their heads to find out why.
216) Build a product that has intermittent outages which it hides from the user
217) Build a product that has little or no documentation on escalation policy and find that genuine problems can be described well but not brought up for mitigation.
218) Build a product that tries to tackle the hard 10% scientific problems at the cost of 90% commercial problems.
219) Build a product that mitigates troubleshooting via published documents and find that the support team is building supportability features rather than support case handling
220) Build a product that specializes monitoring and alerting features and find that customers are not utilizing because they cannot plug it into their existing infrastructure.
221) Build a product where the features are built independently but find that the customer has turned on all of them
222) Build a product as a culmination of development efforts but find a mismatch between customer expectations and delivery
223) Build a product with internal vetting and sometimes friction and find the customer advocacy voice waning.
224) Build a product with the notion of getting a feature into the hands of customer without being explained fully why the customers want it
225) Build a product as a part of a portfolio and find that the entire value proposition of the product subdued by the portfolio perception.