Ask Yourself: Should I Build This?
A couple of years ago, I heard Guy Kawasaki talk about how the thing that defined Silicon Valley was its “what the hell, let’s build it” attitude. It took me a while to get it, but I came round to understanding his point: get moving, build something, figure out who cares about what you’ve built, and then evolve the product. It’s good advice, to a point.
However, there comes a point where the market is so saturated that you start to do stupid things. I got a great example of one such thing in the email today:
It’s called, creatively, “Barbecue”. It’s from San Francisco-based Equinux. I’m pretty sure it’s one of the signs of the apocalypse.
Now, I’m sure there will be people that will purchase this application; it’s cute, gimmicky, and it will doubtlessly keep someone entertained for at least three minutes. But the breathless copy proclaiming this application’s unparalleled awesomeness is simply over the top:
Serve steaks to your friends on Facebook, share kebabs and ribs on Twitter or via Mail. Barbecue on the iPhone:
- Photo realistic images that make your mouth water
- Top notch graphics to get a real bbq experience
- Real sound effects to bring the thrill to the grill
Seriously? We spent countless billions building silicon foundries, a revolutionary mobile operating system, and the associated expertise to simulate the experience of BBQ? I could do the real thing for a couple of bucks, with the obvious bonus that I’d actually get to eat the results. I know somewhere, a software developer is clucking their tongue and pontificating on those silly marketing people. But, last I checked, the marketing people didn’t build this application.
I worry that developers have lost some serious perspective in their bid for fame and fortune. Just because it makes money, doesn’t mean it’s useful. Now, I’m not suggesting that we toss out our enthusiasm for trying new, unproven things; however, I am suggesting that developers need to start considering whether or not their software offers any socially redeeming value.
Developers need to start not only asking themselves “can we build it?”, but also “should we build it?”
I like the observation but as a rule I leave questions of “should” to the realm of spiritual faith. My world revolves around decisions, risks and consequences.
From that point of view, what you’re talking about simply comes down to risk. Doing up-front market research – understanding who will buy your product, how many of them there are and how much they’ll be willing to pay – can reduce your risk of an expensive flop.
But market research has its own consequences – the time and expense required to do the “proper” market research would have killed countless successful ventures before they even got off the ground. Every venture has a different set of risks and circumstances, whether they are the risk of missing out on a short opportunity window or the risk of spending $300M developing a product that eventually almost nobody buys. A business plan (whether it’s a bound volume locked in a repository with numbered copies or just rattling around inside your head) identifies those risks so you can focus your attention on the most important ones.
The same of course applies to engineering. People talk all the time about “engineering best practices” (well I do at least) but what does that mean to the small startup business? They just want to get their product out to market in the fastest, cheapest way so they can start making money. They can’t even afford to spell “best practices”.
Just as in business, it comes down to preparation and managing your risks. If you’re VC-funded and time-to-market is your critical element, waiting until near the end of the product development to start thinking about testing is not managing your risks. While such things as a document repository and an integrated change control system would be a waste of time at this stage, failing to have a QA strategy that starts with a review of the project requirements is going to cost you later on.
To increase your chances of being successful, build a balanced approach to risk: Focus on the real risks to your business and ensure your planning (business planning, development planning, QA planning, …) addresses the most critical ones. Then get busy and get it done.