3 ms·

This is really the classic features vs. benefits conversation. Don't build features, build benefits instead. I've spoken with lots of developers who swear that

This is really the classic features vs. benefits conversation. Don't build features, build benefits instead. I've spoken with lots of developers who swear that they understand this distinction, but most actually don't. You ask the question, "so what's this product going to do for [target customer]?" and they start spouting off features. It's interesting to hear about Ryan's light-bulb moment, because I had a similar epiphany a couple of years ago. In making that leap, what surprised me the most was just how invisible that distinction had previously been to me. Feature: Reminds you of your upcoming appointments Benefit: Never be late for an appointment

destraynor 14y ago
Succinct. The other piece he mentioned is "Products are also Services". Take Square, who released that Business in a Box thing: https://squareup.com/register/hardware/shop https://squareup.com/register/hardware/shop That comes from a fundamental understanding that Square are in the business of "Helping businesses charge money", they're not just in the "payment technology business". If they were, they'd stop many steps earlier in the process. They know where to "draw the line" http://insideintercom.io/where-to-draw-the-line/ http://insideintercom.io/where-to-draw-the-line/
digitalengineer 14y ago
This what good brands do as well: Chanel No5 sells a fragrance, but people buy feeling and smelling attractive. Nike sells sneakers and sportswear but people buy the hope and tools for better athletic performance. Source: http://www.risingabovethenoise.com/ http://www.risingabovethenoise.com/