WIP: Iterating Our Product Development Flow Towards Outcomes

Review App: View WIP Product Development Flow

Why is this change being made?

• Our current Product Development Workflow is great at defining roles and expectations per phase but can at times be prescriptive, not leaving enough room for flexibility for teams to collaborate as needed for the specific customer/user problems they're trying to solve. While we do need to provide them a clear framework for connecting their outputs to customer value and business outcomes, we want to leave some room for PMs, EMs and UX to own and decide within the framework what will help them reach their goals best.
• To have more consistency in the process, we should have fewer but very clear required process in the framework vs a long list that is difficult to execute upon precisely, repeatably and scalably.
• Some team members have expressed concern that because there are too many specific requirements in the product development flow, it's difficult to scale and at times feels counter to our values of results (e.g. "measure results, not prescriptive processes", bias for action, etc.), efficiency (e.g. Freedom, responsibility over rigidity), and iteration (e.g. don't wait, MVC, low level of shame, focus on improvement)
• We need to outline the things that are required to keep the trains running on time and break everything else out into a framework of recommended processes, good practices, tactics, tips, and references to help product teams be as successful as possible.

Important characteristics of system behavior we should keep top of mind while iterating on our Product Development Framework

The indicators of satisfaction need to be customer value and business outcomes, not adhering to a process

“The most powerful ways to influence the behavior of a system is through its purpose or goal. That’s because the goal is the direction-setter of the system, the definer of discrepancies that require action, the indicator of compliance, failure, or success toward which balancing feedback loops work.”

“Systems behavior is particularly sensitive to the goals of feedback loops. If the goals-the indicators of satisfaction of the rules - are defined inaccurately or incompletely, the system may obediently work to produce a result that is not really intended or wanted.”

If the right goals are defined, self-organization leads to resilience and stability

“The most marvelous characteristic of some complex systems is their ability to learn, diversify, complexify, and evolve…Like resilience, self-organization is often sacrificed for purposes of short-term productivity and stability. Productivity and stability are the usual excuses for turning creative human beings into mechanical adjuncts to production processes.”

“Remember that hierarchies exist to serve the bottom layers, not the top. Don’t maximize parts of the systems or subsystems while ignoring the whole. Aim to enhance total system properties, such as growth, stability, diversity, resilience, and sustainability - whether they are easily measured or not. ”

Optimize for intrinsic responsibility

“You can make a system work better with surprising ease if you can give it more timely, more accurate, more complete information”

“Intrinsic responsibility means that the system is designed to send feedback about the consequences of decision making directly and quickly and compellingly to the decision makers.”

“Aid and encourage the forces and structures that help the system run itself. Notice how many of those forces and structures are at the bottom of the hierarchy. Don’t be an unthinking intervenor and destroy the system’s own self-maintenance capacities. Before you charge in to make things better, pay attention to the value of what’s already there.”

Author Checklist

• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
• Assign this change to the correct DRI
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to your manager.
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files.

For help with failing pipelines reach out in #mr-buddies in Slack