There's a neat little formula for you... on the surface, it makes even less sense than a coach exhorting his players to give "110%." It's actually my compact way of expressing two of the lessons I've learned working directly with end-users to come up with a software design.

Offer 80%

80% solutions are solutions that fit Pareto's 80/20 rule. You only solve 80% of the problem, but you do it with just 20% of the effort. Now most customers would be pretty mad if you only gave them 80% of what you promised them. Especially if you followed up by telling them, "Well, it only cost me a fraction of what it would to do it all. Look how much money I made!" Suggesting 80% solutions is done during design, when the spec is still up in the air.

An early project I worked on was part of an in-house tracking system. Each record represented a real-world software product that we'd delivered to a customer. They wanted to present the user with a series of yes/no questions about how the product was configured and which parts of its functionality were actively being used. Now, these questions had logic dependencies; if you asked "Did you like ice cream?" and got a "No", you didn't need to ask "Which flavor?" They wanted to only ask meaningful questions.
Now, a simple, fixed list of questions would have been trivial: a single table in the database, bound to a control already provided by the application framework. I pointed out that this would be far less work than implementing to spec. We reviewed the design and decided that the user would be likely to make mistakes that would interfere with reporting (the primary business need of the project) so in this case we decided to implement the full solution as a custom control.

Even though they went with the full package, I would have been remiss if I hadn't pointed out that there was a cheap, easy alternative. Even slight deviations from the standard solution can set us up for large amounts of custom work. (Other 80% solutions were accepted and helped keep the project with the scope of an internal project.)

This is not compromise; we're providing value to the customer each time we point out an 80% solution. The customer is basically working in the dark; they have some vision of what the product should do and how much value it has, but no idea how much it costs. That means there will be plenty of these arbitrage opportunities to find.

Giving 110%

I also like 110% solutions — when you give the customer extra cool stuff for free.

On the same project, a user would first be presented with a list of records. They could select one and open another form to update all the fields of the record. However, some of these updates were far more common than others; in particular, updating the delivery status of the product is extremely common. So I gave the user a context menu so they could update the status by simply right clicking on a record in the list. (It was pronounced cool.)

No one had asked for this feature; it wasn't in the spec. But that's simply because they didn't think of it. Adding a right-click context menu is trivial, from the developer's perspective. 110% solutions are about giving the customer what they want, but don't know to ask for.

Optimize

Every design is a cost-benefit analysis on some level. Since we know the cost and they know the benefit, working together is essential. I think this makes it more fun — working with a good design is a lot more rewarding than conforming to an inflexible, arbitrary spec.

In fact, a system designer or architect turns a specification into a design in a similar way, as far as I can tell. The difference seems to be that the designer loads as much information as possible about the users requirements into one brain that then knows both the cost and the benefit. The design shouldn't even require conscious thought at that point; the designer will simply kick off subconscious threads that search the solution space for cost-benefit local maxima.

(At least, that's how I feel when designing systems where I understood both sides of the equations. All those little threads reporting back, providing surprisingly complete development paths in an instant. They must have been working on it in the background for a while. Your subjective experience may differ.)

Even if there's a good architect around, we can always add value by pointing out 80% or 110% solutions when we see them. Our knowledge is valuable — we should share it!