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 1
AM: Inception — Kick Off; Hopes and Concerns
PM: Problem Definition; Value Proposition Canvas; User Journeys
Day 2
AM: Functional Solutioning
PM: Design Validation; Story Splitting
Day 3
AM: Tech Solution Validation
PM: QA Testing Strategy; Story Estimation
Day 4
AM: Story Prioritisation
PM: Roadmap Planning; Project Governance
Day 5
AM: Showcase Preparation
PM: 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.