Input metrics can be helpful to track progress toward long-term goals, but they can cause issues if not used carefully. They might make people act in ways you didn’t expect, limit creativity, and lead to micromanaging.

Read more »

Changing from "Customers" to "Partners" will give you a better perspective on internal product development.

Companies are using internal product platforms to speed up development, make user experiences consistent, reduce operational costs, and support various environments, including mobile. One of the key differences in product management of an internal platform is who your end users are. They adopt and use your product for different reasons than an external customer would.

It’s tempting to view the product managers and engineers using the platform as your customers. As product managers, we spend most of the time thinking about customers, so it’s natural for an internal product to think of fellow employees as their customers.

But the concept of a customer comes with assumptions and context that can slow your success as a platform team There’s a huge difference between an actual customer and these internal “customers.”

Read more »

"You have launched a new feature in your product. How do you measure the success of the feature?"

If you don’t know the answer to this before you build features, you’re probably building the wrong things.

You’re building features to solve problems. If you don’t know what success looks like, how did you decide on that feature at all?

Starting with features instead of problems is a tragically common problem among product managers. They may be building capabilities for problems their customers don’t have. They may be building the wrong solution for their customer problem. Or they may be building small, insignificant things that don’t have large impacts on their business or customers.

You have a hypothesis that creating this feature will generate a certain outcome. Was that outcome created? Was the hypothesis correct? Trying to figure out after the fact a way to measure success means that you weren’t focused on the outcome when you were creating the feature. The shipping of the feature itself was viewed as the goal. This isn’t a good way to build products.

Product teams should be discussing product outcomes. They should review their releases to see if the feature worked. Did it create the expected outcome? Why or why not? What experiments could you run (iterations) to learn if there are better ways to solve that problem?

There are some signs that your product teams are feature-focused instead of outcome-focused.

• Their OKRs, bonuses, and celebrations are mostly about whether they shipped instead of achieving an outcome for the customer or the business
• Discussion of outcomes and KPIs from the last release doesn’t happen during the planning process
• They don’t iterate on previous feature releases. Or if they do, the iterations are known in advance, instead of based on what they learned about what just shipped
• People talk about what feature is needed to increase sales instead of what problems you aren’t solving for customers

I like to manage with OKRs. This post describes how I use them, how I think about what’s important, and the tactics I use to execute using them. This isn’t a complete primer on OKRs. There are plenty of those on the internet and in books. I highly recommend Christina Wodtke’s Radical Focus if you want a detailed guide to OKRs. I’m writing this mostly so I can send it to my future teams when we’re implementing OKRs.

Read more »

A team inside a large company spent a year building a new product from scratch. They obsessed about every detail. They refined the giant vision down to a reasonable v1. They slipped the release date a couple times, but then celebrated shipping a working product.

Nine months later, they only had one customer. What went wrong?

One of the biggest oversights was that they were so focused on building the code that. Made up the product, they forgot about the rest of what makes a product work. Marketing first got involved when the product was almost done. Support didn’t have any tools to help customers and didn’t really understand the product.

But most importantly, this new product from a sales-driven company didn’t think they needed sales. Sales didn’t see the product before it launched. They didn’t have input into price models. No one told them what was different about the new product.

So sales sabotaged the new product. Probably not on purpose. There might not have been meetings where sales teams said, “let’s make sure no one buys the new product.” But when a prospective customer asked a sales person how they could buy the new product, sales always steered them away. Steered them toward the products they understood. The ones where they knew how to price it, demo it, where they knew the customer would be well supported.

“Why won’t sales let people buy this,” the product team lamented. But why would they? Sales had a new product dropped in their lap with no input, no context, and no warning. It’s not surprising they just kept doing what they normally did.

The product team thought they had a green field product. Build whatever you want, however you want. But they failed to think about the context they were operating in. They failed to keep the rest of the company involved while they built the product.

The result was something that sales didn’t know what to do with, marketing couldn’t explain to customers, support couldn’t operate, and finance couldn’t bill for. The team had only built the code, not the whole product.

The product was a failure from the start, the team just didn’t realize it yet.

Sometimes teams have trouble grasping how a leading indicator can drive outcome-based goals. How do I take an outcome I want to achieve and turn that into input metrics and then use those metrics to track progress toward my goal?

Imagine you want to lose weight, lower cholesterol, and become healthier over the next 6 months. You could set key results of "lose 40 pounds" and "drop cholesterol to 125" but the problem is that it’s hard to track that every week. If you do a bunch of things to try and accomplish this every week, it could be several weeks or months before you see any results.

Here’s where input metrics come into play. You know that to lose weight and improve your health, you need to exercise more and eat better. Doing those things will lead to the weight loss and other health improvements you’re after. So your input metrics might look like this (this is totally made up and you obviously should not use this as health advice):

• 30 minutes of cardio 4 times each week
• complete 2 pushups per day by the end of week 1, and double that every week
• have a salad for a meal 3 times per week
• only eat red meat once per week

These are things you can measure every single week, knowing that they’re advancing you toward your ultimate goals. By measuring these input metrics you can know if you;re likely on track for your outcome of losing weight and lowering your cholesterol. By adding those measurements as additional key results, you’ll have a well-rounded score card that gives you early insight into progress and measures the actual outcome you want to acheive.