An overview of a fast-pace product development process.
1. Product requests and ideas are collected using a variety of sources and techniques. They come from customers and internal stakeholders, and are gathered using brainstorming sessions, interviews, online feedback capture, focus groups, analysis of sales win/loss reports and support cases, competitive analysis etc.
Product requests and ideas are captured as Wishlist items.
Note: there is a separate escalation process to handle requests of urgent nature, e.g. issues impacting customers.
2. Wishlist is prioritized every six to seven weeks (twice a quarter). For an overview of the prioritization process please see The Art and Science of Product Prioritization.
3. Items selected during a prioritization session are moved to the Design Queue for analysis, requirements definition and design. Output of the design process consists of lightweight documentation, wireframes and visual comps (where needed).
4. Once an item design is done, it is moved to the Product Backlog.
5. Every two weeks, Engineering Team selects items from the Product Backlog for implementation in a bi-weekly sprint. Our Development Process post provides more details.
6. Product enhancement and fixes are deployed to production every 2nd Wednesday. Release notes and updated documentation are published on the Help Center shortly after a release.
Robert Tekiela
Hello Robert this is good advice, but what should be highlighted in addition is the wishlist item’s fit into the product architecture and direction. essentially does it fit with our direction. There is also a great need to revisit what the core product is on a regular basis.
Shep,
I agree with you one hundred percent. We evaluate item fit during prioritization sessions. Revisiting core product is done in the context of periodic business and product strategy sessions.
Bob
Robert,
this is a great process, but I had a query here. In India, there is significant attrition in teams, leading to slippage, causing defects which lead to customer escalations and more time spent on bug fixes. How does your team handle partial completion of sprint backlog.
Partial completion of the sprint backlog is OK. Items which are fully completed get merged into develop branch (for deployment on staging), then to the master branch (for deployment on production) and get released. Items which are not finished stay in feature branches and roll over to the next sprint.