Feature definition: turn a request into a useful product capability
Feature definition explains who needs a capability, what it lets them accomplish and which behavior belongs in the release. A name such as "Saved items" is a starting point, but the team still needs to agree what people can save, where they find it later and what happens when an item changes.
Find the task behind the request
Imagine a learning app whose readers ask for bookmarks. Before specifying an icon, investigate when they want to return to a lesson and how they find it today. Saving a lesson for later study is a different need from keeping a permanent copy for offline use.
Write down the observed problem and separate it from your proposed solution. Interviews, support requests and behavior in the app can inform the decision. If the evidence only shows that people lose their place, a resume-reading feature may fit better than a collection of bookmarks.
Describe the result before choosing the controls
For this hypothetical app, choose a narrow result: a signed-in reader can save a published lesson and find it again in their account. The brief can then describe adding, opening and removing a saved lesson. Offline copies and shared collections remain outside this release.
Atlassian's guide to user stories frames work around a user's goal and its value. A story can introduce the need, while the feature brief resolves the behavior that a short statement leaves open.
Agree the boundaries that change the experience
Decide whether the saved list belongs to a device or an account, which readers have access and whether limits apply. These choices affect what a person expects after switching phones or changing a subscription.
In our example, bookmarks follow the account across devices. Saving twice keeps one entry, removing a bookmark does not delete the lesson, and a withdrawn lesson remains listed as unavailable until the reader removes it. These are design choices for the example, not universal rules for bookmarks.
Make incomplete and failed actions understandable
Suppose a reader taps Save while the connection is unavailable. The team needs to choose whether the app queues the request or asks them to retry. For this version, keep the lesson visible, explain that it was not saved and offer a retry. Do not show a completed save before the account has recorded it.
Describe the empty list and any access restrictions alongside the successful path. A reader with no bookmarks needs a route back to lessons. Someone opening a saved paid lesson after their subscription expires needs an accurate explanation of the access condition.
Use the brief to decide what happens next
Review the example with design and engineering before estimating it. Ask each person to explain what the reader sees after saving, reopening, removing and losing access to a lesson. Different answers expose decisions the brief has not settled.
The next choice is whether this capability deserves development now. Use product prioritization to compare it with other opportunities. Once it is selected, carry the agreed behavior into product requirements rather than rewriting the feature from memory.
- User and situation: a reader wants to return to a lesson.
- Useful result: the lesson can be found again from the same account.
- Included behavior: save, reopen and remove a bookmark.
- Boundaries: no offline copies or shared collections in this release.
- Acceptance: the chosen behavior works across the agreed account and network states.
Sources
Discuss your product's next step
I help define product priorities, plan launches and investigate where users drop out.
