Build it right to build the right thing
You can't build the right product if you can't build the product right.
I tweeted that this morning, in response to a Twitter-vibe that was flitting around. I'd like to follow it up here with a bit more meat.
The fundamental truth of successful software products is that they have to be built "right", or at least "right enough". And a software product organization today needs to know how to build things right.
There is an exception. If your "business strategy" is to build some piece of crap that isn't sustainable, make a big splash on the Internet, then be acquired by GoogBook for a zillion dollars, you don't have to be able to build it right. You're not building a product. You're dancing about trying to look really attractive, so someone will slip you enough shares to let you go live somewhere warm and dine on tea and oranges that come all the way from China. That's cool. But it's not developing a product.
When we develop a product, of course we want to build the "right" product. The right product is a product that does something much like the idea we originally had, except that instead of what we originally thought, it has what customers actually want, need, respond to, desire, and love. No one -- at least no one I have ever met -- knows up front what people will love. We get a successful product out there by getting something out there, as soon as possible. Then we listen to the market, which tells us mostly what they don't like, and maybe a few words about what they do like. Then we change the product -- or, as Lean Startup would have it -- we pivot.
Our initial product is almost certainly not the "right product". If we do not build the product "right enough", we won't get it to market quickly, and when the market speaks, we can't change it quickly enough to respond. And someone else will respond instead. They build "our" product and we're left out in the rain, trying to find a nice cardboard box to live in. Or, worse, working for the man in some high-paid boring programming job.
Don't wind up working for the man in some high-paid but boring programming job. Build the product right. Repeat until it's the right product.
What does it mean to build the product right? Make it well-crafted but not over-crafted. Make the design flexible but not awesomely general. Make the code clean and clear but not a literate masterpiece. Make it free of defects but don't test for centuries to get there.
In short, the product needs to be built using the software development style that Agilists have been talking about for nearly twenty years: automated acceptance tests; test-driven development; refactoring; continuous integration. All that stuff. And it needs to be done by people who really know how to do it, when to do it, and how to do it quickly and well.
When you can build software that way, you can build any product. When you can build any product, you can build the right product. What that really means is that when "they" come back from having their butts kicked in the market and say "what we really need is Y not X", you can say "sure, no problem" and really mean it.
You rip out the stuff for X, which is all conveniently in one place because that's how you roll, and you put in the stuff for Y, which you can do quickly and well because you know how to build it with a good design, solid tests, and without leaving the program so twisted that when they come back for Z instead of Y, you're out of luck. Because they will come back for Z and W and with any luck at all for Vau and Gimel and Alpha as well. And you'll put them all in, nice and neat, because you know how to build things right.
If you can build the thing right, you can live long enough to find the right thing. I think that's your best shot.