I’m often asked what the key to being “agile” really is, and over the years I’ve managed to come up with a clear and concise answer: accepting uncertainty is the key to agility. It is perhaps the single most fundamental culture change that companies must go through when making a true transition to Agile development, and it’s often the biggest stumbling block that prevents them from fully becoming agile. You can see this in so many anti-patterns of Agile development: long-term, specific roadmaps; set dates and forced marches; iterations that are dictated, not created by and for the teams; and so many others. All of these behaviors stem from an organizational inability to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along.

It’s become rather commonplace lately for people to dismiss “Agile” out of hand as an industry buzzword with no meaning or substance to it. And in some ways, the term has earned that reputation — mostly from people who use it regularly without really knowing what it means or how it changes an organization — or more accurately, how an organization must change to be Agile. And while there will always be those who abuse such terms, mostly out of ignorance rather than malice, it’s important to remember that “Agile” is a word with meaning, substance, and history behind it. There’s a good reason why the Agile Manifesto begins with the words, “We are uncovering better ways of developing software by doing it and helping others do it.” These words ring true because they aren’t an end in and of themselves, they don’t attempt to prescribe or proscribe any specific approach, and they accept that there is fluidity in what we do and how we do it. Truly embracing “Agile” requires that we hold certain truths to be universal…

As a Product Manager, it’s in our bones to always do the best job possible, to deliver the best product possible, and to satisfy the most customers possible. But what if I told you that by always succeeding, we’re actually hampering ourselves? While it might feel good to hit a home run every time you step up to the plate, you’re probably not playing in the right league. It can be easy to fall into a pattern of complacency, of certainty, of feeling invincible because you never miss a swing — but the simple fact is that if you’re never wrong, you’re playing it too safe and you’re limiting yourself to only what you know that you can accomplish. It takes bravery to step outside our comfort zones, to stretch ourselves and test our boundaries, and to try new things that aren’t guaranteed to be winners. In fact, failure is essential to growth not only as a Product Manager but as a person in general — for it is only in failure that we learn from our mistakes and can adjust to ensure that the next stretch, the next test of our abilities, passes with flying colors. If you never fail, you never grow…

Most companies out there put a huge push on efficiency and running “lean” — doing the most possible with the least amount of overhead. And in most cases, that’s a very noble goal — after all, overhead in the form of people and positions is generally the highest cost that companies face. Reducing the number of people needed to achieve the same goals allows the revenue side of the equation to exceed the costs — which is almost every company’s end goal, to achieve a sustainable business model that makes money for the owners of the business. The problem with this is that it’s often taken too far — the drive to be “lean” winds up causing more headaches and issues than it creates an environment conducive to success. This issue isn’t only of concern to Product Managers, it affects every part of the business, from sales to marketing to support to development. And because of that, we’re often in a unique position to see they dysfunctions that trying to drive too lean causes throughout the company. It’s up to us to be aware of the risks and raise them as we start to see red flags, before they damage the ability of the organization as a whole to compete in an increasingly competitive marketplace.

It’s commonly accepted nowadays that we use user stories or some variation on them to communicate our “product requirements” to development teams (job stories, jobs to be done, scenarios, etc). And while this is certainly an improvement over some of the bad, old Big Up-Front Requirements (BUFR) methods that were used many moons ago, they’re still not perfect, for a wide variety of reasons. All too often, they assume that certain considerations have already been made, that certain work has already been done — when in fact it often hasn’t. Not every development team has a UX and UI member dedicated to help them achieve a story; not every product can afford to have user-story level architecture decisions being made — and every User Story has to be the result of some amount of planning and forethought, both from a business and a technical perspective. While user stories are a great tool, they’re far from the only tool that we need in our drawer to be effective. Here are some things to consider when you’re relying on User Stories as your primary method of relaying work to be done to your development teams.

Due to the unique role that Product Managers play in most organizations, we’re often capable of being the strongest influences on the overall culture of the product development organization and of the company in general. And while there are many companies out there who are truly only interested in giving lip service to the concept of agility, there are others who actually want to be better, who want to embrace the concepts of agility — and it’s up to us as leaders to influence that and contribute where we can. While there are a lot of different behaviors that we can engage in which are likely to increase the adoption of agile practices across our organization, in my experience there are three key things that we should focus on if we want to broaden the success of agile adoption in our companies…

It’s far too common in the world of Product Management for us to wind up being narrowly focused on the actual product development cycle – define, build, measure, repeat. But there’s far more to building, launching, and maintaining a successful product than just what goes on between Product Management and Development. The best and most successful Product Managers try to look at the “whole product” and not just one small (though essential) part like the development process. To get the whole picture, we need our eyes, ears, and fingers on the pulse of all the activities that go on around the product — development, sure, but also marketing, sales, support, implementation, services, and anything else that might be considered “product-adjacent”.