2013-04-23

Co.Labs

When Not To Think Like An Engineer

Building an independent software product to solve your own problems might make you a more efficient worker—but try to monetize your product publicly and you may wish you had chosen someone else's headache, not your own.



Engineer thinking can be a double-edged sword for entrepreneurial developers. To survive the startup process, you need to build an application that solves a problem you truly care about. But to really care about a problem usually means it has to be your problem. Gentry Underwood, whose Mailbox app was just acquired by Dropbox, says this creates something of a lopsided software market and a whole host of missed opportunities. Teased from our extended interview with Underwood, which will be published on Friday, April 26:

Startups are so hard. They ask so much of you and they ask you to ask so much of your team. If one day you're asking your team to kill themselves because you're going to change the world by creating mass crowd sources to end injustice, and the next day you're actually telling them that all that hard work is now going to serve people $.50 off their next latte, then you're going to have a hard time appealing to [employees'] passion in the long run. I can only speak out of personal experience and maybe for some people [for whom] this isn't the case, but startups ask almost everything of you. They are entirely consuming. If you don't deeply care about and deeply believe in the thing that you're trying to do, the things, the problem that you're trying to solve, I don't know how you can sustain the pain and the energy requirements—to actually go from failure to eventually finding something that approximates success.

If you can imagine before you're building all your prototypes, you're working through a design process to be very clear: What is the problem that you're trying to solve? Who has that problem? How big of a problem it is? How much they're willing to pay for the solution, so to speak in some way, shape, or form? In other words, how painful is it to them? What is it that if we create it, it's going to solve this specific problem?

There's zillions of similar products for people that sit at their desk all day coding on 27-inch monitors, because that's everybody building for themselves. Often in a startup, the problem is deeply felt by the founder—that's an easy way to tap that same kind of empathy. You don't build such empathy skills if the pain is already yours. Either one works: If you're good at stepping into somebody else's shoes, you can often find a lot of other problems that other developers don't have. Then you have an advantage of finding a market that's not necessarily served.

There’s a dearth of software in areas that probably seem a bit far afield from hacking, like, say fashion design or construction. Sometimes it's better to think like an ethnographer—or maybe a therapist—and try to tackle problems that comparable engineering teams simply can't relate to.


Want to hear more about how engineers think? Check out this longer story we're tracking: How To Think Like An Engineer.

[Image: Flickr user Ian Sane]




Add New Comment

1 Comments

  • herbys

    This is silly. Thinking like an engineer doesn't mean "thinking inside the box" or forgetting about other people's requirements. It means using reason and science to make the product fit for its purpose, and any smart engineer means it's purpose is generally not to solve a problem but to produce an end benefit, which may include solving the problem and it may include other things (such as marketability). The article should be titled "don't act like a dumb, inexperienced engineer".