As newly registered user i only wanted to say hi to everyone else who uses this forum

You have to know the value of a feature before it gets put into the development pipeline. It might be that the feature is a parity feature that provides no competitive value, so you could skip it entirely.

Each release should have its own sales cycle. How many upgrades did you sell? How fast? How many new customers or returning customer did you have?

How many features fell from points of difference to points of parity? How many new features added to your points of difference? How many features moved from points of contention to points of difference, or points of parity?

You should be able to score each release in these ways. You may not get it down to a feature, but you would know how your feature mix is driving revenue.

Since revenue and other financial metrics are generally important to a company, can you offer suggestions on how to accurately measure the financial impact of a feature? For example, how do you measure the financial impact of adding a new report to a product? It certainly is buyer-facing, but how can we measure the feature’s effectiveness in signing up new customers (especially when the report is not on the product list as a separate item, but rather simply bundled into the existing product)?

Another approach to the risk is evolutionary development where several teams address the same risk independently. Then, at different points in time, the progress of each approach is weighed. Some approaches can be eliminated. Then, continue and iterate this process until the functionality is delivered.

Utlimately, the delivered functionality will have to meet the non-functional (“How Well”) requirements, or the release criteria might have to be reduced.

The reality is that nobody fails. Failure is up to management, not up to the people doing the work. Sometimes you can meet the goals at the specified level of performance and still fail. Failure is not tied to having goals or realizing risks, so the developers should be fearless in their pursuit of functionality.

The same can be said about goals. If a goal is the responsibility of a larger organization, it will typically be broken down and allocated across the organization. The metrics have to be broken down and allocated as well.

Coupling and cohesion can be applied to goals to the same degree that they are applied to code. Appropriate coupling at the code level provides for encapsulation. Likewise goals, responsibilities, and metrics.

There doesn’t have to be a larger discussion. There does have to be someone that decides how the goal will be partitioned. That someone is ultimately responsible for the goal. The people or unit allocated a partition are responsible for the subgoal.

Without an intervening project manager, the partition within a team falls to the team lead, and across teams falls to the product manager.

Individual programmers in separate teams should be able to negotiate around their code without escalation.

No one ever comes out and says “We don’t want to set goals if we’re not sure we can meet them” directly — it’s usually part of a discussion where they talk about how their group can do the right work to meet the goals, they just don’t trust that another group will pull their weight. Or, there will be caveats about the methods we’re using to estimate revenue or traffic or ROI, and how they’re not tested or reliable

When I hear that, it’s always just shorthand for someone not being willing to sign up for a goal since they’re not sure they can meet it. If they were 100% confident they could meet it, they wouldn’t have all these objections. And it’s not just about whether you get a bonus based on it — it’s about not wanting to look bad, part of a bigger issue about people not admitting mistakes and not working towards continuous self-improvement.

And yes, “We can’t agree on what the impacts and goals should be” is part of a bigger discussion. I’ve found that often you don’t have that bigger discussion if you don’t bring up metrics. A new idea is proposed, everyone gets excited, you start building it, and the only way to get people to stop for a second and think about “why” we’re doing it is to ask about metrics, which leads into the discussion about goals.

The primary goal in any company is hitting some dollar figure, and making a growing contribution towards that every quarter. This goal is always there even if nobody sets it. Otherwise, you don’t have to wait for the next crowd.

And on this one “We can’t agree on what the impacts and goals should be.” – I feel like that’s a bigger problem then just measuring it – it would tell me they maybe shouldn’t be building something until someone makes a decision over what problem they are solving and how they are to solve it.

On a related topic, I have some thoughts on how you measure product manager’s performance – there is a lot of overlap here with your ideas I think.
http://requirements.seilevel.com/blog/2006/01/measuring-product-manager-performance.html

Anyway, it’s a great topic.

Your technologies and those of your suppliers changes may impact your delivery dates, but the platform floats on top of the technology, and your products float on top of your platforms, so functionality should remain stable. This should give you stability at the UI, while everthing else is changing underneath it.

Excellent post.

Your opening statement is especially true: “Too often, product managers implement new features, functionality, or make other changes to a product without a true understanding of why these changes are being made.”

I think one of the reasons is that the discipline of Product Management in high-tech is relatively young. Whereas other disciplines such as Engineering and Sales are quite structured, Product Management is often far less so.

But I think this is changing for the better. I believe articles such as this play an important role in taking the practice of Product Management to the next level. Keep ‘em coming!

- Raj
Accompa – Affordable Requirements Tool for Product Managers

Just to add to your article – in real life it always does not work out. A typical case is in certain new markets where users are themselves not sure of what they want. Investing too much in trying to find the right solution that makes sense, may not be a worthwhile exercise. A way to deal with this situation is to work closely with engineers in coming up with quick prototypes and letting customers play with it till it is possible for all involved to measure the impact and applicable use cases. The key here is that there should be much less resource / cost investment – minimum QA. Once, the prototype and the features there in get validated, you have your next candidate to be the product (or a new product feature). This has always worked for me …