I like the answer that's here, but had a different perspective.
In user17580's answer, there's things that I think are really good and what I would call "search engine relevant":
what languages did you use or have to learn? In fact, a way to dodge the "I had to write some X, but I couldn't develop in X day in and day out" is to talk about what languages the product used, without necessarily highlighting them on your skills list.
what programming elements, development tools or complex pieces of infrastructure did you have to know?
what processes or best practices did you have to learn to be successful - agile? waterfall? test driven design? Did you pioneer any?
- to some extent, the development process defines some of your deliverables. For example, if you are working in agile, you may be defining stories, or use cases, or epics, but you are likely NOT writing a requirements spec. If you do waterfall, you are likely to have a huge paperweight of a document for your requirements, and you would know if you had contributed to it.
Then there's some quick ways to describe the project itself:
- Release cycle - how many per year?
- Code size - big, medium, small?
- User base - how many? open source? paid service? product with licensing? Some businesses have a defacto model - for example, most social networking is free for the user base.
- Where is it in it's lifecycle? Prototype, Beta, mature (multiple versions), legacy? Also - what about your feature - did you prototype it or are you supporting an existing user base?
Then there's team stuff, how you communicate and what your role is within the team, the company and outside of the company is useful resume content - sometimes. For example:
- within the team - what was your scope of responsibility? Was there anything that you were the primary owner of? It doesn't have to be a product or a feature, it may be that you wrote and owned the build script, or the automated test harness.
- within the company - were you the delegate for anything? Did you have accountability and ownership for it? Going to a meeting of interested people is not a resume item, but being the guy they send to resolve test issues across a multi-team working group may be worth mentioning - particularly if your effort improved things.
- outside the company - did you have any customer consulting or support responsibility? It takes strong people skills to be able to communicate to external parties, so if you had to resolve customer support tickets or you consult on proposals with customers for new work - these are useful points to highlight.
- Particular actions - presentations, paper writing, leading a discussion - places where you take the initiative beyond your daily responsibilities is a worthwhile thing to highlight. Note that you probably don't want to highlight work that you do as a normal part of a process that is more or less standard - for example, at the of an agile sprint, it's common to give a demo. I would not put "regularly demo'ed features at spring reviews", but if you have the same demo with a bit more polish to customers as part of a sales pitch, I might say "demonstrated the product as part of our sales process".
Ownership, accountability and productivity
First, I'd say that the focus should be places where you've taken ownership, been accountable and been productive. Note, productive does not equal successful. A great engineering product may fail it the business due to a misunderstanding of the market - that doesn't mean that the engineer did a bad job. However, being the owner of a feature and delivering many weeks late on a 2 week project, is probably NOT the feature you wanted to highlight, unless you can tell this story as a success.
The goal with this is to create enough useful information about your job that the interviewer can have a meaningful conversation with you. "Ah, I see you took responsibility for 3 major features this year, talk to me about the one you found most challenging...". "Oh, I see you were part of a team that embraced agile - what do you think of it? what would you change about the team's process?"
So the big bottom line - don't write about things you don't want to talk about.
NOTE: A huge failure isn't a taboo subject - I have often gotten jobs with enthusiastic discussions of the things I've learned from my mistakes, and tales of how we recovered or succeeded anyway. A good story has to have a good challenge in it. :)
1 Year is 1 Year
Realize that there is only so much you can do in a year. I suspect you can get more than 1 sentence out of the experience, even if it's 1 sentence for the product, one for the role within the team, and one for it's business value - you've got three sentences and that's not so bad. In a year, I really don't expect that someone will have hung the moon, so don't try to get too wordy. Succinct is good.