On Releasing Early
Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)
My attention was grabbed by one of the comments in particular, from Trevor Lohrbeer. He says, in part:
Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).
Which, it should not surprise you to know, reminds me of a story.
And here’s the story.
I worked on a freelance basis, moonlighting long ago, with a fellow named Bill who had a really neat vertical market application in development. You know the kind. It was one of those database applications that aren’t particularly innovative in a technical sense but did a fantastic job of fitting a specific organizational need. I seem to recall the application was pretty decent to begin with. It basically worked, but Bill had a few ideas for improvement before hitting the market. And that’s where I came in.
The main thing was that each screen–this was a big Windows application–had a zillion data entry fields and Bill was thinking of having a kind of all-singing, all-dancing database table that linked every field on the dialog window to its corresponding location in the database. That way we could have one function or method that worked conveniently for all dialogs, to save data when the user hit OK and to bring it up again when needed.
Kind of. It was a pain to implement, with (as you can imagine) tons of special cases. This field gets saved normally but it’s a phone number. That one has special validation. I’m sure you know what I’m talking about if you’ve ever done user interfaces for database-intensive software.
And we’d get a version done, and I’d be away on my day job for a while, and Bill would report back that he’d met with one or two prospective customers for this product, and they had some more suggested changes. So we’d go implement the changes, and in a couple of weeks Bill would meet again with the same prospects, or different ones, and there’d be another round of stuff to change.
You can see where this ends up.
More like this?
You totally want to read more implementing software projects that actually get done, and you will, if you get onto my keep-in-touch mailing list. You get a complete mailing about once a month, with articles and links and special offers that help you do your job, as well a quick note every week or so with a surprise. Do you need more stress? No? Then this is for you.
I don’t think this application ever got done, not in the sense of anyone ever paying money for it and using it in their organization.
There were probably are a few reasons for this happening. First thing, I think Bill was truly a perfectionist at heart. He just hated the idea of producing something that’s less than ideal. Hated to leave things undone or done poorly.
Another reason was probably a bit of emotional freakout about having the project done, and possibly simply failing in the market. I think people get like that. As long as you’re still working on the big new project, you haven’t failed. When you say it’s done and you send it out into the world,you could lose. Being in the midst of losing is rough, but having lost is really hard for people to accept.
Huh. I wonder if that’s an American thing.
It reminds me of the Crazy Horse memorial. The construction managers there are in love with the process, but they don’t seem that interested in actually finishing the thing. As the widow of the original sculptor said to the reporter after the project had already been going on for sixty years:
To picture it 60 years from now, I’d like to think we had the first building, at least, for the university so that we’d actually have some students here… I’d like to see the horse’s head finished and polishing Crazy Horse’s body and doing all of the finish work on it.
What? A hundred and twenty years of development and she thinks it should be a little more than half done? I mean dude. Talk about missing your window.
I read the article again and realized… of course. The statue will never get finished because the sculptors are being paid to keep working on it in the form of admission fees to watch the work being done. As usual, people do what the incentives tell them to do. The incentive is to not finish.
Let me ask about your incentives. Are you getting a lot out of working on the project? Or does your payback come when it’s done? How will you feel when it’s finished? Relieved? Happy? Anxious? Or bored with nothing to do? It makes a difference.
Anyway, back to Bill.
Another reason for the failure, something that Trevor Lohrbeer picked out very nicely, is that Bill was getting terrible feedback. He was asking people who hadn’t bought the software, and perhaps never would!
Bottom line, no, these people (even though they were in Bill’s very specific vertical market) had none of that proverbial skin in the game. They could say absolutely anything and it wouldn’t matter, because it only affected a product they weren’t actually buying.
I’m having this problem right now, in fact. I want to make some mid-course corrections on my new Startup Booster infoproduct line, but most of the people who volunteered to comment on the preview editions aren’t the intended customers. Their opinions are interesting and important, but it’s not the same as a real customer saying, “I’m paying my money for this thing and I want it to be like that.”
In the Agile realm we divide the population of stakeholders into chickens and pigs, from the punch line of the joke that says a chicken is involved in a ham and eggs breakfast, but the pig is committed. If you’re a chicken, it means the costs and pains of carrying out the project are not on you personally. If you’re a pig, it means you are personally the one making stuff work–not hoping, not observing, not planning for it.
It’s not the same thing, but it’s parallel, to the concept of bringing in paying customers early. A paying customer is like a pig–he’s at least taken on part of the actual monetary cost of getting the project done. A prospective customer, or an idly interested bystander, doesn’t have the same investment. She’s a chicken.
One more test
“But wait!’ you might be saying. “I don’t have any paying customers at all! I have to listen to my prospects because that’s all I’ve got!”
Then I’m afraid I have to ask in reply, “Do you know you really have a product there?” Because if you don’t have any customers, your product just might be… a hobby.
What’s your product? Who’s using it?
Let’s discuss in the comments.
Tweets that mention On Releasing Early « Critical Results -- Topsy.com
January 26, 2010 @ 12:04 am
[…] This post was mentioned on Twitter by Mark W. Schumann, Mark W. Schumann and Kevin E. Schlabach, Agile Topic. Agile Topic said: Agile #Agile: On Releasing Early… http://bit.ly/7W0qvq […]
January 26, 2010 @ 6:50 pm
Mark, You say: “Being in the midst of losing is rough, but having lost is really hard for people to accept.”
So true, and a point, coincidentally, you made in a comment to my blog today.
Love the Crazy Horse story. Compared to them, I’m running way ahead of schedule!
Mark W. Schumann
January 27, 2010 @ 11:58 am
What makes you think it was a coincidence?
I was raised on mathematics. My people notice patterns and then see them everywhere. 🙂