Forgive me Marty Cagan, for I have sinned.

I’m ashamed to admit it, but at one time in my early career, I was responsible for managing a product like a feature factory.

Not sure what that is? A feature factory mindlessly cranks out features like a production line, hoping the next one will change their fortunes.

And I did it. A lot. But not anymore.

In the attempt to redeem myself, I thought I’d share a few frameworks that can help you, your team or someone you know beat the trap of becoming a Feature Factory PM.

Outcomes over Outputs

Feature Factory PMs fall into one of two camps:

No measurement

Measure the wrong thing

The worst culprits of the first camp, that I’ve experienced, are small B2B companies adding features to win sales contracts. And oh boy, is that a bad place to be.

Features become a sales strategy. Success is measured in winning contracts from those features. Your product becomes a bloated mess. And for you, it can create a very non intentional mindset to product management. You might start saying things like, “Some things you just can’t measure.”

Bullshit. You’re better than that. Get yourself over to camp two — but pack light. You won’t be staying long.

Camp two is usually disconnected from the business, either because they’re measuring non-business metrics like story points and velocity, or they simply aren’t aligned to business strategy.

They might measure…

Feature metrics: Performance of a feature (How many people are using it? Is it quicker or easier for a customer to do X now than it was before?)

Product metrics: Performance of specific product objectives (Because of feature X, more people are using functionality Y)

Team metrics : How many story points/features were launched at the end of the month/quarter? (I put this in for dramatic effect; this will only lead to — at best — success theatre, and at worse, the wrong behaviours from all parties)

This might seem like a very logical way to measure, but in reality these measures tell us very little about the business impact of all the work we’ve done.

A more business centric way to build and manage a product is by measuring our efforts in terms of outcomes, not output.

When we measure outcome, we measure the impact the new features had on the activity of the users AND the success of the company. When we measure output, we use features; when we measure outcome, we use OKRs.

If you haven’t heard of Google’s OKR framework I highly recommend you use it. It will give you a way to clearly state the what you are trying to achieve and how you will measure it. There are a multitude of great resources out to get you started, but I rather like Radical Focus by Christina Wodtke

But Hold on though, we already use OKRs.

You may already use this framework, but are you using it right?

Perhaps you do measure those product metrics via OKRs but are you measuring the business impact?

Here’s a fictional example below.

The team are working on a sexy existing functionality called feature X, which is a secondary feature in this new product. As it’s a new feature, they want to make sure it’s being used, so they are measuring product metrics and have an OKR set against it.

However, the business’s real objective is to increase their activation ratio. This is key — once activated users stick around with the product, retention is good.

Now our fictitious team could nail their product metrics, but could they succeed? If their metrics aren’t measured against the business objective, how would they know? What if adding just one of the features hit the business goals and the rest were diminishing returns? Without adherence to (and observation of) the business objective, we run the risk of building expensive features without return.

Make sure the OKRs align to business objective.

Now, there is a caveat to this. If you work in a large product company, your team might be many levels removed from the business objective. Usually this is achieved with cascading OKRs. Make sure you and your team are aware of the business objective and are still measuring it.

Discovering the right things to build

Feature Factory PMs tend to focus on the pace of feature delivery. They pride themselves on producing many features, without acknowledgment of the metrics they should be moving. They feel like it’s their responsibility to know everything, or least give the impression they do, but rarely invest time to explore the problem space. They just keep on building; because to them (or their company) it’s a bigger sin to not have developers building things than it is to have them discovering the right things to build.

Using a discovery framework like the Product Kata by Melissa Perri, will help you structure your approach to achieving the business objective, avoid poor ROI and better serve your customers.

How does it work?

Understand where you are (the current condition),

where you want to be (target condition),

whats stopping you from making progress towards it (obstacle),

whats your next step,

what do think will happen (expected),

what did you learn.

Here’s an example:

Consider this as the current condition — 85% of trial users don’t complete key activation steps.

We don’t know why yet, but we do know that we need to achieve a rate of at least 50% to have a healthy trial to subscribing rate and then retention rate thereafter.

It is here the Kata gives us a simple framework to progress through what we don’t know to discover potential solutions, then to communicate the findings and progress.

In this example below, each row might be a week or shorter depending on the problem space.