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…
Is there such a thing as a “full stack” Product Manager?
There’s a rather annoying trend that’s been showing up within both job postings and resumes that’s just crawled under my skin in a way similar to the “ninja” and “rockstar” appellations that developers have adopted. The description that I’m talking about is that of the “full stack” product manager. Now, i totally get where this comes from — in the world of development, there are clear distinctions between developers who focus on the backend systems, the middle tier of integration and business logic, and the actual customer-facing user experience. This is because the skillsets for each of these isn’t necessarily directly transferable to another area — especially with a junior developer who generally excels at one of the three areas, and isn’t quite as competent at the other two. Now, it’s entirely natural for a developer to grow in those lackluster areas over the course of their career, to the point where they might legitimately be called a “full stack” developer. But the same just isn’t true for Product Managers — primarily because we don’t really have anything close to a clearly defined “stack” that we can master. Let’s take a look at what this means for us…
Knowing Your Effort Budget
It’s amazing to me how often I talk with someone about a project they’re working on, and when asked “what’s your budget on this” they just look at me with a blank look. Let’s be real for a minute — everything we do in product design, development, and management has limits. We have limited resources. We have limited time. We have limited energy. But all too often we just assume that everything that we’re doing requires 100% of our effort, 100% of the time. But that’s simply not true. Some things are more important than others. Some things require more time and effort and energy than others. Some things that we do can slip through with a smaller amount of our attention than others. We instinctively do this, but we rarely actually plan it — and that’s to our detriment and to the detriment of our stakeholders. Laying out a clear understanding of the amount of effort that you’re expecting to spend on any given project or component can be an essential tool in any Product Manager’s belt.
That Which is Urgent is Not Always Important
We’ve all been there — that sudden call from one of your Sales team with a customer “on the hook” but they only need this one more thing to close the deal. Or maybe it’s an escalated issue from your biggest customer that lands in your mailbox with gigantic ALL CAPS AND EXCLAMATION MARKS!!!!!! Or worse yet, it’s your CEO who “stops by for a quick chat” about something that he overheard at an industry event last night. Regardless of where these things come from, they all have one thing in common — they’re urgent. They require your time now. They simply cannot be ignored.
Or can they? Or more accurately, should they be ignored? If you ask me, the answer is absolutely. Things that are “urgent” are thrust upon us by others with some expectation that we’ll drop everything and deal with them — not on our terms, but on the terms of someone else. Here’s why you should beware of the urgent and instead focus on what’s important…
How to Be a More Agile Product Manager
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…
[Read more…]
Pack ’em Up! Understanding Your Portable Skills
I’m often asked by in both formal and informal discussions whether I think that Product Managers are stuck in whatever industry they start in, and if not how to break into a new one. And through all the years of having these discussions I’ve determined that the vast majority of the skills that make someone a great Product Manager are entirely portable between companies, products, and industries. You can learn a new product pretty easily, assuming that you have an organization with a good onboarding process. You can learn the market pretty quickly, assuming that the company has some internal experts already there to learn from. And you can learn the politics of the organization by just paying a small iota of attention in your first 30-60 days in the organization. None of those things are directly determinative of success as a Product Manager — what is determinative is the soft skills that you bring along with you, your approaches to problem solving and consensus-building. To that end, here are three key skills that any Product Manager should leverage no matter where they are and no matter where they want to go.
Reduce, Reuse, Recycle – The Importance of Reducing Waste
I find it entertaining when people talk about how Agile and Lean and Kanban are all relatively new, untested, and revolutionary concepts. That’s because they’re none of those things — they’re simply descendants of ideas and concepts that have existed in manufacturing contexts for a half-century or more, just pitched in a different way, at a different time, to a different audience. What we talk about now is just an evolutionary adoption of principles of line production that were brought into being by W. E. Deming and his contemporaries at the end of World War II — the concepts of identifying and reducing waste, focusing on just-in-time stock-keeping, and narrowly focused on doing only the work needed to move a product to the next step of the line. Even the empowerment of individuals and teams owes a great bit of gratitude to the Toyota Production System and it’s focus on granting every line worker the power to stop the entire process if there was something wrong or something to improve upon. I think that it’s past time that we not only acknowledged this history but embraced it — and leveraged the long history of success in that domain over into our own work.
- « Previous Page
- 1
- 2
- 3
- 4
- …
- 12
- Next Page »