Most of the product teams heavily rely on “User stories” to describe features. The problem with user stories is that 1) they don’t give you context about what the feature is about, 2) they are not enough for a developer to sit down and get things done.
When I read requirements like “As a user, I want my personal dashboard to tell me on what company to invest today,” I see a huge gap between the user and the feature, that I will need to fill in with a lot of creativity. That creativity is an invitation for multiples bad habits, like refactoring.
Before you even get to write a user story, you need a PRD (Product Requirement Document.) A good PRD covers at least the following sections:
- User: who is this feature for?
- Problem: What problem does the user have, and we will resolve it with this feature?
- Assumptions: what assumptions are we making about the user, the problem, the technologies, and anything relevant to this feature?
- Solution: What are the user inputs (or external system inputs)? What are the outputs?
- Results: what are the success metrics? How are we going to track them?
User stories are just a sub-section in #5.
Even with the PRD and User Stories, you need to follow up with good wireframes, an explanation about what the user will do (user flows) and a good architecture and infrastructure design.
If anything of these components is missing, expect that your developers will do them for you, and you won’t have any saying until the feature is done.
