Most Product Managers have, at one time or another, heard the apocyphal quote often attributed to Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” And when we hear the line, we laugh because there’s no way that we would do such a thing — the “faster horse” is a fictional thing that we’d never actually spend out time and effort working on. We slap each other on the back, smile, and then go back to our office where all too often we return to working on the “faster horse” that we’ve deluded ourselves into thinking is innovative and fresh. It’s an unfortunate fact that much of what we do really is just delivering faster horses, giving our customers what they say they want (or worse, what sales tells us they say they want), and not digging deep enough to uncover the real need, problem, and desire that’s driving the request.
“Agile” is More Than a Buzzword: Continuous Improvement
There’s more to being Agile than just blindly following the rules and processes of any specific methodology. One of the core components of effective Agile practice is internalizing the concept of continuous improvement. As I’ve touched on in other articles, Agile is a direct descendant of the concepts originating in the lean manufacturing movements of the late 1940s and early 1950s. And the single most important part of this ancestry is the focus on empowering and entrusting the people who do the work with setting their own destiny and with challenging each other to improve their practices on a regular basis.
10 Questions with Stephen Cognetta
One of the best things about my blog and other activities is to meet new and interesting people in the Product Management community. Today I’m happy to present the latest in my 10 Questions series, featuring none other than Stephen Cognetta. His latest project is an ambitious online Product Management interview course that was launched just last month. Stephen’s a really great guy, and a strong voice in Product Management; in his own words…
Stephen Cognetta is the founder and CEO of PMLesson, the best online PM course focused on practice-based learning. Stephen is passionate about mental health and has also founded HackMentalHealth, the world’s largest community of mental health + technology advocates. Stephen is a minimalist and owns under 115 items.
Without further ado, here’s his installment of 10 Questions with the Clever PM!
Proper Care and Feeding of Your Product Backlog
One of the least glamorous parts of Agile development for most Product Managers is the process of backlog grooming. It can be a challenge to get teams to engage when they’re in the middle of a sprint, it can be difficult to convince stakeholders to refer to the backlog instead of the Product Manager for simple questions, but most of all it reminds us of the gigantic list of things that we’re not doing — which is a source of frustration for any Product Manager. However, maintaining a clean, healthy, and vibrant product backlog is essential to the success of not only an Agile product team, but to the organization as a whole. When backlogs are clear, prioritized, and public, people can freely and regularly review it, raising questions and concerns as they come up rather than waiting for a big bomb drop of feedback during some strategic planning session. If you’re a fan of my blog, you know that I strongly believe that it’s the little work in upkeep and transparency that transforms an organization from just “doing” Agile to “being” Agile — and the product backlog is the number one arrow in your quiver to make change happen.
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…
- 1
- 2
- 3
- …
- 12
- Next Page »