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

170) Build a product that does not allow users to explore broad or deep without administrator privilege and find users dissatisfied.
171) Build a product that does not allow authoring policies and find that the usage of the product is almost a chaos.
172) Build a product that does not allow differentiation to users either with policies authored by the administrator or out of the box and find that 10% of the users may matter more than the remaining 90%.
173) Build a product that does not let frequent users form their own customizations or dashboards and find that the product is pushed behind those that can.
174) Build a product that does not allow hands off operations with alerts and notifications and find that the product is not up for renewal.
175) Build a product that does not show captivating charts and graphs and the users migrate to applications that do.
176) Build a product that does not allow users to track their activities especially on shared resources and have the administrator be flooded with calls for lost or missing resources.
177) Build a product that does not allow operations to be distributed and have the planners complain about capabilities.
178) Build a product that does not protect data at rest or in transit and have all the watchdogs show up at the door.
179) Build a product that fails to meet the industry compliance and government regulations and find that the product cannot be sold in certain regions.
180) Build a product that tries to be ahead of the game in emerging trends and find that a significant legacy from partners still requires older technology integration.
181) Build a product that tries to squeeze different channels into the same stream
182) Build a product that tries to distribute a stream to separate channels when the user is expecting one
183) Build a product that tries to promote a partner application from the same maker to the deteriment of competitors
184) Build a product that tries to emulate open source and invite the world to build with it duing its early stages only to find it shutting doors in its growth stage with bars for acceptance
185) Build a product that does not choose partners to foster growth and find that it cannot sustain innovation by itself
186) Build a product that gives users a tonne of information to go through when they want a summary
187) Build a product to implement a use case and leave it for solution integrators to find bugs
188) Build a product to satisfy some customers only to irk others
189) Build a product with over generalization when some customization would have served neatly
190) Build a product with ambitious charter and find the release timelines reducing the plan.