How can you balance agility and stability in product management?

Agility in Product management comes from an intentional effort at defining the success use case, scoping and hard prioritisation to deliver value at each sprint. Scoping down is often hard, but is crucial to answering 'what value are we adding, what problem are we solving for the users?' The solution maybe a new feature or an optimisation but as long as it is based on data based prioritisation, it will deliver value in an agile manner. Execution with agility requires frameworks for user testing, AB validation, lean shipping cycles, live site support mechanisms, real time metrics (to catch any failures before they impact), tight guardrails and lean processes. Most of these are engineering excellence practices and must be invested in.

Being Agile is not about chaotic work that blindly pushes forward just to meet sprint goals. It's about maximizing the value of the development output. Thus, the greatest value there is, is to keep the Product working and working stable. "Keeping the Light On" [KTLO] is thus usually the highest priority!

Don’t deploy on Fridays! The key reason is to budget time for unexpected silly mistakes / user feedback / scale related issues even if it’s ‘a quick change’. If your availability will be low right after deployment, this can prolong any potential negative impact. If you get the itch to deploy on Friday… distract yourself with something else!

Adopting an agility-based mindset can be exponentially accelerated by assuming the best: -Assume every piece of feedback you get is with the intent to make your product better -Approach every interaction with a user with the mindset that they're an intentional partner -Collaborate with internal stakeholders knowing that they want the best for your product because that delivers the results they need With these best intentions in mind, you can (and will) frame the conversations in a positive mindset that will help get to the WHY behind the discussions.

An agile mindset is just one pillar in achieving product stability and agility. Other things to look holistically are: Clear goals provide stability, while agile frameworks like Scrum and MVP approaches offer flexibility. Cross-functional teams unite specialization and collaboration. Continuous feedback and data-driven decisions sustain agility. Prioritization, risk management, and an adaptable release cadence strike the right balance. Effective communication ensures alignment. Adaptation over time is the key to navigating this dynamic landscape successfully.

Imagine you and your friends are building a castle with blocks. Each of you has a role - one person decides what the castle should look like (Product Owner), another makes sure everyone is working well together (Scrum Master), and the rest build the castle (Development Team). You plan what you'll build each day (Sprint), review it, and then plan for the next day. This way, you gradually build your castle block by block.

One of the main tools in Scrum is Prioritization. Best backlog prioritization is: - Transparent - Value-driven: Each item's value is calculated using a formula, not based on opinions. - The formula evaluates: - Financial impact - Client effects and user experience - Technology and future improvements - Task size and resources required All metrics can be calculated Involving different team members in assessing tasks is an effective approach: - Product: Financial assessment - UX: Evaluation of client effects - Tech Lead: Assessment of task size and technology improvements. A helpful tip: Using task size as a denominator implements the LEAN approach. This ensures that large-sized tasks are broken down into smaller ones

User feedback is the key. Must be a skeptic to ask your users, how they see it and why! This will help a lot to understand what they need to accomplish. The way of treatment is the main pillar.

The use of agile artifacts can be helpful when discussing the progress of product development. However, to effectively align agility with stability, it's crucial to connect these actions, tasks, or stories with product objectives, user needs, or problems. These objectives should be implicit in your product strategy and vision. Additionally, these tools can be useful for making trade-offs and adjusting prioritization based on both business and team needs.

With over a decade in the product management, the Daily Scrum has always been a bit of a double-edged sword in my book. It’s structured to be this concise, to-the-point meeting where everyone aligns, but more often than not, it ends up being a tightrope walk between sharing critical updates and avoiding turning it into a status reporting session. There were instances where team members, instead of being engrossed in their creative and problem-solving zones, were inadvertently sidetracked, crafting their next day’s update. It raises the question: How can we preserve the collaborative spirit of the Daily Scrum while also safeguarding the deep work zones that foster innovation and problem resolution?

Also, don't worry too much if you are not following certain methodologies to the letter. Agile principles are enough for you to start. Use your first principle thinking and just adjust to your company's or team's situation. After, just regularly do evaluation, and deepen your understanding on agile principles. The principles are there to stay, frameworks and techniques will come and go

In my experience, leadership should be embraced in any agile deiven organization. Dont fake Agile while ignoring the values and adjustments being made only fulfilling the needs of the stakeholders/business leaders. Once the commitment has been lived by the team, everything will run fluid. Otherwise look oout for any wastes which are being generated.

The framework isn't the most important part to driving stability - knowing where you are, and where you want to be against your overall goals is critical. The framework is merely a means to the end. But first you must know the end you want to achieve. Is your biggest strength of your product your stability? Do you want to maximise it? Do you know where you are now, and if you should invest more? These are the key questions that set the goal for you to execute within the framework. Do not let process override delivery of results.

Simply, ensure that all stability-related tasks are included in the Definition of Done for each user story. This way, the product management team can concentrate on the business outcomes defined for each story (Acceptance Criteria), while the team takes care of stability within the scope of the Definition of Done for each story

User feedback is the key. Must be a skeptic to ask your users, how they see it and why! This will help a lot to understand what they need to accomplish. The way of treatment is the main pillar. Focus on this

Agility without a clear objective is aimless. Always set targets aligned with your organization's goals, like profit or sustainability. Agile practices mean little without the right mindset; keep your focus on the original principles of delivering success. Measuring is vital, both for maintaining stability and assessing if you're achieving your objectives. Finally, balance your goals to get a fuller picture. For instance, weigh customer numbers against delivery pace to ensure your product is both profitable and responsive. These insights can serve as a backbone for effective agile management.

I would rather consider vision and planning as key elements for stability. Agile is great as mindset in general and way of working where suitable, but still needs a good planning aligned to the vision on long and medium term.

One of the Agile methodologies recommends releasing deliverables to the customer incrementally, ensuring high quality at each step. This approach aligns with Agile principles and methods, emphasizing the importance of maintaining stability throughout the process. It's crucial for everyone on the team, including product management, to adopt this mindset, as any compromise in product stability can lead to customer dissatisfaction and, ultimately, poor product management

If you're building zero-to-one, your focus should be on change management and tying decisions back to the product strategy and product goals. If you're iterating on a product, control your variables and tie decisions back to metrics. Focus on testing and validating assumptions.

I believe we should Implement release staging environments where we can test new features and changes in a controlled setting before deploying them to the production environment. This minimizes the risk of instability in the live product.