5 Useful Non-Agile Rituals for Product Managers Working in Enterprises

Beyond Agile Stand-ups and Retros

There are well documented rituals for agile product development — sprint planning, daily stand-up, iteration review, retrospective.

When I started working in an enterprise, I found that these ware not enough. The complex stakeholder landscape and geographically diverse business units that exist in an enterprise meant that I needed an extended toolkit to succeed.

Over the years, I have worked with teams to optimise a number of rituals that I have found useful for the enterprise workplace. I’m going to share them here and hopefully you might find them useful too:

Product Discovery

People: Product Owner, Business Analyst, Tech Lead, UX Designer

When: Weeks before workstream inception

Duration: A few weeks or up to months depending on complexity of the project/proposition

Purpose: First you need to figure out what the product looks like. While in a startup the exercise normally starts with identifying a user problem, in an enterprise there are more dimensions to align with:

• Strategic goals — the product has to fit with the strategic goals of the company.
• Resources available — this is a two-way exercise. On one hand, quarterly and annual resource planning would outline what resources are available at a high level. On the other hand, the discovery and the product backlog that comes out at the end of the Inception would inform how much resources is required.
• Technological constraints — such limitations would form the boundaries of the opportunity. In certain enterprises this means having to deal with legacy systems which dictates the effort required to truly innovate.
• Customer problems — this one is similar to the well document process of identify customer pains and getting to product market fit. Usually extensive user testing is required
• Competitive and comparative analysis — benchmarking your proposition against products in the industry and similar products outside of the industry.

Materials from Product Discovery is typically put together in the form of a deck. This deck is used during Inception ‘Kick-Off’ to set context for the workstream and bring all stakeholders onto the same page.

Workstream/Project Inception

People: Full Team (Product Owner, Business Analyst, Tech Lead, UX Designer, Developers, Iteration Manager), Business Stakeholders, Program Leadership, Program Technical Architects, and other Subject Matter Experts.

When: Start of the workstream

Duration: 1–2 weeks depending on project/product complexity and size

Purpose: This consist of a series of intensive half day workshops over 1–2 weeks. The goal is to bring all stakeholders together to so everyone is on the same page. The workshops are facilitated by the core product team. Every stakeholder are invited to attend the first (Kick-Off) and the last (Final Showcase) workshops. Relevant stakeholders are invited to individual workshops. A sample rundown could look like this:

Day 1AM: Inception — Kick Off; Hopes and ConcernsPM: Problem Definition; Value Proposition Canvas; User Journeys

Day 2AM: Functional SolutioningPM: Design Validation; Story Splitting

Day 3AM: Tech Solution ValidationPM: QA Testing Strategy; Story Estimation

Day 4AM: Story PrioritisationPM: Roadmap Planning; Project Governance

Day 5AM: Showcase PreparationPM: Final Showcase

Working Groups

People: Product Owner, Business Analyst (optional), Business Stakeholders / Subject Matter Experts

When: Regular cadence throughout product delivery

Duration: 30mins to 1hr depending on topics to discuss

Purpose: After project inception, the product team will start building the product, i.e. begin ‘delivery’. The team will continue to conduct user research, user testing and come up with new UX/UI/prototype/assumptions about the product. It’s helpful to have a working group consisting of Subject Matter Experts in the wider business to review these early artefacts.

Experts may ask questions or give advice to de-risk the product. Often it leads to a better product that aligns better with business goals and user needs. It also helps with stakeholder buy-ins as these domain experts may become advocates for the product within the organisation.

Product Showcase

People: Product Owner, everyone included in the Inception and Working Group

When: Every 2 weeks or end of each iteration/sprint

Duration: 1 hr

Purpose: This is a forum to demo working software to all stakeholders and share progress against milestones. The showcase can be video recorded for circulation afterwards.

Early user feedback and analytics can be discussed here too. As the workstream progresses it’s useful to use the Showcase as a standard way to communicate progress and results.

Conclusion

I found that in an enterprise environment, just focusing on agile rituals internal to product development isn’t enough. Having these additional rituals helped me manage stakeholders and establish structured communication channels to gauge feedback and ensure our product continue align with expectations and goals.

Feel free to comment below. If you enjoyed this article, please hit that clap button to help others find it.

Follow me: Medium | LinkedIn