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…
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.
User Stories Aren’t Enough
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.
Assumptions, Risks, and Constraints – The Keys to Success
One of the most important parts of being a Product Manager is making sure that your stakeholders and developers understand not only what you’re trying to do, but the surrounding circumstances in which you’re trying to do it. Often, this is a matter of discussing and managing scope; at other times, it’s making sure that people understand the schedule and resources working on the improvement; and at still other times, it’s ensuring that what comes out at the end of an iteration is what everyone wanted at the beginning of the iteration. But there’s a larger set of considerations that are of key importance to aligning your teams on — because they significantly impact the overall success of what we’re trying to do. All too often we ignore these three components to our peril, and when we do there’s an even chance that they’ll come back to bite us in the ass…
- « Previous Page
- 1
- 2
- 3
- 4
- …
- 18
- Next Page »