For many years, “outcomes over outputs” was a common mantra in product management. This approach builds off of the idea that you shouldn’t celebrate when a team completes a story, feature, or initiative. Instead, you should celebrate the big outcomes — think of things like reaching 1,000, 10,000, or even 100,000 users.
The problem with this kind of thinking is that it can place too much emphasis on the end game without considering how you got there in the first place. Although they’re less sexy, product rituals are easier to control and ultimately build the groundwork for success. You can think of these as the continuous, ongoing activities that you engage in with your product teams.
Former football coach Bill Walsh illustrates the importance of rituals like these in his book “The Score Takes Care of Itself” as he explains what it took for him to turn the San Francisco 49ers from the NFL’s worst team into a dynasty. The book’s message is so powerful and resonates so well that I felt compelled to write an article about how you can apply concepts from the book into product management.
This article covers what product rituals are, the different types, how you can establish effective ones, and the challenges you might encounter when implementing them.
At their core, product rituals are meetings, processes, systems, and behaviors. They form the basis of your culture and only become impactful when integrated into an overall system.
Returning to the Bill Walsh example, most NFL teams held meetings that looked pretty similar to Bill’s. The difference was in the way he prepared for and conducted those meetings along with the expectations he held of his players and coaches. His rituals enabled him to build cohesion, maintain focus, and ensure consistent progress.
When it comes to product rituals, you probably won’t be drawing x’s and o’s on a whiteboard. However, just like with a football team, there are routine tasks that you perform that prop up the culture of your team. Some of these include:
It’s important to have some sort of regular team check-in. You want to make sure that your team prioritizes their workflow and that everyone knows what was accomplished, what comes next, and what blockers need to be resolved. Ensure that the sprint (the current development period) has clear goals, the meeting remains short, and everyone has a voice.
In some cases, standups might be weekly instead of daily, or even remote. How you schedule your daily standup depends on a lot of factors — your team maturity levels, your product and company maturity, your company culture, etc. One PM told me, “We prefer written communication as it’s explicit, recorded, and remote-friendly.”
Here, daily standups were only held weekly as all other communication was conducted through Slack or Docs. Other companies may have a stronger in-person culture where agreements are made in-meeting and notes are taken by a scrum master or product owner.
Sprint planning meetings are held at the beginning of each sprint and sprints are generally one, two, or in rare occasions three weeks long. These meetings plan out the next sprint and review the previous one through retrospectives. They help your team prioritize their work, reflect on what went well, and identify improvement areas for the team.
Newer teams tend to struggle to understand their capacity, workload, and velocity (measures of team delivery) and this can lead to poor planning, milestone misses, or in the worst case, upset customers. Typically most teams can recover quickly and understand what they can deliver.
If not, some product and engineering leaders will switch their teams from a sprint planning system to a Kanban system. In a Kanban system, you work on one ticket (or story) at a time before moving on to the next one. This helps your team better understand how long each story is taking because they won’t be working on multiple stories simultaneously.
Another area that teams struggle with is in balancing discovery and sprint delivery. I recently had a conversation with a PM who explained, “Our engineering manager says we need more product work ready for development in the pipeline.” This statement interested me as it pointed out a few issues that go beyond sprint planning:
If you notice these issues, it’s important to recognize that sprint planning isn’t the place to resolve them. Consider setting up some 1:1’s with your stakeholders and be prepared to have some vulnerable conversations to identify where the hangups are occurring.
Monthly product reviews are your team’s opportunity to align with executives on the current state of the product, to demo the latest progress, address the roadmap, and make strategic trade offs or decisions. The meeting is usually led by a senior member of the product team and requires a lot of input from all functions involved in the product development (product, engineering, design).
Since executives aren’t involved in the day-to-day (daily standups) or week-to-week (sprint planning), it’s important that information is rolled up succinctly and materials are sent out ahead of time. This gives executives a chance to get caught up on progress, prepare their thoughts, and determine what questions they have for the meeting.
At the end of the presentation, note that any questions that weren’t addressed can be addressed through email. Take good notes and summarize them so that you can review at a later date.
Customer feedback sessions or customer discovery sessions ensure that your product stays aligned with customer needs. These sessions should be held multiple times per week and product managers should have a steady pipeline of them going at all times. These sessions gather and analyze feedback from multiple data sources to discover new use cases and help you determine what to build next.
In early stages of a product, customer feedback sessions will consume a lot of your time. Over time, your company may expand into multiple products and customer segments. As a result of that success, you may speak with customers less and less frequently because more of your time will be spent managing internal stakeholders.
My only advice here is to be mindful of this phenomenon and do your best to continue to meet with customers regularly. Your best bet is to prioritize your customer requests and ensure that you have a steady stream of feedback coming in.
Cross-functional syncs are meetings with your sales, marketing, or support teams to ensure you have a sound go-to-market (GTM) strategy and plenty of support (customer success, post sales support) alignment. These meetings offer an opportunity for teams to share dependencies and offer support for one another’s initiatives.
Your sales team meets directly with customers so they’ll have the most pointed feedback on what is and isn’t working. Your marketing team will rely on you to provide them with key insights on customer segments, value propositions, and key personas to target. Last, but not least, your customer success team will work directly with customers on product improvements and feature requests. Use these meetings as an opportunity to share across functions and align as much as possible.
Establishing effective product rituals requires you to establish ground rules, open communication, trust, and a shared understanding of what each ritual entails. This can be boiled down to the following items:
While this might look like a lot of tedious work, not putting in the work results in even more tedious work … and alignment meetings!
The good news is that you can automate a lot of these tasks by leveraging technology. For instance, record your meetings and generate a transcript. You can then feed that transcript into an AI summarization tool to generate your meeting minutes.
You can also cancel meetings and move them to asynchronous updates. The key here is that you remain consistent and set expectations of team members so that everyone follows through and remains engaged.
To help you get started, consult the following list of best practices from within the product management community:
No single, overarching method or framework works for everyone. The key is to understand the dynamics of your company, your team, and your product maturity. What works for one team won’t necessarily work for another.
The hardest part in implementing new rituals or replacing old ones is getting your team to “buy in.” Bill Walsh talks about this extensively in his book as he describes his first two years as the coach of the 49ers. He struggled to get his players to believe in his vision until he realized that it wasn’t about pitching an end goal. Instead, he needed to focus on building a daily process.
Speaking about Bill’s book, James Clear says:
“‘The score takes care of itself.’ The same is true for other areas of life. If you want better results, then forget about setting goals. Focus on your system instead.”
In addition to determining the right set of rituals for your team, you need to find (or sometimes manufacture) sources of motivation for them. You’ll need to be consistent all along the way. Sometimes you’ll need to stick with something even if at first it seems like it’s failing.
Throughout most of my career I focused on “outcomes over outputs,” or the “y’s,” as I would like to say. After reading “The Score Takes Care of Itself” and observing high performing individuals inside and outside of work, I’m convinced that PMs need to focus more of their attention on rituals and systems because they’re the things you can actually control.
Outputs might be the shiny objects that stakeholders point towards but your inputs are what determines where your product ends up. To make improvements you need to go back into your progress so that you can build the conditions for success into your product culture. Only then will you have control over your direction. Good luck!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
“Disagree and commit” is a management principle that encourages team members to voice their opinions during the decision-making process.
Drew Doman, VP of Product at Apptegy, talks about leveraging tenets in product management rather than strictly relying on processes.
By strategically combining products, you can offer greater value, increase average order profit, and stand out in a competitive market.
Learn more →
