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
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/
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/
Am I alone in actually wanting a features checklist?
I know going in most people will try to insert superfluous "features" just to make their list longer than a competitor. However eventually their are tangible items you can use to compare. I'm not buying your brand, I want to know what I get for the money
What is particularly revealing is Ryan's confession about tracking and co-ordination challenges at 37 Signals:
"In some areas, it’s been really successful. I mean, there’s a lot of self-management happening at 37, but at the same time, what I noticed was that despite a lot of success with that, projects simply were not getting shipped."
"So, I was asking myself “What’s missing? Why isn’t this happening?” And I realized that what it really takes to ship product is coordination...And, if somebody doesn’t actually take care to schedule everybody’s time, so that the right people are available at the right time, with the right context, to work together and make all those things happen, it just doesn’t happen on its own."
We've been discussing the sort of culture we want at a new startup this week, and Jason Fried and DHH's opinions on tracking came up.
Jason in 2006 :
"Christopher: We never tracked time. Not even in the client days."
"Nollind, we don’t track time. Tracking time is a waste of time. Things either get done or they don’t. If they don’t, everyone knows about it."
In a recent interview with Fast Company :
"We don’t track things in that way. I don’t look at that. I don’t want to encourage that kind of work. I want to encourage quality work."
DHH in 'Refusing Administrative Minutiae' :
"No time-tracking, no tick tock, just clear expectations of what the client was going to get. It really opened my eyes to “you can refuse to do the shit you don’t want to do” way of running a business."
I'm actually sympathetic to creating a company culture which tries to reduce as much 'big brother bureaucracy' as possible, and assumed that 37 Signals had managed this successfully by hiring late, and hiring good.
However based on Ryan's comments I get the sense self-management went a little too far.
Still, they've managed to achieve some success and financial reward :)
To be clear, nobody tracks time, even for projects that are managed. The coordination I mentioned is about ensuring the right people are available to work together on the right things at the scale of days and weeks, not individual hours. Most of the hard work is making decisions about what to call 'done' versus where to keep iterating, and managing that over time so everyone experiences steady progress.