What's a good product requirements template for a web 2.0 startup? I get asked this question a lot, so here's my attempt at an answer.
I've done product management for over 10 years for small and big companies, and what I consider to be a good way to outline product requirements has evolved a lot over the years.
Back in my early Yahoo! days, product requirements (PRDs) were long and detailed docs that we handed off to engineering in a traditional Waterfall manner. Then came Scrum and we traded the PRDs for long spreadsheets (Backlogs). That was faster but lacked a bit of color. Another approach was during my time at eGroups, where I was just sitting down with my rockstar engineer du jour, telling him what I needed, he'd code and add his own magic, I'd try it, give feedback, and we'd build a great product that way. That was nice but it stops working the minute your team is bigger than 5 people.
So here's something that works well in a rapid and iterative development process, with overall product/dev teams of about 5-20 people. If you are in a big company, your team may be much bigger, but chances are the actual team working on the part of the product you're in charge of is not that big.
BACKGROUND AND GOALS
Keep this section short but powerful (a few sentences max). This is to help everyone understand why you're building this product. E.g. what's the user need and/or problem to solve, how you plan to solve it. Use data if you have it - data is good! If people can't be convinced after reading this section then maybe you shouldn't build product.
Who is this for: even if the product or feature is for all your users, give a sense of which segment is more likely to use it. This will help you prioritize as the team gets into coding and will help with design choices.
Outline the main ways users are going to use the product, in a story telling style. E.g. "Erika wants to share a picture of her trip. She grabs her phone, snaps a picture, starts [your product], chooses who to share with and that's it, her picture is now shared".
You don't have to use actual names if you don't like it, but it's powerful to force yourself to tell a story that way. If your story gets too long, your product is too complicated.
FUNCTIONAL/USER EXPERIENCE REQUIREMENTS
This is the meat of your doc. The best way to get there is to have a meeting (or series of meetings) with the key stakeholders, i.e. you (the product manager), your engineering lead and design lead. You may add other folks depending on the product you're building, but don't add the whole company or else it won't be productive.
In those meetings, you'll explain what the user needs are, and give a first pass of how you envision addressing that need, and get everyone to participate and add their share. It's important to work on the end-to-end flow rather than on a particular web page alone. Remember, your goal as a product manager isn't to build web or app pages, it's to build an experience that rocks.
What worked well for me so far is to draw the flow on a big white board. I like to draw very rough wireframes of each page or step the user would go through, even if the product doesn't end up exactly that way. E.g. you may draw a page for registration and a page for the error message, just to insist that there must be a helfpul error message at that stage, but your designer will very likely decide that the error message should be on the same page as the registration fields.
As you draw each page of the flow, everyone pitches in with their feedback, you make modifications on the fly, annotate each step of the flow with special cases or comments. Before you know it, your product takes life and all you need to do is take a few pictures of the whiteboard and stick them into your requirements documents.
If you have time, you can use simple wireframing tools like Balsamiq to turn the whiteboard images into early wireframes.
The key in this section is to go with as much visuals as possible. Reserve the text for what can't be explained via the images (e.g. " the default setting is Off", or "In a specific important corner case, the product will behave that way"). If this feels too wild, you can always summarize the requirements implied in the wireframes using text, but stick to bullet points and try for no more than one line per bullet.
SUCCESS METRICS AND DATA INSTRUMENTATION
How will you know that the product is successful? It's important to force yourself to have a numeric target, even if it's just some back of the envelope math. Your engineers need to know what you'll want to track ahead of time so they can instrument the product accordingly.
For example, your success metric may be to increase engagement by 10%. To measure this, you will need to track things such as time spend on a specific page, number of [specific action] per user etc.
What's the one thing in the whole product that will make your users go "wow, I love this". You may not be able to answer this with a "feature" when you write the requirements, because often the wow factor comes from excellence in the execution. So here you just aim at pointing out which area needs to be perfected, e.g. "It should be dead easy to create a professional-looking post with 10 photos".