Every so often I meet a product manager that tells me that they are not allowed to talk to their users or customers. Sometimes it’s because the sale reps want to control all access; or maybe it’s because marketing is supposed to be the interface with the customer; and occasionally there is literally a corporate policy restricting direct customer access because of worries about inappropriate statements or commitments. For whatever reason, if you work at a company where you’re told you can’t talk to your users, my advice is to first try hard to change this policy, but if that doesn’t work, dust off your resume and find a place where you can practice your craft and have a shot at creating great products.
If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.
Very often I’m asked how product managers should be measured. I have long believed that the only true measure of the product manager is the success of his or her product. While I still believe that, it’s not a very satisfying answer, as it’s not clear what the best way to measure a product’s success is. Is it revenue? Profit? The number of users? Page views? All of these indicators can be useful but they don’t really provide the big picture.
Last week I attended a truly unusual conference (www.gelconference.com). One of the best experiences I’ve ever had at a conference. Anyway, as I was walking around I met quite a few people that recognized my name from the newsletter, and soon it became apparent that there’s some common questions out there, and I thought I’d turn this article into a quick Q&A; for those of you that may be wondering about the same things.
NOTE: "Design" below refers to User Experience Design, and not Architectural or Systems Design.
Few words are more dreaded by product managers than being told by engineering: “No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can’t maintain it, the site is a dog!”
In the previous article I argued for some very significant changes to the way most teams produce software. Several of you wrote to me and asked that I elaborate on my final point, which had to do with the fact that once you have a product definition that works, you can’t just “piecemeal” it up and expect the same results. I believe this is a hugely important point, and gets to the underlying reason for a great many failed products and wasted releases.
I do not believe great products happen by accident. In every case, behind every great product I find that there are certain truths. Today I want to share ten such truths. I try to keep these in mind on every product effort:
Even in small companies, getting decisions made is often time-consuming and frustrating. Every product company needs a mechanism to get the key stakeholders and decision makers together to make timely and informed product decisions.
I have to admit to a strong bias up front: I love Apple. I think they’re responsible for some of the best technology products our industry has produced in the past 25 years, and I have been a fan of the company since the Lisa (which I consider a prototype for the Mac). I view Steve Jobs as one of the best product managers of all time.