There are lots of different templates for writing a Product Brief or PRD (acronomicon: product requirements doc), and such docs can get quite lengthy, depending on what type of environment you work in, and if you're working in an enterprise company.
HOWEVER: When stakeholders look at your doc, they're probably (most likely) not going to read the whole thing, but rather they'll scan it to get a gist of the feature.
Most people looking at a product or feature brief are trying to answer one of these 5 questions.
1. What is the purpose of the product/ feature?
What's the point of this new feature, anyway? Think of this as the product or feature 'elevator speech.'
I often ask this question of other product managers, and I often get lengthy answers. SPOILER: Past two sentences, you've lost half of the people in the room.
- Be succinct! If the feature is valuable, you should (usually) be able to say what the purpose is within 2 sentences.
- Use real human language. Does your product brief sound like a PhD thesis? Your academic language isn't impressing anyone. Stakeholders want to get the gist, without a lot of fluff.
Business-y speak: The ParkWhiz app intends to use xyz trending technology to track the inventory of parking availability, and surfaces that availability to users, allowing users to find parking more efficiently in high-traffic areas. Via an advanced algorithm, ParkWhiz also prices parking spaces based on a patented supply and demand model, therefore saving users money much of the time by pre-selling parking spaces based on availability.
Layman's Terms: ParkWhiz helps commuters 1. save time looking for a parking space, and 2. gives users the lowest, real-time rate on parking spaces.
2 - What is the problem you are trying to solve, in real-world layman's terms?
You can answer this question with a storyboard, use cases, scenarios - or all three! Keep this as simple as possible; you'll have to supplement later with comprehensive UX flows.
Mary commutes from Boulder to Downtown Denver every day, and spends 20 minutes looking for a parking space every day. She doesn't know if a garage is full until she physically drives by each downtown garage in the morning.
3 - How will this feature solve the problem?
You've outlined the value of the product, and the problem(s) you're trying to solve... now how does this feature solve the problem?
Tip: This is somewhat similar to #1, but should be more specific.
The ProPark app shows users all available parking spaces within 1 mile of their current location, and lets people purchase parking within the app, usually at a discounted rate.
4 - What are the alternatives or competitors?
Stakeholders want to know what the alternatives or competitors are, especially if this makes it easier to visualize the product or feature, and understand the value.
Competitors: The two most popular parking apps are Parking Panda and SpotHero
5 - How are the alternatives or competitors different?
How are you differentiated? Use screenshots and/or mocks to demonstrate visually if possible - an image is worth... at least a hundred words.
How our app is different: These apps search a much wider radius for parking spots, and users aren't offered discounted rates.
As a product manager, make sure you have these questions answered in your product or feature briefs, or PRDs, so stakeholders can get the answers they are looking for quickly. It will drastically cut down on your email.
Also, because I love my readers, here's a red panda. You're welcome.