Last week Trinity Ventures had a CEO leadership dinner, which included a really great talk by Dr. Deborah Gruenfeld, Professor of Organizational Behavior at the Stanford Graduate School of Business.

Dr. Gruenfeld's talk was titled, "Acting with Power". She explained how behavioral cues affect perceived levels of power.

• You can demonstrate authority when communicating with someone through body language. For example, expanding your body to take up as much space as possible, making direct eye contact, and speaking slowly.
• Even if you are in a situation with power, there might be times you want to "play low" in order to get what you want. You bring yourself down to the level of the other person. 

There was some role playing, including a situation where someone played a manager in need of work and someone else played the assistant. By not calling the assistant by name, by not looking them in the eye, by not even waiting for a response before storming off, the manager could assert power over the assistant and get stuff done.

Dr. Gruenfeld teaches this stuff to business school students at Stanford. So I left with one big question:

Should business school students be taught how to act with power, before they have earned it?

I was never formally taught how to communicate with people, regardless of power level. I learned from watching my dad, through my managers at Apple, through trial and error. I still don't claim to be great at it, but I learn more each time I speak. If I talk to a customer at my dad's restaurant, a teller at a bank, or a bouncer at a Las Vegas club, I act differently to try to get what I want.

It seems wrong to me that business school students are being taught how to act in situations they have never been in, how to assert their power over people, perhaps before they even have any.

Silicon Valley startups have a bias against business school graduates. As engineers, we like to think that great innovation means coming up with interesting ideas and actually building them. Young business school students sometimes come off too strong, too cocky. Young product managers talk down to engineers. Could classes like this one be causing that?

Business school should stick to teaching the mechanics of running a successful business as much as possible, and leave the psychology out of it. The interpersonal part of running a company is best learned organically, with experience.

Simply teaching people how to assert power over people and then sending them off into the real world seems a lot like the Stanford Prison Experiment.

You should follow me on Twitter here.

I had a very frustrating conversation with someone a few weeks ago. He asked me how Posterous could compete in the blogging space given Google's Blogger has more users, money, and people.

I responded: we have the best team of engineers and designers imaginable. We will win because we are small and awesome. Microsoft throws 10x as many people at music players, phones, and computers. And they aren't winning there. If team size always won, there wouldn't be startups.

He then asked me about features. Other platforms have our features. Were we the first to do video posting by email?

No, we weren't the first with our feature set, but we think we did it best. Look at the iPhone: little of what the iPhone does is actually new. But Apple did it right, so it actually works well. If you compared the first iPhone to a Blackberry for features, the iPhone lost.

I asked this person directly: do you have an iPhone? Nope. Do you use a Mac or a PC? PC. There you go. You don't get it. Until you use an iPhone, a Mac, drive a BMW or Audi, you don't even realize how great the experience can be or how much it can drive the success of a product.

When I was at Apple, I learned that they don't throw more people at hard problems. They hire the best.

And they don't measure products by what they do, but by how well they do them. You won't find a matrix where Apple compares their product to a competitor by feature. They measure products by the experience.

My co-contributors to 8020startup Sachin, Evan and Andrew have each given their perspectives on striking the right balance between getting the product out the door and getting it right as far as bugs are concerned. But I want to discuss bugs from a different perspective, namely, the psychological impact bugs have on the entrepreneurs and employees of a startup. 

Bugs don't just affect customers, they affect the product creators as well, especially at small startups. Entrepreneurs are parents and startups are their children. Hence, startups are no day job. You are breathing life into something which previously did not exist and that takes 24/7 dedication. True entrepreneurs don't go home at the end of the day and say to themselves "Wow, that latest version of our software I shipped today was complete crap. Glad that's over." This means that if one of us ships a bug and fifty people complain about it every single one of those complaints is taken personally--the entrepreneurial equivalent of being told your baby is sick. Each and every complaint hurts. You don't want your baby to be sick! You want him/her to be perfect!

Some of these complaints hurt worse than others. Yes, you already knew that when someone uses your product while simultaneously running an OS/2 Warp emulator, all of the drop shadows on your icons would disappear. Fine! You were mentally prepared for that one and had made an explicit decision that it was worth shipping that bug. (And for those of you who have never worked at a tech company before...every product you've ever bought has a known bug list that is usually made up of tens, if not hundreds or thousands of bugs.) That's like being told your baby has dry skin. No biggie.

The one's that really hurt, however, are usually 1) the ones you didn't see coming and 2) ones you misjudged in magnitude. These are the ones end users get angry and complain about. That end user anger is translated into entrepreneurial guilt. You feel terrible you didn't fix that bug before it shipped and now your customer just had your application crash and lose the 30,000 page research paper the customer had dedicated his/her life to (all without saving of course) which was also about to cure cancer. Now you're worried that all of this customer anger will reach a crescendo and impair the future success of your startup/baby.

Don't underestimate the impact this will have on your life as an entrepreneur. These sorts of situations can really ruin a day and contribute to why being an entrepreneur is so tough. Starting a company feels like a rollercoaster especially early on. Nasty, customer-affecting bugs are often the trough in the rollercoaster. When customers suffer you do too. 

My advice when prioritizing bug lists is this, ask yourself, "How will I feel when we get hundreds of frantic emails and DMs from customers complaining about this bug? WIll I slough it off and say 'Tough luck it's just a drop shadow' or will it turn into 'AntennaGate' and ruin the rest of my night or week?" That's at least one way of gut-checking how you're prioritizing your bugs.

Remember, the bugs affect you too.

Beta gets a bad rap these days. Sachin is right that the designation can become an excuse. Google kept Gmail (a truly great product) in beta for over five years, and customers became comfortable with the concept. Lazy companies take advantage of this comfort and say "beta" when they mean "buggy." Wrong. However, a beta done right is one of the most powerful tools in your arsenal.

There's no substitute for getting your product in front of customers but it's not always easy. It's 2010 and anyone can launch a Minimum Viable Product for peanuts. This is great for products aimed at individuals, but it's tougher to convince an enterprise to take a chance.

Enterprises move slowly, and sales cycles can be long and difficult. It's tough to ship fast and iterate quickly when you have to deal with budget cycles, legacy systems, and institutional inertia. Big organizations are full of people whose goals aren't aligned with yours.

A good beta program can help mitigate these risk factors. What makes a good beta program? In my view, it needs at least the following:

• A working product, clear implementation plan, and finite timeframe
• An internal champion at the customer
• A product manager on your end whose life depends on a successful beta
• Measurable evaluation critera

Well-run beta programs are a lot of work. If you launch your product to an enterprise without providing proper support, getting influencers on your side, mitigating concerns, and proving that you solve the customer's problem better than anyone else, you will fail.

But if you do it right, your customers will tell you what's in the whole product you need to build to win the market. They'll feel special because they helped. You'll build the relationships you need in the organization and convince the decision maker to open her wallet. You'll make the customer successful and they'll love you for it--even if you have a few bugs.

I love the last line of Sachin's previous post. Ship a simple, beautifully polished product rather than trying to check all the checkboxes.

However, the reality is that you're going to ship with bugs. Every single software release that I worked on at Apple went out the door with hundreds of known bugs, some of them pretty embarrassing visual glitches and crashes.

That doesn't mean that you should blindly throw software over the wall to your users. Those bugs that we shipped were discovered after hours of testing, examined from every angle, prioritized and reprioritized, argued for and against, and ultimately punted to the next release with great reluctance.

Everything's a tradeoff. Against the benefit of fixing a bug, you must weigh:

• time required to diagnose and fix the bug
• risk that fixing the bug will have unintended consequences, including introducing something even worse
• lost user benefit since they don't have your new product in their hands
• cost of giving your competitors more time to catch up to you

Time is a huge part of this. If you've got enough time before your ship date, then you may have the luxury of fixing "nice to have" bugs. But keep raising the bar as you approach your release date. When you're on the verge of shipping, only a true showstopper can delay your launch, no matter how badly the mispositioned drop shadow pains your CEO.

There are no easy answers, of course. Shipping the wrong bug can cause real pain for your users and even torpedo the future of your company. But if absolute perfection at any cost is your philosophy, you may be in the wrong business.

There's no better feeling in product development than seeing real people using what you have built. And there's no better way to get feedback. Is your product a good fit?

But there's one important caveat to shipping early: absolutely do not ship bugs. Whatever you deliver to a user needs to work. Remove features if they aren't ready. Add more functionality in the next release. But if you ship bugs, you will lose users.

So you have a buggy product but you still want to launch? Just put a "beta" badge on it and you're good. WRONG. Releasing software as "beta" is bullshit. It's lazy. It's asking for a free pass for the bugs *that you should fix*.

You can prerelease software to a small group for testing. But when you go public, stand by the software you have written. Own up to the bugs.

In summary: when shipping software, do it early. But don't measure your software by how many features it has; measure it by the experience and polish.

Realtime Worlds, a $100mm smoking video game crater. From VentureBeat:

Realtime Worlds had previously created Crackdown, a futuristic cops-and-robbers game that took place in an open world urban environment. It was like Grand Theft Auto, but with more of a comic-book style artistry. Propelled by that success, the company built its staff to more than 250 employees and created a publishing alliance with Electronic Arts. It’s scary to think that the company worked on All Points Bulletin for more than five years and only found out now that nobody wanted to play it.

Ouch. They waited five years and spent tens of millions of dollars before knowing whether the very concept of the game the were creating was worthwhile?

I was just at the Chicago Tech Meetup where Brad Keywell, co-founder of Echo and Groupon, was speaking. One of my favorite parts in Brad's speech came when he said, "Groupon 1.0 started on a Wordpress blog."

That's all they needed to test the core concept of the business as Andrew Mason, Eric Lefkofsky and Brad pivoted from ThePoint.com to Groupon. That simple Wordpress blog tested the very core of the concept because guess what? If that very core doesn't work, no number of extra "features" you layer on will ever make it better. It will only confuse the crap out of you. Brad recommended, "Test it and fail a lot...No waiting for five months and building software and hoping it works." Great advice indeed.

This post by Caleb Elston comes pretty close to summarizing the mission of 8020startup.com: 

A good product is not a bucket of features, a mere bulleted list of things users can do. A good product is an exercise in exclusion. A good product is defined as much by what it doesn't do as by what it does. This is especially true at the start. At the onset, people don't care about you, they don't know what you do, and they certainly won't put up with a confused product. This apathy must be acknowledged and combated in a product that does one thing extremely well; otherwise it won't stick.

The contributors to this blog are united by the belief that simple works. Said another way, 20% of the features deliver 80% of the value. Success is not defined by creating a lean versus fat startup or even minimum or maximum product. Success is about making your product experience simple and right. Designing for simplicity is one of the most complex tasks possible.