|
|
Blog Articles
Estimating Project Costs
Even though we've been estimating project costs since the beginning of software, it's remarkable to me how much confusion remains. I think the root cause of this confusion is that management needs cost information very early in the process, yet engineering doesn't have the information it needs to do a reasonably accurate estimate until much later in the process. The result is either premature estimates that prove wildly inaccurate, or surprises because people had different assumptions all along and when the accurate estimate comes in, management has a severe case of sticker shock.
Make a Friend in Finance
How many of you understand the economics of your product? Do you know your exact revenue model? Do you know the total costs of your product? Do you know how much you pay for each new customer? Do you know their lifetime value to the company? Do you know the return your product has generated for the company?
Build New or Fix Old?
Often I’m asked what the right balance is between new product development and investing in improving existing products. I suppose it’s natural for companies to want to have some sort of percentage guideline, but I try to get companies to think about these investments a little differently. To me, all of these projects are product investments, and rather than worry about whether you’re investing enough in new product lines versus existing product lines, I would rather have the team worry that they’re investing in the best opportunities.
Don't talk to Customers?
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.
The Origins of Agile
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.
Measuring Product Managers
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.
Roles and Ratios
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.
Design vs. Implementation
NOTE: "Design" below refers to User Experience Design, and not Architectural or Systems Design.
Engineering Wants to Rewrite!
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!”
That Dog Won't Hunt
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.