I started my career as a classically trained engineer spending the vast majority of my time designing and writing code. Over time, partly through necessity, and partly through curiosity, I took on more product management responsibilities. With the power came responsibility and, while it didn’t feel that good then, 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.
I suspect I fell into the same kinds of traps that a lot of technical people who have to, or want to, work on product do. I wanted to share a number of myths of unintuitive observations that may help aspiring product owners avoid some early mistakes.
“Why should I care,” you may ask yourself, “if I have no interest in product management?” Even if you never touch a roadmap or write a spec, you will spend the majority of your working hours building something that may or may not be a well-managed product. If you understand some of the key traps that people fall in, you can help course correct early and avoid the painful surprise two months later when you discover that nobody is using the product you built.
**
The hardest part about good product development is that it feels easy. To engineers, it surely seems easier than actually getting the code built – it’s not like to do product work, one needs to be good at math, learn several programming languages as well as most of Unix and the Shell, and a few dozen tools and frameworks to wit. Worse, everyone has ideas – often great ideas – and isn’t product work just writing down these ideas??
Another big reason these misconceptions exist is precisely because technology is so empowering. It feels that one can wish things into existence with a bunch of keystrokes and some electricity. It is also omnipresent – so why wouldn’t everyone just try my product, see how amazing it is, and continue using it forever??
Finally, I must blame 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, implying that more features is always better. Or look at any well-known roadmap and you’ll convince yourself that roadmaps basically list releases of features into the future.
I’m not advocating that we stop dreaming, give up on product management, or abandon helpful simplifications. But let’s do a better job separating the dream from reality that actually makes products successful.
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 are a manifestation of something much more fundamental for a product.
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 primarily want to have a great experience, and in second order don’t want to be hungry after dinner. One doesn’t create a restaurant simply by listing all the entrees that will be served. One thinks about the needs the restaurant will satisfy, and that cuts across the service, the ambiance, decor, the choice of cuisine, and only 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 be capable of (or might be, in the future). Just like ideas, features are cheap. They got cheaper since products moved to bits, because programming languages are more expressive and powerful than nails and wood. Maybe we just haven’t caught up with reality yet: just like we all think we are above-average drivers, we may be thinking that we are above-average feature creators, especially those of us who can also get these features built.
If a product is not a series of features, what it is? A better definition is:
A product 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.
Following this definition, to develop a product, rather than listing its features, you should:
- Start with the user (and the customer – who pays the bills – if they are not the same)
- Understand the user’s jobs and needs very well; better than they understand themselves. Don’t just write down what they tell you
- 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
As you can see, “features” aren’t mentioned until the fourth point. Even then, it’s an oblique connection, from “solutions” to “features”.
Does all this mean you should throw out your feature list? Certainly not. It’s important for competitive analysis, and some customers will go line-by-line and pick a product that seems to have “the most” capabilities. It’s also a helpful way to describe the surface area of the product. But if you find yourself listing features instead of understanding the user, their jobs or your value propositions, you’ve skipped some crucial steps.