| layout | title |
|---|---|
page |
Everyone owns the problem |
Define the actual problem you are solving with the product. Everyone on the team needs to understand who will use the product and why. Any time a developer writes a line of code, they should be aware of how this change will impact the end user and how it relates to the other features of the application in meeting the overall goal of the project. Every member of the team, periodically throughout the product development cycle, should have the opportunity to hear from people in your target audience and understand first-hand about the problems the new software service is intended to solve.
This principle applies on a large and small scale. Broadly, this applies to the key problem you are solving with the whole project, and narrowly this applies to any problem that anyone on the team encounters. Each person on the team should be encouraged to speak up if they see a problem or an opportunity for a better solution.
Examples:
- A user research expert will develop an overall plan and strategy for gathering information from the target audience, but every team member should conduct user interviews and observe usability tests.
- Everyone participates in design ideation (design studios, idea sketching).
- Daily standups and regular restrospectives provide an opportunity for anyone to raise and solve issues.
- In sprint planning, the whole team reviews stories, breaking down use cases into small user-facing stories.
- Team members self-assign stories, according to their own skills and availability, always working on the highest priority task.
- A different person who worked on the story closes it. For user-facing stories, ideally a customer or team member representing the customer. Merging a pull request is not the same as accepting a story.