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.)
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.
It’s Friday, which is usually my day for the big-picture, deep-thinking, philosophically confusing kind of blog post. This time, however, I’m going totally commercial.
I’m excited about this!
A couple of very different items that I’ve been working on for a long time have finally reached a state of substantial completion. I’m ready to get them into a market-friendly state that will enable me to help more people, in a very sustainable way that everyone can afford.
The first thing
The first thing is a Windows application that was custom-made for a local nonprofit organization. They’ve implemented a very successful environmental health program (one of many) that works with families to identify home health and safety hazards, remediate those hazards in a cost-effective manner, and educate the family on ways to maintain the healthy state of the home. There’s a lot of “workflow” involved, and the reporting issues are fairly intense because of federal grant requirements, and it’s further complicated by the need to support an offline distributed database because the inspector with his Tablet PC doesn’t have remote access in the field.
The new application has been in a solidly usable beta state for about six months. Now we’re calling 1.0 done!
The next step
So consider this a pre-release announcement. If you’re working with HUD Healthy Homes or any similar program, and manual recordkeeping is making your quarterly reports a nightmare, or if you just want a better way to schedule all those inspections and followups… we should totally talk. Get in touch with me now and we can arrange a preview.
The other thing
The other thing, which I’ve been talking about on Twitter a lot recently, is my new Startup Booster series for entrepreneurs whose software projects do not yet suck, but might! If you’re starting a company, and particularly if it’s not a software company, the last thing you want is a software project that costs too much, takes forever, and doesn’t solve the problem you had in the first place.
Isn’t it hard enough to get your idea off the ground? The software part of your strategic plan has to help, not get in the way. That’s why I’m building the Startup Booster. It’s a series of super-accessible information products that show you a really clear path to making stuff work even if you aren’t a software person yourself.
Right now, I’m putting the finishing touches on the first module, Buy or Build? It addresses the first and most important question that a lot of entrepreneurs miss: “Do I need to do a software project at all?” In it, I show you a really simple and thorough eight-step process (with a flowchart!) to help you decide whether to buy an existing package, get set to develop something custom, or skip the whole thing.
That’s the perfect implementation of my favorite rule of thumb: the only bug-free program is the one you don’t have to create to begin with.
Here’s what you get
The first module, Buy or Build? delivers a PDF and an MP3. The PDF includes an overview of the whole process, the aforementioned flowchart, and a super-simple workbook that you can write in as you go along. The MP3 is half an hour of my soothing voice, giving you background on the buy/build decision and explaining all the steps with real examples and a few bigger insights.
Here’s when you get it
At this moment, Buy or Build? is in preview. You can buy it at a special discount price of $17 if you’re on my free keep-in-touch eZine list. Otherwise, you have to wait until next Wednesday to join in the fun.
Of course if you now buy the preview, which is honestly kind of rough around the edges, you’ll get the tidied-up finished version for free next Wednesday. Like duh.
The rest of the series
But wait! There’s more! Future Startup Booster installments will help with topics like these. (Not all will be separate modules though.)
Can you do the software project yourself? Is that so crazy?
Figuring out what kind of help you need… how to get it… how to manage it… and when to fire people.
Is Open Source or Free Software right for you?
Deciding on a platform (e.g. Mac OS X, Windows, Web) and tool set.
How to know when your contractor is snowing you.
Protocols for problem-solving.
Measuring return on investment.
Can you turn your project investment into a profitable product of its own?
When to upgrade.
I haven’t worked out all the pricing, but each module will be pretty similar to the first in terms of content and bulk: a half hour of audio, a workbook, an overview, and a visual aid. There will be a really good no-regrets bundle price if you decide to get the whole series. (By “no regrets” I mean the bundle price is discounted by what you’ve already paid for individual modules, so you won’t have to go “Dang! I should have waited for the bundle!”)
Next up:
I’ve already started on the installment that addresses getting help with your custom software project. I’m hoping to get that preview out to friends as early as next Monday and releasing it to the public in mid-February. This is an ongoing process, with new content at least every month or so.
So there you go.
You can get on the keep-in-touch list right now and order the preview of Buy or Build? at a pretty cheap price with the free update, or you can hang around until Wednesday and pay a bit more for the flowered-up product.
Up to you though. I really hope you decide to check this stuff out, because if you’re trying to get a startup going this stuff can really cut out a lot of the cost, hassle, and stress of software projects gone bad–and so much more affordably than figuring it out with a consultant!
I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.
Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)
On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.
Right now I’m finishing an infoproduct. It’s a handbook, with audio and flowchart, for software-dependent startup entrepreneurs who don’t have a grip on the “buy vs. build” decision. In short, I’m creating this thing to help you figure out whether you should buy (or download!) some pre-existing software to support your business, or whether you’ll be better off doing a software development project even if you personally can’t get past “Hello World.”
It’s going to be a series, naturally, and the next segments will show you how to get started with that development project if you’ve decided it’s really necessary.
Over the past few years, I’ve studied what it means to market and sell professional services like mine. Honestly, I’m in a weird place with that, because I’m a huge geek (and still speak FORTRAN fluently) but a lot of what I do is what is sometimes, probably condescendingly, called the “soft skills” realm.
That makes it hard to answer that inevitable question, “So, what do you do?”
I used to reply with variations that started, “I’m a software developer” or “I’m a Unix guy.” But that doesn’t quite tickle the people who really need me.
In my experience, most software-dependent startups fail because they never actually finish the software. It’s really that simple.
I’m trying to figure out how I feel about Jeff Atwood’s recent proclamation: “Version 1 Sucks, But Ship It Anyway.” As a connoisseur of Software Projects That Suck, I get Atwood’s point: you don’t really know what’s wrong with Version 1.0 until some real customers get to play with it and let you know what they think. I’ve often spent days or weeks perfecting a feature that nobody cared about! Why not save that time by getting feedback first?
Am I right that some of the hardest programming is when you’re modifying some existing code that is not quite well enough documented?
I’m looking at this scientific application, in which I struggled with all the code that leads up to drawing some graphs, and the graphs are still obviously wrong. Between me and success I have a few layers of trigonometry and matrix algebra.
Obviously the physicist who wrote the original code had some intention for the methods with names like get_x() and InverseTransform(). And I’ve gotten through about half of this stuff with revelations like, “Oh, this converts the photo grid coordinates into screen coordinates!” or “I can cut this scaling out entirely because I already have a transformation matrix on the Graphics context.”
I blogged a few times recently about ways to make Acess databases do kind of what you want when you’re programming with .NET. There was this one about multiple JOIN syntax. Then this one about “parameter” errors. And finally this one about weird column names. Yuck!
A while back, I was led to Jason Cohen’s blog post on not trying to look like a big company when you’re not. Jason makes a good point, that when Lockheed Martin is ready to order 1000 copies of new software they probably won’t buy it from a small company anyway. That’s often true. But I think there’s a more important reason to knock off the high-falutin’ corporate image thing.