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…
Sometimes Failure is the Best Result
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…
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…
Five Differences Between a Junior PM and a Senior PM
Even though it’s been around as a formal role in software organizations for nearly 20 years (or more, depending on who you talk to), Product Management still struggles with a lot of definition problems — what is the role, how do we grow, when do we get promoted and to where, etc. One of the common issues that we run into are companies who don’t have any form of structure around their product teams, who struggle to define the actual differences between their “associate”, “general”, and “senior” Product Managers without simply resorting to the amount of time they’ve been in the role. As anyone with extensive experience in the profession can tell you, how long you’ve been doing the job has little to no bearing on your actual ability to do the job — you can work for 10 years practicing all sorts of bad behaviors that have resulted in zero growth as a Product Manager. Similarly, you can go deep and hard for 2-3 years and come out the other side as a true product leader and influencer, capable of taking on much more advanced products and projects than your companions. Here are a few of the common differences that I think draw dividing lines between a “junior” Product Manager and a “senior” Product Manager, where age is not the most important factor…
Running Too Lean Can be More Harmful than Helpful
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.
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- …
- 43
- Next Page »