It's funny how the Self-Help section has invaded the Business shelves. The reason is simple: if you take a bunch of chimpanzee-like primates originally evolved for the tribal hunter-gatherer lifestyle and a diet of nuts, berries, and roast beast, and future-shock them into a postmodern global village running on intricate financial flows and constantly changing business practices ... well, if you expect them to cope, they're going to need a little help.
"If you build it, they will come" sounds good, but the real world isn't a movie. I meet a lot of inventors who are completely clueless about how to take their product to market. Fortunately, thanks to some brilliant thinking that has emerged in the last twenty years, innovation has become as much a science as it is an art.
Michael Gerber reminds us: don't just work IN your business. Work ON your business. Your business builds product, sure, but who builds the business? You do. As an entrepreneur, the business IS your product.
Once you've got to product/market fit, then you're ready to raise money.
Raising money is itself a full-time job. The world of venture sounds glamorous and alluring, but in reality, venture capitalists work in offices and report up the chain to their partners and investors just like anyone else. In fact, they have to raise funds just like you do.
During the process of fundraising, I can guarantee one of the questions you'll get asked is What's Your Exit Strategy?: 7 Ways to Maximize the Value of the Business You've Built. Better have an answer. And that answer's not just for the investors. It's for you, too. Some people, when they walk into a room, the first thing they do is look for the exits. When you walk into a company, look for your exits. Of course, you shouldn't let the lure of an outcome distract you from building your ideal company, a firm that builds your ideal products, that you'd love to work at every day.
A friend of mine, in the middle of her MBA, exclaimed: now I know how the world works! And it's true: business is a big part of the modern world, so knowing how business works is a big part of knowing how the world works.
Business is the sort of field where the big picture can only be glimpsed out of the corner of your eye. In the same way that the best childrens' movies are made to be enjoyable by adults on a deeper level, books like What the CEO Wants You to Know : How Your Company Really Works can be understood best by folks who have the right concepts in their heads.
The Portable MBA, 4th Edition offers those concepts: the mise en place, as it were, of business. It's what Heinlein would have wanted: every man and woman should know how to read a balance sheet, launch a product line, explain monetary and fiscal policy, hire someone, fire someone, record a ledger in a double-entry account, choose between debt and equity financing, know when to lower prices, and know when to raise 'em.
In Dilbert-land, the verb "manage" means "control". As in "I need to go to the bathroom, but my manager won't let me."
In the real world, "manage" means "cope". As in "I'm responsible for so many projects, I'm barely managing to keep my head above water." Welcome to the cat-herding profession. Meow.
I recommend two books on how to operate the manager-employee relationship. Remember, that relationship is artificial: we primates are hardwired to deal with parents, siblings, aunts, uncles, children, servants, village chieftains, kings, queens, and priests. We are not born knowing how to deal with "managers" or "direct reports".
You may say that a lot of what's in these books is common sense, but even so, most of the corporate world doesn't know this stuff: if they did, they wouldn't put their programmers in cubicles. (Microsoft doesn't.) Think of it as a competitive advantage: your startup can arbitrage the gap between your knowledge and their ignorance.
What's the difference between a programmer and a software engineer? A programmer hopes for the best. A software engineer plans for the worst. A programmer loves writing code. A software engineer loves not writing code. A programmer knows how to do things. A software engineer knows how things are done.
O'Reilly's blue books are great for programmers. But programming is to software engineering what your home kitchen is to a restaurant.
Let's keep going with the analogy. A restaurant manager needs to know about reservation systems (can we seat a table of eight at 7 o'clock?), produce suppliers (if tomatoes are in season next week, where can I get fresh mozzarella?), staff scheduling and shift rotations (who's going to work this Valentine's Day?) ... the list goes on.
In fact, her job is to make it possible for the cooks to focus on making the food, for the waiters to focus on keeping customers happy, and for the bartender to focus on the drinks.
In the same way, a software project manager's job is to make it possible for the genius programmers to focus on writing code. To do that, she has to meet with customers, gather use cases, turn them into requirements, estimate development effort, prioritize features, build a risk model, develop a staged delivery schedule, interface with QA, report to management, organize dependencies, coordinate integration, and run change control.
At work, a restaurant manager may never cook a single meal. A software project manager may never write a line of code.
