Product Development Process
Step five in the 9II9 product lifecycle is Build. The build phase of the product lifecycle focuses on the software development, testing and incremental release of product features.
Development Methodology
Agile Scrum is a popular software development methodology due to its ability to adapt quickly to the changing needs of users, market needs and stakeholders. Scrum gives the Product Manager the ability to effectively manage the return on engineering resource time by making sure the team is working on the features that are delivering the most value for the user and the organization with minimal waste.
Agile Scrum
In Agile Scrum, a product feature is stored in a backlog until it is ready to be worked on by being assigned to a 2-week development sprint. During this 2-week period, the development team self-organizes around the work to be done, using a daily standup meeting to discuss the previous day’s tasks, today’s tasks and any impediments. The daily meetings are called a Scrum. The development team continues to release new features internally every two weeks until the final product is deemed ready for external release to the public.
Kanban
Kanban is another software development methodology that allows mature product development teams to move even faster by leveraging a process of continuous delivery of features as they are done, rather than waiting until the end of a 2-week sprint. In the Kanban approach, development tasks are carefully managed and the team is only allowed to have a fixed number of tasks “in-progress” at any given moment. In order to start working on new tasks, an existing task must first move out of the “in-progress” and into either the “verify” or “done” columns.
Some media companies may find that using the Kanban methodology for providing operational support to existing products is an effective approach for completing small development tasks outside of a sprint. As bugs or minor enhancements are reported developers are able to execute and deliver minor updates to existing products without disrupting commitments of the dedicated Agile Scrum teams whose focus is primarily on new feature development.
User Stories
There are several ways in which a Product Manager can lead feature prioritization exercises. User benefits vs features is one approach that the Product Manager can take in deciding what features to build or improve. These are not to be taken as actual exercises to be completed for each feature or product idea, but should serve more as a mental model for how the Product Manager should think about building consensus around prioritizing features.
Prioritizing Benefits vs Features
Product Managers are surrounded by opinions about what features should go into a product and need a framework to assist with prioritization. It helps the team to align on what user benefits that should be addressed.
A good framework for prioritizing is to create a table with four columns. In the first column, list the user benefits or features that should be addressed. In the second column, note the importance of each feature or benefit to the user along a spectrum from low to high. In the third column, list the the user’s current level of satisfaction with each particular feature or benefit using the same spectrum of low to high. The fourth column contains the estimated upside potential of High, Medium, or Low based on current satisfaction and importance to the user rankings.
The deciding factor is driven by insight into the user’s current level of satisfaction with a feature, how important it is to their daily life, and the upside potential if the product team were to invest in developing that feature.
User Acceptance
As the development team begins working and marking certain tasks as done from their side, the Product Manager and Quality Assurance will do a round of user acceptance testing to validate that the feature is being implemented according to expectation. These are mid-sprint review sessions that serve as a way to identify potential issues before making it to the end of the sprint. See the appendix for guidance on writing user stories with acceptance criteria. In a media organization that doesn’t have a dedicated QA resource or team, the responsibility of acceptance and functional testing rests with the Product Manager and editorial lead who will review, verify, and close items at the end of each sprint.