The Latest from TechCrunch

Editor’s note: Guest author Aaron Levie is the founder and CEO of Box.net

In the enterprise, simplicity simply doesn’t sell. Complexity, on the other hand, justifies costly software licenses and a swat team of consultants and systems integrators. It explains why updates are available every three years instead of being pushed weekly. And it even serves as an easy – but ultimately blameless – scapegoat for failed deployments and lagging user adoption. After all, the problems faced by today’s enterprises are incredibly challenging, and complex problems require equally complex solutions, right?

Wrong. This mindset needs to change – in fact, in order to survive, enterprise software must become simpler. Consumers are bringing new technology and expectations into the workplace where, more often than not, they’re forced to work with and around legacy platforms that disable rather than enable productivity. Simplicity will become the most important factor in business technology’s success, and to get there it can no longer be a dirty word in the enterprise. But it’s going to require some serious effort on the part of vendors and buyers alike.

We don’t want complexity, but don’t know how to value simplicity

While I deeply respect and admire the many innovations brought about by legacy solutions, the current state of technology in the enterprise kind of sucks. There’s a reason why a Google search returns more than 2 million results for “I hate Lotus.” Complexity is the culprit, and it takes many forms: tedious processes for common tasks like HR and expense reports, inability to collaborate beyond the firewall without IT intervention, and information silos without any security rationale. Not to mention the bad UI, error messages, upgrade failures, and downtime that users and IT departments contend with on a daily basis. And while no one explicitly desires cumbersome technology, we keep buying it because we’ve built a strong correlation between the number of features a solution has and the likelihood it will solve our problem. That, and you won’t get fired. While building or adopting the most feature-rich service looks great on paper, in practice it means that customers have signed themselves up for technology that can never be upgraded, unhappy end-users, and (paradoxically) inertia to move off tools that required so much time to implement and experts to maintain.

This bias isn’t limited to technology buyers or builders – the analysts I speak with often focus more on feature comparisons and product matrices than end-user experience and customer success. But that is changing, slowly. Gartner analyst Brian Prentice recently argued that simplicity is misunderstood and needs to be defined by the relevance and usefulness of features rather than the absence of features. But, we still have a long way to go before product comparisons focus more on customer success than feature parity. Gmail would never win a battle with Exchange on sheer volume of features, but the features that remain translate to better end-user adoption and satisfaction.

CIOs and IT administrators may be wary of out-of-the-box simple solutions, but they’re certainly not happy with the complexity of current solutions. A recent Forrester report on CRM deployments, for instance, found that “inflexibility” and “difficult upgrades” were cited as significant problems by over 75% of CIO respondents. Ouch. And IT adminstrators can’t even spend their way out of technology headaches – you will often see negative returns on overspending to solve IT problems. Out of the tens of thousands of IT buyers we talk to, the biggest benefit of moving to the cloud is the reduced support time and hassles, not just the reduction in cost. The need is certainly there for simpler solutions, but we need to prioritize and value simpler technology.

Building simple software takes vision and discipline
Mark Twain (or Ben Franklin, depending on your source) said, “If I had more time, I would have written a shorter letter.” This, in essence, is the challenge with simplicity. Building simple technology is not easy; it inherently takes much more work to reduce complex problems into simple solutions for people. Building products that suck is far easier, as David Barrett of Expensify pointed out in his post yesterday. Simplicity requires that you have user experience drive product management and solve problems with exceptional design. And it also means you sometimes have to say no.

It’s really, really hard to say no to customers. They want the world from your product, and they deserve it (really, they do). But letting customer feature requests or analyst reports exhaustively drive your product roadmap can be incredibly damaging. It’s not that they want something useless or that they’re wrong in their demands; it’s that they’re not seeing the underlying fabric of your product. And this is why it’s so crucial to have a vision: if you don’t know where your product is heading in a fundamental way, your customers or competitors will take you in too many directions. As Rypple co-CEO Daniel Debow points out, traditional enterprise software sucks because vendors relinquish control of product roadmaps to close deals: “Buyers may not realize it, but the many hours they spend crafting the perfect RFP are really spent designing the software that comes out the other end.” Build for all your potential customers’ potential problems and before you know it, you’ll become the more complex competitor that you’ve trying to disrupt. The majority of software and services tend to forget this as soon as they go from focusing on user experience (market fit) to scale.

There will always be a few really complex problems that require complex solutions. But for the vast majority (read: 95%) of use cases, simplicity will suffice. Where complexity is necessary – whether it’s to build a specific workflow, integration, or solution for a particular vertical – solve it through customization. Abstract the core areas of your product from the parts that can be modified by a developer or customer, making sure the core and default use is still simple. The best products in the world can do as much or as little as customers want without you having to think twice. The economic upside of this is obvious, of course, as you’ll now have a rich ecosystem of integrators, value-added resellers, and professional service firms that can participate in your success.

You can’t change market expectations, but you can create new markets

So how does Box make enterprise content management simple? We don’t, really. We redefine it. If Box tried to compete based on the laundry list of functionalities that have come to define ECM, we’d quickly lose to SharePoint, which has a sufficiently filled-out offering and deep penetration. An existing market has certain expectations because of the companies that have come before you, and you can’t just build to meet these standards, nor should you set out to change them immediately. Instead, find the dimensions where you can make things materially simpler, and build a solution that gives users more power with fewer features. Start with a department and end-users, solve their problem, and expand.

Or look at the problems your product is already solving, and expand into entirely new, under-served markets. For instance, there’s an explosion of demand for business software in the mid-market. Companies in the 50-1,000 employee range are large enough to have challenging and interesting problems, and for years they’ve either lacked the technology to address them, or they’ve had to buy into more expensive solutions than their needs require. Bring your software to new organizations and new markets, and if you build the best product, it will grow. It’s far easier to maintain simplicity by finding the groups that have the problem you already solve really well, than by trying to reach legacy markets by building new features.

Take MySQL, who redefined the database market by offering a simpler database for every developer in the world. They now own a huge chunk of the market without having to compete with Oracle in the process. GoodData, Zendesk, Assistly and Workday have all leveraged the cloud to build simpler solutions in markets dominated by big, clunky, overly comprehensive systems. Salesforce.com, with a $15B market-cap, has shown how to build a very large enterprise by selling a little to a lot of customers: an average Salesforce.com customer only has an estimated 15-20 seats on the service.

How to build a simpler enterprise:

If you’re in IT: Look throughout your organization and find the areas where employees spend a disproportionate amount of time or run into problems on a specific set of tasks. Enabling technologies in these areas will pay huge dividends for your organization. Pilot tools with employees, or find out what they’re already using before implementing something site-wide — more likely than not, a simpler solution has already been adopted. Consider the intangible value of implementing simpler technologies: less support, less maintenance, less headache, more productivity. Demand simplicity from your vendors.

If you’re building software: Invest disproportionately in design, usability and engineering. Create transparent feedback loops to make sure your product is being successful. Building great, usable technology is not subjective. Constantly test what you’re building on users and gather data consistently. Reduce features sets, allow for customization, and stick to your vision. Sell based on the complexity of the problem and the simplicity of the solution.

If you’re a business manager or end-user: Talk to your IT department. Explain why your existing technology isn’t meeting your needs, and offer to pilot new technologies. Use your IT organization as a source of knowledge and innovation rather than just a support center, and they’re far more likely to implement user friendly, innovative technologies.

Simplicity will be incredibly beneficial, and it will also be incredibly disruptive. The losers will be the technology providers who are either too lazy or too overextended to settle on a vision; the winners will be workforces that are empowered by usable technology and the vendors that serve them.

Photo credit: Getty

Welcome to part two of Ask a VC in Southeast Asia. This week, it’s Wilson Cuaca and Chandra Tjan of East Ventures. I shot this video in Singapore, but they invest primarily in Indonesia where East is one of the only traditional early stage VC firms.

Over delicious crab, we discuss the Web opportunities in Southeast Asia, whether startups should focus locally or globally, and perhaps the most important and most divisive question: Whether Singapore or Indonesia has the better cuisine. Enjoy.

Ask a VC will return to the Valley next week. Not sure who the guest is, but send in your questions now to AskaVC(at)techcrunch(dot)com.

At Tencent headquarters there are pictures of its cutesy penguin mascot everywhere. Sometimes he’s winking and smiling, and sometimes he’s getting all badass, seen to your left. It’s also how the company behaves in the market.

As you may have read, a strange and dramatic fight is escalating in the Chinese Internet between Qihoo 360 and Tencent, maker of the ubiquitous QQ messaging platform.

In short, anti-virus software maker Qihoo 360 accused Tencent of giving out private user data and turned its privacy protection software guns on QQ. Tencent has big muscles in China and its flexing them: It accused Qihoo 360 of something similar, telling users to uninstall the software if they want to keep using QQ. That the standoff is so tense — and critical to the Chinese Internet given the power and reach of the two players– that the country’s Ministry of Industry and Information Technology and the Ministry of Public Security have stepped in. There doesn’t appear to be any solution yet.

Why should you care if you’re not in China? Because China is the largest Web audience in the world and Tencent is the king of it. At north of $40 billion, it also has the third largest market capitalizations of any Web company globally, just edging out eBay and  soaring even higher in the last few months. And it has international ambitions. It owns 10% of Mail.ru, which in turn owns huge chunks of Facebook, Groupon, Zynga and other Western Web 2.0 giants. Watching how Tencent throws its weight around the Web is now as important as watching precedents set by Google or Facebook.

I know what you’re thinking: Chinese companies are up in arms about the rights of individuals online? But let’s put that aside for a minute. This is a test of just how powerful Tencent is becoming– more important, how it views its power in the world’s largest Internet market. Chinese sources are saying they’ve never seen a battle like this amid the normally low-key Web giants, and it’s hard to remember one like this in the Valley. The closest I can remember is the throw down between eBay and Google over payments where eBay blocked Google Checkout transactions on its site and when Google pushed back, eBay pulled its ads. No one won: As Mike said in the link above Google came off like a wimp and eBay came off like a bully.

That spat was nakedly about power in the check out market. This fight is ostensibly about user’s infomation and  the crucial question is whether either of these companies are indeed sticking up for users’ privacy rights or it’s all just competitive posturing. As far as I can tell no one really knows. And that’s the point. In the blackbox of the Chinese Internet, it’s almost impossible to know who is protecting users and who is just protecting their fiefdom. That means it’s not in the interest of China or the Web for any one site to have the power to strong-arm users stop using another popular service.

We’ll see how the market votes. Will the desire to connect with friends over QQ win out over software that prevents viruses? The world’s Web elite should pay attention: If Tencent has that much power, that’s even more staggering than its market cap.

This is a guest post by Julia Krysztofiak-Szopa, product manager at Inflavo and former community manager at Adtaily. On Twitter she is @julencja.

If you happen to be a smart, English-speaking programmer in Poland, there is a good chance you will work in a start-up.

An American one.

Ryan Janssen, CEO of New York based SetJam.com started his company 18 months ago. His first challenge was to build a team of quality developers but, according to how he sees the tech scene in New York, finding the developers who work in lighter, agile frameworks was not so easy. The startup-oriented Django/Python/Scrum skill sets are hard to find in a city where majority of programmers work in more enterprise-friendly methodologies, with .NET, Java and C++ as core languages.

Today SetJam employs six full-time developers and three quality assurance specialists, all of them based in Poland

First shoes, now diapers. Amazon is reportedly about to announce on Monday the acquisition of Quidsi, the New Jersey-based ecommerce company behind Diapers.com, Soap.com, and, most recently, BeautyBar.com. Fortune’s Dan Primack, who broke the story from a maternity ward in Boston where his daughter was just born (no joke), puts the price of the all-cash deal at $540 million. A year ago, Amazon bought online shoe retailer Zappos for $1.2 billion.

Founded by Vinit Bharara and Marc Lore, Quidsi has raised a total of $78.5 million. Its most recent funding was a $20 million debt round last April from investors including Accel, Besssemer, MentorTech, and New Enterprise Associates.

Diapers.com is the company’s flagship brand, with an estimated $300-million revenue run rate this year. Soap.com just launched in June, and BeautyBar.com launched last week. So the vast majority of revenues is still coming from Diapers.com, which would value the deal at less than 2X revenues. Feeling threatened, Amazon recently started undercutting Diapers.com on price, a strategy which may have helped convince them to sell.

If the deal goes through, it would just go to show that you can still build an ecommerce startup if you go after the right niche. But it would also prove that if you get big enough, Amazon will notice and either buy you or try to squash you.

“Like” buttons have been around on the Internet for a while now. But most people didn’t pay too much attention to them until Facebook came along with their one-like-button-to-rule-them-all. Now it seems as if every site on the Internet needs a Like button. And while most companies are content to use Facebook’s, some behemoths prefer to keep their data in-house. Like Amazon.

It appears that the online shopping giant is currently in the process of testing out their own Like button. As you can see in the screenshots taken by reader Arul Isai Imran, their button looks similar to Facebook’s, complete with the thumbs-up icon. Clicking on the button turns it orange and changes the text within the button to “Liked”. Interestingly, below that, there’s a check-box that reads “Don’t use for recommendations” — clearly, the main intention here is for Amazon to use this button for recommendations.

And that makes a lot of sense. A huge part of Amazon’s business is recommendations. Currently, they look at what you’ve been browsing for on Amazon and especially what you’ve bought. This Like button will give them one more explicit signal, something in-between browsing and buying.

It would seem that most people aren’t seeing this button yet (I’m not, for example), but plenty of people are, and it seems as if they’re mainly being tested on Amazon Books pages right now. You’ll also note in the screenshots below that Amazon has cleaned up the design of their header a bit.

[images: twitpic/aruvam]

I heard from Mike Arrington this morning. Good to hear the familiar voice now wrapped in the aura of rich and retired. Of course, he's no fool and realizes quitting is not an option. If we stop doing whatever that is, we throw life in the dumpster. Nothing good follows. He may be crazy but he's not stupid.

How come you're not writing for us, he begins. Actually, he tries first to confirm some rumor he's either been fed or made up about Salesforce. I recognize this is as a test, designed to illustrate my ethically challenged new reality now that I work for Marc Benioff instead of just plain admiring what he and his company are doing from the alleged neutrality of the media. That while asking me to resume writing: Please deliver your debunked credibility to my (uh, AOL's) firebrand flagship disruptive media leader.

So I remind him of the numerous times I've sat next to him as he rides around town beating the story out of some hapless deer caught in his headlights, and that he's getting nothing because I've seen this movie. Unfortunately, what he really wants is for me to write some of this patented stream of consciousness drivel for him so I can be ignored and berated by the 12 year olds who are just waiting to push me into the grave and shovel the worm-riddled dirt over my irrelevant pundit ass.

By now I'm sure Mike is rethinking the idea, but at the time he called he was hoping I'd deliver some wisdom about the recent apparent retirement of Microsoft's second Chief Software Architect, Ray Ozzie. Aside from some mean spirited but amusing Fake Steve and a smattering of reporting, most observers seemed content to go after Steve Ballmer and let Ray move on in graceful peace. But Arrington has a good instinct not only for what he does but also for the stuff others find interesting as the Big Picture spools on.

What he smells is this: Ozzie has moved on emotionally to reboot his imagination, his sense of wonder at what we can do when we honor that which is indistinguishable from magic with our time. It's a powerful signal, that the grass is greener outside the Microsoft moat. It's that fateful moment of a divorce, when one or both realize it's time to jump so that the healing and rebirth can begin sooner.

Is covering a divorce a good way to spend my time? No, and why not. I miss the old Microsoft when Bill was King and we balanced awe and fear of the juggernaut that was Windows and Office. But now Jobs is King and the Cloud is an endlessly rejuvenating hub of innovation and opportunity. Windows is just a coat of paint, vital to keep the cracks from forming and the termites from digging in, but not a place from which we daydream. Office is well-maintained, clean, freshly swabbed down with the bracing smell of antiseptic.

But so what. Do I need a document to memorialize ideas or a file structure to file them or a location to store them? No, no, no. How many millions of iPads need to be sold to underline the profound nature of the disruption. I don't care about the container, I love the iPad because it's like the fourth wall we break through in the comedy club and become part of the scene. The stream is a living breathing thing, and we intuit that we can't freeze dry information while it's in the process of being born. The idea is the first breath that's taken, the document is a shelter to protect the child until it can find the confidence to enter the dialogue, and the location of the spirit that's unleashed is TBD.

We're captivated not by the mechanics of the system but by the glimmer of awareness it suggests. Lotus Notes was like the liftoff from the surface of Tranquility Base: it was logical that it would work but amazing that it actually did. It may be hard to remember what it was like before the Web, but Notes was ungainly and hacked on top of a Windows that should have been called Window. Notes validated the idea that Windows was a platform you could build something bigger on. The collaboration is the computer.

With Notes, Ray discovered what happens when we think across boundaries. The very physicality of the chicklets, little rooms you could open up and rummage around in, code you could attach to make things happen even when you were out getting drunk or asleep. The idea that we could not only tame the neck-bolted Frankenstein that was Windows but that we could collaborate and free associate right under the noses of IT. No sexier than 5,000 Facebook friends, but for its time a landscape that drew me in and taught me that IP tunneling over the public net could produce a secret world hidden in plain site like the rooms we carved out of plowed snow banks as the day kept the snow malleable before night turned our work into smooth ice.

I'm not here to argue with Sir Tim and the WWW, but I remember what came before and after and that everything about Notes — from its complexity to its economics to its underlying assumption that collaboration could even be practical at all — changed who I was and what I expected. I was a child of the 60's, a creature of first the 61 Yankees of Mantle and Maris and Kubek and Richardson and Berra and Skowrun and on and on, and then the Beatles of John and George et al, and then Kubrick and Annie Hall and: now what? The dream is over? It was no longer what I wanted to do when I grew up but instead 4 dead in Ohio.

Constructing the future on the 2001 soundstage and dragging McLuhan out from behind the sign was the inflection point, but when Woody Allen delivered the line "Boy, if only life were like this!" he was simultaneously making it so. Say what you will about the hairballs, but Notes made it so if you wanted to spend your time that way. It bound me to technology in a way that before was child's play and after became a life's work. Yes, bad things could happen to good people, but good things too.

But Ray's not done and neither are we. In fact I think Ray wanted to go out and play and didn't want to ask permission any more. I think it went something like this:

Hi, Steve it's Ray. Listen, I quit. No, no, it's not you, I just don't want to spend another damn minute thinking about Saving Private Windows. How long? I was thinking about tomorrow. Oh, well then how about right now. I've been writing this stupid memo for hours now and I've run out of nice things to say about Sinofsky and the rest of those idiots. Steve, you're the best but every time I write milestone it auto-corrects to millstone. In the time we've been chatting, Jobs has taken down 2 more carriers, bought and sold Disney, and almost rebooted the Mac as an iPad charging stand.

Now wait a minute Steve. That's not right. I did stay here and finish what I started. I know, I'm just too nice about this, have been all along. Should have just shot one of those Office guys and ported it to the iPad whether you liked it or not. I told you it would be huge from minute one. Bill would have done it in a New York minute if he thought it would save the company. By the way, have you heard the new Neil Young record? It's an angry world, you know.

What are you going to say? You'll have to shout to be heard over the gloating. Just say I've gone insane and you had to do this for my own good. Of course I was just kidding about 3 screens and a cloud. It's just the cloud. Jobs has all the screens. Rename it Sharepoint Azure and then drop Azure. Try it: we're all in on the Sharepoint Cloud. Then rename Office Xboffice and Windows Phone the xPad. No, SharePad's not bad either. See, Steve, it's going to be fine.

Editor’s note: The following guest post is written by David Barrett, CEO and founder of Expensify, whose tagline is “Expense reports that don’t suck.”

Now, you might think that making a product that isn't terrible should be so obvious to every company on the planet as to almost be nonsensical. Indeed, who would ever advocate building a product that sucks? But the fact is: many products do suck. How can something so obviously important and universally recognized by so infrequently accomplished?

It's a surprisingly complex question. But I think it all boils down to variations on a single, simple answer: it is much, much easier to build a product that sucks than one that doesn't. Here are some reasons why that is true (and what you can do about it):

1. It only takes one person to make your product suck.

I love the movie Twelve Angry Men. (The Henry Fonda version, not the Tony Danza version.) It's about this jury of 12 people, 11 of whom walk into the jury chamber convinced the accused is guilty. But as you know, juries can only render verdicts with unanimous consent, so that one lone individual is able to prevent a quick conviction and force the jury to review the evidence and deliberate on the case—one by one convincing everybody that the accused is in fact innocent. It's a great movie about the power of the individual to uphold justice in the face of prejudice, expediency, and general carelessness.

Unfortunately, your team isn't a jury. Quite the opposite: anybody can make your product suck, often without anybody else noticing until it's too late to change, and very expensive to undo. The fastest racecar can't move if the gas-cap gets stuck; your product is only as good as its worst component. Not sucking requires continuous, unanimous consent—not on the details, but consent that not sucking is worth the effort. And you need to do it without security guards lurking outside the door.

Suggestion: Convey to your team and the world that not sucking is your primary goal. More important than new features, more important than new customers—even more important than being awesome—is the simple act of not sucking, consistently, across the board. Each awesome feature might attract a new user, but each sucky feature will lose you two.

2. Nobody ever got fired for sucking.

There's that old saying "Nobody ever got fired for buying IBM". It dates back to when IBM was in decline after a long period of dominance, when there were clearly superior products available but the risk of choosing them was higher than the safety of going with the tried-and-true. You can always be fired for something going horribly wrong, or for trying something crazy that doesn't pan out, or for doing something that upsets a key customer or loses a major deal. But nobody gets fired for merely doing something sub-optimal, especially when that's what everybody else does. Too often product teams take the the quick and dirty way to get the feature out, or concede to that "one line change" to satisfy some new client. Nobody gets fired for making something merely meet the hard requirements, even if it fails the "soft" requirement of "not sucking".

Suggestion – Be slow to hire, and quick to fire. I know everyone always talks about the importance of exceptional people. But like the importance of not sucking, that standard is very rarely maintained in reality. Maintain it. There's that saying "A people hire A people, B people hire C people." Be an A person, even if it means doing without for far longer than you'd like.

3. It's easier to suck more than suck less.

Sucking is like a tar pit: once you step in, your struggles only pull you in deeper. After you make that one product compromise to satisfy some crazy customer, then you've got to support that setting forever lest you lose the customer who depends on it. Then other customers find it (because if you're going to build it, why not give it to everyone?), and those customers have their own unique requirements that pull you further into the sludge. That one random checkbox for a single customer becomes a full settings page for a niche demographic with esoteric needs. Supporting those customers places constraints on how you support other customers, affects how you upgrade your data structures over time, prevents sharing of certain types of code, etc. The tar pit sucks you down, and sometimes the only way out is to go back the way you came, discarding the customer you fought to get in the first place, and upsetting all your other users along the way. Avoiding the tar pit takes an incredible level of discipline and fortitude. It should be no surprise that it so rarely happens.

Suggestion: Avoid the tar pit at all costs And when trapped—which will happen, often, despite your best attempts—cut off your own limb if necessary to get back on track. Even if it means upsetting 100% of your users: if they're the wrong users, it's what needs to happen to get the right ones.

4. There are more ways to suck than to not suck.

Anybody charged with building some feature is immediately overwhelmed with choices. Even ignoring the countless technical options for rendering feature X on platform Y, there are limitless sub-variations to every possible choice. Something as simple as, "Should this link be a button?” “Should the button be on the left or right of this other button?” “Should clicking it open up a dialog or a new page?” “Should you click Save after clicking the button, or does the button auto-save the result?" And on and on. If sucking is like a tar pit, then building a product that doesn't suck is like walking a tightrope over La Brea. In the fog. There are countless places to step, but very few of them are on the right path—and often you don't know you've slipped until you're waist-deep in tar.

Suggestion: Define what not sucking means to you, and make sure everybody knows it. Even if the lines are ambiguous, draw them anyway, and work to constantly refine them. How you circle your wagons is far more important than how fast you can fire your guns.

5. Customers demand sucky products.

Not intentionally. But they request features that make your product suck, with depressing regularity. This is doubly true if your product allows some users to manage other users. There are features that they think they need but don't, and features they actually do need but nobody else does. There are billions of people out there and you will never, ever satisfy even a tiny fraction of them. So be very selective as to which ones you let dictate your roadmap, and make sure they're taking it to the promised land and not into a tar pit. They'll threaten to never use you, or to quit, or to say bad things about you. Some will actually follow through. But most will eventually realize you were right all along. That is, if you actually were right in the first place.

Suggestion: Trust your instincts and the tiny set of users who use you, and resist advice from the billions of people who don't. Either you're right or you're wrong. If you're right, sticking to your guns will lead to success. And if you're wrong, better to fail fast on your own merits and learn something along the way than to take bad advice from people who never intended to use you in the first place.

Don't get me wrong: people complaining about your product isn't all bad. People only complain about things that matter to them; better to have complaints than disinterest. And not all complaints are equal: complaints that you don't support feature X are far better than complaints about how feature Y sucks.

But ultimately, if your users hate your product, eventually an alternative will come along that sucks less. At Expensify, we try to live by these rules and create products that don’t suck. Like any ideals, I don't claim Expensify lives up to them perfectly. If you’d like a glimpse at what we are working on next and want to help us suck less, please sign up for our Expensify 2.0 Beta.

Most products suck. But yours doesn't need to, and we're trying as hard as we can to ensure ours doesn't either. I'd love your advice on how we're doing, or any suggestions on how to do better.