Allen Pike writes:

We enthusiasts love maximal products because they inspire us and delight us. As such, we support these highly polished apps. We buy them, we write about them, we celebrate them, and we buy the t-shirt. We pay $2.99 each to try two different alternatives to the free Twitter app. These fans love what you’re making so much that they can support your business.

We call these folks prosumers. Consumer enough to care about polish, craftsmanship, and the emotion behind your product, yet still pro enough to put money where their mouth is. They are enthusiasts, either of the task at hand or of apps as a craft.

A prosumer seeks out Maximum Viable Products.

Interesting thought, although maybe more difficult to execute than minimum viable product. After all, spending the time to build out that maximum product before knowing whether anyone will pay for it is dangerous.

Given that, a lot of minimum viable products don’t implement a revenue generator, which means that the MVP isn’t testing the most important piece: will anyone pay for this? While not charging at first might have worked for Dropbox and Twitter and Facebook and a few other big companies, they also all had access to vast amounts of capital. They are the exception to the rule; we are not.

My focus is on minimum viable product to start, one that has enough to charge for so we can see the reaction, but also one that has legs and can become a maximum viable product over time. After all, I don’t want to become someone else’s feature.

There’s a story that’s been around for a couple of years now about how Drew Houston of Dropbox met with Steve Jobs. This from the Forbes article:

In December 2009 Jobs beckoned Houston (pronounced like the New York City street, not the Texas city) and his partner, Arash Ferdowsi, for a meeting at his Cupertino office. “I mean, Steve friggin’ Jobs,” remembers Houston, now 28. “How do you even prepare for that?” When Houston whipped out his laptop for a demo, Jobs, in his signature jeans and black turtleneck, coolly waved him away: “I know what you do.”

What Houston does is Dropbox, the digital storage service that has surged to 50 million users, with another joining every second. Jobs presciently saw this sapling as a strategic asset for Apple. Houston cut Jobs’ pitch short: He was determined to build a big company, he said, and wasn’t selling, no matter the status of the bidder (Houston considered Jobs his hero) or the prospects of a nine-digit price (he and Ferdowsi drove to the meeting in a Zipcar Prius).

Jobs smiled warmly as he told them he was going after their market. “He said we were a feature, not a product,” says Houston.

Houston is doing some amazing things with Dropbox, none of which I’d consider a feature. I’m certain Jobs was negotiating. But all the same, being a feature to a larger product is a recipe for being run over.

Microsoft was a company incredibly good at taking other people’s products and turning them into features. Palm, on the other hand, was horrible at it. For a company known for making personal productivity tools their apps were anything but productive. Year after year I expected Palm to add features and they never did. Many people lauded the company for not wiping out their developer community. I always thought it was just stupid.

Building a company is hard and takes a lot of luck. Some of that luck revolves around timing and partnerships and the right people picking up the product and evangelizing it. But some of that luck is that a bigger company doesn’t just run you over on their way to their next billion.

Interesting post from Elaine Wherry discussing her time helping her husband get a chocolates business up and running.

My husband, Todd, and his co-founder, Cam, had spent the last few years building chocolate machines and scouting the world for great cocoa beans in an effort to open a micro-batchchocolate factory in San Francisco’s Mission District. The construction crew finished converting the brick automotive garage to a food-safe bean-to-bar workshop and it was time to figure out the nitty gritty details like moving, merchandising, and designing the café & retail space. Todd needed all the help he could get and I was happy to pitch in during those critical months. Now that I’ve come up for air and returned to tech projects, I’ve had time to reflect on what I learned from brick-and-mortar operations:

What follows are her lessons learned. In short, why she won’t complain about writing code ever again.

I particularly liked lesson #6:

With Meebo, our business model went something like this: we built a product that people like. We monetized a fraction of those eyeballs with brand advertising. We tracked the percentage of users who clicked an ad and logged their engagement times. However, since correlating brand advertising with bottom line revenue is nearly impossible online, we also monitored ad partnership renewals. If all of those metrics were healthy, we were happy. (~60 words)

At Dandelion Chocolate, the business model is: we make and sell chocolate. (5 words)

It’s so much easier to build a sustainable organization around a simple revenue model. There are no tensions between ad partners, distribution sites, engineering, and sales teams. There are fewer points of failure. Instead, everyone is aligned towards a simple goal: make something people want.

Yeah… our best models do tend to get a little convoluted here in tech world.