3 Product Lessons I Learned from the Cleveland Browns

Unfortunately, I have been a Cleveland Browns fan my whole life. Since 1995 they have only produced two winning seasons and each year I ask myself why I even bother cheering. As a software product manager, I also read a lot about how to learn from mistakes, failure, and organizational problems —all of which the Browns have in spades — to produce products that make customers happy. This NFL season I watched the Browns play the Baltimore Ravens and realized what I have learned about my profession through their failures:

#1 No Situation is Perfect: Learn to Embrace Constraints

The Browns have been through 11 quarterbacks since 2005. When you talk to a Browns fan they will typically tell you, “it’s a rebuilding year” because of this constant change. The unspoken agreement between the fans and the team is that since there is a new quarterback, the team will need time to adjust — so the fans shouldn’t expect much. Seems reasonable, right? In the case of both the Cleveland Browns and product teams this attitude works as an insidious tool to explain apathy.

In product teams, constraints usually surface in the forms of: timeline, resources, management or customer expectations, legacy support for an existing application or some combination of all of these. For example, recently our team was working to launch a new iOS app, while supporting a legacy app that was in production. The team was under a lot of pressure to launch, but kept seeing delays as the operations maintenance for the legacy app compounded due to months of neglect. The team felt like they needed more resources to help with the operations load, but this was not possible. After several iterations of failed milestones we made two decisions that allowed us to launch in a reasonable time frame. We decided to only fix problems with direct revenue implications and cut scope of the project to only recreate features that existed in the legacy app.

Our success on the launch can be attributed to a shift in thinking facilitated by both the acceptance of our resource constraints and explicitly stating the team’s goal (launching the new app). This sounds simple enough, but too often one of these two components — either the explicit statement, or acceptance of a limitation— is not present. For instance, it would have been easy for an engineer to refuse to hit milestones without operations support, or for a manager to add scope based on expectations for the new app. Another important component was agreement around a few key success metrics: average app store customer rating, daily crash-free user percentage, active users and sessions. With an agreement on the end goal, key metrics and a commitment to work around constraints, the team was free to come up with innovative solutions to problems.

#2 There are No Unimportant Plays! (Or Why Ownership is so Important)

It was the third quarter of the first game against the Baltimore Ravens and the teams were locked in a close game. On third and long of a pivotal play, Joe Flacco (the Ravens QB) threw an incomplete pass and as soon as the play was over a penalty flag was thrown. This is the moment all Browns fans dread — when we realize a big play is about to be called back because of a penalty. The play was called back and the Ravens proceeded to score a touchdown.

The failed third down conversion that turned into a touchdown was difficult to watch because it seemed to be the result of attitude rather than ability on the Browns’ part — that is, the offending player probably thought “this play probably won’t have a big impact on the outcome of the game”. This attitude displays why it is critical in product teams to empower individuals to feel ownership over team results. Our team was designing a series of app screens that allowed sellers to list items on Tradesy (a peer-to-peer marketplace for women’s fashion) — a critical piece of functionality — and our designer was happy with how it looked visually, but torn on whether or not he needed additional user feedback on text and imagery. He eventually went forward with gathering feedback and held off on developing. He found several big problems, including one that left users confused on how to edit pictures, which is a key function of the flow. If he had not felt like an owner he could have just as easily passed off the designs after he was happy with the visuals, but instead he found problems early and it turned into a big win.

I use a couple tools to empower contributors on projects such as this one: First, a user experience lab, where we show designs to customers, to give designers, developers, and business folks feedback and show them how their decisions affect group results. Second, a dedicated time in weekly planning meetings for team members to call out what works and what doesn’t in relation to team goals (e.g. to increase checkout percentage). Finally, a goal setting system that encourages individuals to align their goals with those of the group, such as the OKR system.

Maybe the next time the Browns find themselves in a tricky situation, each player on the field will similarly ask themselves “how do I make sure the team wins?”

#3 ABG (Always Be Growing)

The Browns are known as a running team, but successful seasons have come when they have the ability to pass the ball. It is obvious that they can’t win without a strong passing game or at least a healthy mix of the two, so why does the team insist on focusing on the running game year after year without at least trying new models? I don’t work for the Browns, but my instinct tells me that it’s based on the faulty assumption that what won for them in the past will work in the future.

When you see a group that stubbornly refuses to evolve, it becomes clear why it is so important for product groups to invest in the future and proactively experiment with ways to drive the business forward. The fact that there are growth teams in every company now speaks volumes to this point. The poster child for the value of such experimentation is Amazon Web Services. The group started as tools and infrastructure just for internal Amazon teams and in a decade has proven to be over a $5 billion business. This would not have been possible if Amazon clung to the belief that it was only an e-commerce company.

In addition to exploring new business lines, it is important to continue learning from customers in order to innovate around existing products. At Tradesy, one area in particular where this comes up a lot is around seller services. Sellers often ask questions about how to manage inventory, get better information on pricing or find insight into what is working with buyers. This feedback may lead to seller applications that aren’t necessarily tied to our current listing and sales process, but our group feels that it is important to keep an open mind about what is possible for these customers. Of course not many people would disagree with the statement that a product group should constantly learn and evolve, so the difficult part is cultivating this attitude in daily operations, specifically:

• Set learning goals each sprint — work to test something new every cycle
• Put a framework in place to organize customer feedback and synthesize with the group once a month.
• Talk, talk, talk to customers as much as possible — user test, interview, survey — make it part of your weekly or monthly operation.

To grow is to constantly learn, evolve and change with your customers something any good product group and sports team does well.