Product Management 101

Bringing a new product or service to market is like raising a child. You can get all the advice in the world, and know all the theories and best practices beforehand but it's only going to get you so far. There's no unilateral, all-revealing formula for success. Perhaps more valuable is first-hand experience and battle scars about what works in certain circumstances and what doesn't. You might have a different perspective on these things - that's fine - but I thought it was time to jot down some lessons I've learnt, and some things I've picked up from others for future reference. Some people might call this advice common sense, others might term it user-driven development, some will classify it as user experience optimisation (UXO), yet others might call it product management. Whatever you want to call it, it makes sense.

You need your users! They are the only reason you built the application/service.
So don't treat them like garbage!
Your users are not technical experts.
So don't assume they are. Sure, there may be small percentage of experts in your userbase but target the majority before the minority.
Your users might not care to learn 5 different ways to do something in your app.
Don't put huge amounts of effort into the "expert mode".
Your users might have radically different opinions about the quality of the app than you do.
Swallow your pride/ego and listen to them! Find out what their pain points are and address them. You obviously can't please everyone, and you might not have the data you really need so some judgement comes into play here
Your users may not use your app as expected.
Observe their behaviour and adapt accordingly!
Your users may not be as motivated as you are to use the application.
So don't build a UI that gets in their way and forces them up a learning curve that they have no chance of getting an ROI on.
Your users may prioritise features radically different to what you expected.
The developers of GMail thought the delete button was unnecessary but their users didn't. The rationale the Google PMs used was sound - why do you need to delete when you have tons of free storage - but Google listened to their users and put the button back in because the users demanded it.
Your user may not be as passionate about your application as you are.
Sure, you can have an animated paperclip overlay coming to life and speaking to the user in any one of 5 different languages after they've caused a form validation error but does the user really need that, or is your dev/UX team just trying to get new technology XYZ onto their resume? The user just wants to get round the issue ASAP and get on with their activity. Keep "Microsoft clippy" and "Vista UAC" in mind when you do your Kano model.
Your users may not care to tell you what sucks about your application.
So take the issue into your own hands by doing anything and everything from "hallway usability tests", to organised user experiments. Waiting for people to come to you with negative feedback is just putting your head in the sand waiting to be hit by a runaway hummer. Hint: waiting to do usability test until the product is finally built is a certain route to wasted cycles.
Intuition is regularly wrong. Let data drive decisions.