Product Development Misconceptions

I am blessed to have started as a hard-core developer (with all the advantages and all the biases accompanying such a role) and then, partly through necessity, and partly through curiosity, to have started dabbling in product, only for this dabbling to have escalated into true product ownership. With the power came responsibility and I am lucky to have failed spectacularly in my first real product assignment, so much so that the many learnings of good product development have been etched in my memory for ever. Some errors I made several times (each time the problem looked just different enough to have fooled me), which helped me internalize what makes good product development even more.

The hardest part about good product development is that unlike the resulting product, it is unintuitive. It's particularly treacherous for those who have good (and smart) ideas, or those who lack experience getting stuff built, but feel that they can conceptualize what it takes to get stuff built ("I haven't built anything, but I could probably do it if I put my mind to it, it doesn't look that hard"). Because that's where the biggest impedance mismatch occurs between our confidence of our intuitions and reality.

I encounter one or more of these misconceptions on a weekly basis: talking to nontechnical managers, talking to technical non-managers, talking to venture capitalists (who are the worst violators!),  CEOs, users, stakeholders, you name it. I think the biggest factor contributing to these myths persisting is the very fact that technology is so empowering. Unlike building, say, a real bridge or automobile, with technology you can wish so much into being with a bunch of keystrokes and some electricity. And this magic (it's hard to find a better word for it) makes us forget reality.

The other reason why these misconceptions are alive and well is the continuing reinforcement of poor analogies and superficial descriptions of products. Go to many Enterprise products' websites and I bet you there is a page that lists or describes or compares features (and implies that more features is better). So we end up basically equating products with the features they offer. Or look at Intel's microprocessor roadmap and you'll be sure that roadmaps basically list releases into the future. As developers, we think about how long it took us to implement a feature, and so this (I'll argue) first-order consequence is often basically all that remains.

In all these, "basically" is the killer word. These things are not basically equivalent. They are equivalent at a rather simplistic level, and that superficial equality contributed to many challenges doing product development.

I'm not advocating for us to stop dreaming. But let's do a better job separating the dream from reality (such as a comfortable bed and enough sleep, to stick with the metaphor) that is required to allow us to dream in the first place.


Reality #1: Product ≠ a series of features

It's tempting to describe a product by listing its features. But a product is not just a sum of its features. In fact, I'd argue that a features is a manifestation of something much more fundamental (and important):

A feature is a vehicle delivering value to a user. 

Focusing on features when developing a product is like describing all the different entrees when developing a restaurant. Sure, the entrees are important, but focusing on just the entrees risks missing the fact that behind the entrees are diners who want to have a great experience and get some nutrition. And you don't develop a restaurant by listing all the entrees that will be served. You think about the needs you want to satisfy, and from that you derive the ambiance, the decor, the overall cuisine, and ultimately the food.

Feature-centric product development carries a deadly risk: that you equate product success with the richness, or sophistication, or multitude, or cleverness of its features. At the end of the day the product needs to deliver value to its users. If you get buried in feature lists and forget who the user is, what she needs and wants, how she thinks and behaves and what she expects, your features will be nothing but a useless laundry list. But you'll be patting yourself on the back for a job well done.

It's easy to think of features. We all do it when we use products, when we critique them, when we imagine what products could do. Just like ideas, features are cheap. Features didn't use to be so abundant (and cheap), but I believe that this is because we simply used products less in the past, and the products used to be physical (with physical constraints which make it harder to think of features) and so you didn't have everyone and their mother come up with features for all sorts of products. And so maybe we just haven't caught up with reality yet, and just like we all think we are above-average drivers, we all think we are above-average feature creators. This is particularly hazardous if you're technical, because then you're likely smart and you can also build the feature, which makes you think you are a particularly good feature creator.

If a product is not a series of features, what it is? Here is a better (not perfect) definition: A product is a creation that offers a certain (usually small) set of value propositions to a certain (usually well-defined) set of users. The value propositions satisfy the users' needs or wants, address their pains or make their jobs easier. To develop a product, rather than listing its features:

  • Start with the user (and the customer, if you want to be able to capture the value you're creating – the two are not always the same)
  • Understand the user incredibly well
  • Define the value propositions that align with what the user needs, and that are accessible to the user
  • Define how you're going to provide this value (only now is this beginning to look like a "feature", even though it's more like "implementation hint")


More to come... in the next installment, I cover another critical misconception. It turns out that a roadmap is not a list of releases. Stay tuned.