Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Product Management

Build the whole product

Freshness Warning
This blog post is over 1 year old. It's possible that the information you read below isn't current and the links no longer work.

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.

Recently Written

A Framework for Scaling product teams
Oct 9: The people, processes, and systems that make up a product organization change radically as you go through the stages of a company. This framework will guide that scaling.
My Networked Webcam Setup
Sep 25: A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features
Sep 4: Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks
Sep 2: The key to effective roadmapping? Different views for different needs.
Micromanaging and competence
Jul 2: Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system
Jun 24: A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes
May 14: Being a product manager means never having to say, "that's not my job."
Too Big To Fail
Apr 9: When a company piles resources on a new product idea, it doesn't have room to fail. But failing is an important part of innovation. If you can't let it fail, it can't succeed.

Older...

What I'm Reading