The time is always right to do what is right. ~Martin Luther King Jr.
- Update how we build out features: Propose a problem --> Validate the problem --> Come up with a solution --> Build It --> Ship It (leaning heavily on agile processes). Product Opportunities Board
- Centralize progress and status of various features of our product within JIRA (accessible to the entire company) One master project in JIRA which will make a direct connection into the Product Roadmap
- Centralize the product roadmap within JIRA & Confluence (accessible to the entire company). Product Roadmap
Goals
- Transparency
- Sharpen the problem at hand with input from various teams
- Simplify design process with the ability to reference the evolution of the feature with an articulated validated problem
- Easily prioritize where our energy should be focused, leaning heavily on agile processes.
Steps in submitting an idea
- https://betterpt.atlassian.net/jira/software/projects/PO/boards/19
- Once on this board, you have the ability to create an issue
- When creating an issue, ensure you're approaching it in problem speak. Meaning, do your very best to frame it in attempting to validate the problem. You're free to propose a solution, but that should be the very last thing you think about. We need to first gather around the proposed problem, so make sure you articulate it well.
Where you would create an issue
An example of the team going back and forth in an attempt to validate the problem
Goals
- Land on a viable solution from the validated problem that represents the MVP
- Set the boundaries as to what will exist within version 1.0 of the feature accessible to the entire company (making use of MoSCoWs)
- Make use of agile processes to ensure the solution is able to be shipped ASAP where the evolution of the feature comes from our customer feedback.
Goals
- Ensure we adhere to the MoSCoW to push out a feature ASAP
- Produce stories from the finalized solution that enter the backlog of the developers
- Create the necessary epic from this finalized solution in JIRA
- Reference the epic in our Product backlog/table of contents (which will also live in JIRA) to ensure the company has an understanding as to what is being built (i.e. what is Project London?), along with its status (i.e. in progress, 50% done, 99% done), and its projected due date.
All we have to decide is what to do with the time that is given us. ~Gandalf
Backlogs prompt debates and choices that keep a program healthy—not everything can be a top priority.
Goals
- Accessible to the entire company
- Easily reference status and progress of where the feature is as it will be directly be tied to the epics.
- Ability for the company to dig into the details of feature, the boundaries set within a MoSCoW, what v1.0 will look like, along with its anticipated completion date.
Where to view it
Anti-patterns
- Source: https://www.atlassian.com/agile/product-management/requirements
- The entire project is already spec'd out in great detail before any engineering work begins
- Thorough review and iron-clad sign-off from all teams are required before work even starts
- Designers and developers don't know when requirements have been updated
- Requirements are never updated in the first place (because everyone signed off on them, remember?)
- The product owner writes requirements without the participation of the team