View profile

How-To Guide: Product Development & Release Management: Part 1

Part 1: Planning Milestones & Development Sprints Part 2: Sprint Retrospective, Kickoff & Bac
How-To Guide: Product Development & Release Management: Part 1
By Gannon Hall • Issue #8 • View online
Part 1: Planning Milestones & Development Sprints
Part 2: Sprint Retrospective, Kickoff & Backlog Grooming
Part 3: Daily Standups
Part 4: Story Pointing & Velocity Calculation
Part 5: Cross-functional Communication & Stakeholder Engagement
Part 6: Release Management
Part 7: Impact Analysis & Feature Iterations
Part 8: Functional Workstreams & Roles
Part 9: Products, Major Initiatives, Features & Stories
Part 10: Stories, Tasks, Artifacts & Tools

The goal of a development and release management process is to provide guidelines to help improve the flow of information, accountability, quality, and velocity of software releases. The goal is not to impose executive oversight or control. On the contrary, tight product planning and release management enables more empowerment at the lead level and helps prevent unplanned projects from derailing the roadmap.
These guidelines borrow practices from a variety of sources but can best be described as a variant of the agile scrum methodology.
Adopting a quasi agile scrum methodology does not mean that you should favor speed over quality. If a feature isn’t ready you shouldn’t release it. Ideally, changes/fixes that address the feature’s “readiness” will be made and the feature will be released in the next sprint.
Product Squads
Squads are an autonomous unit of PMs, engineers, and designers primarily responsible for a portion of the user experience or business function evident in their squad name. A squad should have at least 1 PM lead, 1 Engineering lead, and 1 Product design lead. Squads use OKRs and sprints to represent the impact of the work they do to continuously improve a user’s experience.
Planning Milestones & Development Sprints
Weekly Product Review Meeting
Product review meetings are a weekly meeting to review plans and works in progress. The purpose is to inform, discuss and decide on a range of initiatives in different stages, with the goal towards keeping each other informed, gathering feedback and building consensus on next steps. This is the meeting where Feature Briefs, critical updates that cause roadmap changes, designs, and demos are reviewed (along with a variety of other points of interest).
Stakeholders should consider product review meetings their primary source of product information and their primary opportunity to provide feedback on product direction and functional design. Product should make this opportunity a priority. It is vital that relevant stakeholders outside of the tech org are involved as early as possible. With that said, if a stakeholder chooses not to attend a meeting or engage in the process, they forfeit their input.
Major Initiative Kickoff Meeting
The major initiative kickoff meeting happens once as a squad begins to design and scope a Major Initiative. It is where a Feature Brief, that has been given the go-ahead to continue exploration after a product review meeting, is broken down into design, analysis, and engineering tasks resulting in artifacts such as wireframes, EPQs, and/or user research studies. Tasks identified in designing and scoping the initiative are assigned during this meeting.
A squad’s lead PM, lead engineer, lead analyst, and lead designer are required to attend this meeting while optionally inviting stakeholders and other key designers/engineers/analysts who are likely to be significantly impacted by the Major Initiative or take on tasks coming from the Feature Brief. If a stakeholder chooses not to attend a meeting, they forfeit their input.
Design Review Meeting
Design review meetings have 3 possible subjects: visual/UX design review, user research review or technical design review.
Invitees should include all squad leads (engineering, product & design) or their chosen proxies, and all stakeholders likely to be impacted or interested. Lead Product Managers, Engineers, & Designers have the responsibility of encouraging stakeholders who are likely to be interested to attend.
Regardless of the format, the purpose of the review should be made clear by the Lead Product Designer. The designer should also make it clear what kind of feedback they need for from the group.
The feedback gathered may lead to additional design and/or research tasks to be created. The Lead Product Manager should work with the Designer and/or Researcher to estimate the level of effort (LOE), and plan the next review accordingly.
The design review meeting can happen any number of times between the major initiative kickoff and feature planning meetings. The number of times this meeting happens is at the discretion of the lead PM based on his or her judgment of when the squad is prepared to begin work on any part of a major initiative.
The lead PM is responsible for clearly communicating, to all interested parties, when a scheduled design review meeting will involve making a decision on design finalization.
Feature Planning Meeting
The major initiative planning meeting is where Stories in a technical design and/or UX specs are translated into Tasks and estimated using Story Points. This meeting is scheduled on an ad hoc basis, and typically should happen once for a Major Initiative, and usually covers several weeks of work for an entire team.
Feature Planning is led by a PM and involves an engineering lead and the engineer(s) who will own at least one task from the technical and/or UX designs. An effective practice is to have a PM walk through UX Designs and prompt engineers to break down each part of the design that requires a Task, or the lead engineer talks through the technical design to prompt the PM to create tasks for each component of architecture, logic and/or implementation.
Sprint Milestones
Sprints are 2 weeks periods in which all tactical work for major initiatives and features is completed.
Example Sprint Calendar
Example Sprint Calendar
No Meeting Day
In the Sprint calendar above you’ll notice that we’ve designated Weds as a “no meeting” day. While managers often have to break this rule, the goal is to dedicate at least one day a week of uninterrupted work. I have found that this practice contributes greatly to productivity.
Thanks for reading, next week we’ll look at Sprint Retrospective, Kickoff & Backlog Grooming.
Did you enjoy this issue?
Gannon Hall

Lesson's from the front lines of product management and leadership

If you don't want these updates anymore, please unsubscribe here
If you were forwarded this newsletter and you like it, you can subscribe here
Powered by Revue
Gannon Hall, 1856 Green Street, #3, San Francisco, CA 94123