Posts Tagged ‘FAIL’

Fail… Win!

Wednesday, February 4th, 2009

Got to work and there were several email that caused me heart palpitations and caused me to have to go and do some “quick and dirty” fixes. Fail.

Got a nice email about a presentation that several of us delivered yesterday to a local organization. Win!

Went into a meeting thinking I was asking for a simple file support request, and came out with the information that the project has been escalated so high into the organization that you have to do breating exercises to practice for the lower oxygen levels. Fail. or could be Win! depending on what the outcome is.

Had to purchase some human insulin for the beast, which is not cheap, and was unsuccessful in listing him as a dependent. JL now has his own pharmacy account. Fail.

So far, no exploding throw-ups or obvious allergic reactions. Win!

Received a lovely hand-made ceramic bowl froma friend. Win!

My shoulder is out of joint (this happens from time to time) and I can’t lift it higher than my shoulder until I get it back into place. Fail.

Outwitted wordpress to get back into my blog, even if I have no idea how I did it. Win!

A science project is not good business

Saturday, July 19th, 2008

If you’ve ever worked at a startup or you’re considering starting one, read this article: Monitor110: A Post Mortem.

Too much money + two leaders + letting tech trump business + not getting customer input early enough = FAIL. Come to think of it, whether you’re a startup or not (and good golly, I think I’ve visited every node in that equation). I admit to a few shudders as I was reading the article, and I’m a little surprised (refreshingly so) at the candour with which it’s written.

The problem was, however, that when it came time to make hard decisions the two-headed structure really didn’t work. It was a technology company working to solve a complex problem, and ultimately technology dominated the discussion. Ultimately, we ended up building something that the business side was not happy with, which made selling it difficult.

If you ask a developer what the problem is, they’ll tell you it’s “feature creep” (i.e. business’s fault); if you ask the business what the problem is, they’ll tell you it’s bad coding, not enough coding… (i.e. tech’s fault). What not many seem to do well is step back, join forces, and let the market decide. As long as we are making up the problem to be solved within the confines of the company, it will get more complex and our solution will be more likely to be wrong, and late:

Is it better to wait a bit before releasing to have a more compelling product or to begin getting feedback on a less impressive offering? We chose #1; in retrospect I think we should have chosen #2. By choosing to wait we lost our intimacy with the customer [...], falling into the classic [...] trap of pursuing a “science project,” not building a commercially salable product.

I was a bit surprised that a startup fell into this trap so early in its life, but I sadly report this as epidemic in larger companies. The bigger the brand, or the larger the product cost, or the more management levels a company has, it becomes impossible to let anything out of the door unless it is labelled “done”. Sometimes this means pushing shitty stuff out there because customers have been promised “something” for a long time now and they are now, rightly so, demanding “something”. But it’s the company that assumes that what is shown must be “done”.

These two things–the division between tech and business, and the extreme arrogance of presuming to know what customers really will buy without finding out–are the root cause of most of the problems that businesses face. Find a way to work together and to constantly put yourself out there, and I think you’ll be happier, your customers will be happier and there’s a better chance that you’ll build something viable (of course, there’s always the possibility that you find out what your are building isn’t wanted, but that’s important to know too).

It’s hard to be allowed to make mistakes or to ask questions of your customers, in public, to which you don’t know the answers. It’s hard not to change the reqs because Customer A screams loudly about what your product should or should not do. But if Customer A is not your only customer, then you need the constant reality check of checking in.

A science project, …or an ego project, is not good business.

(Link via VC)

That ain’t good…

Tuesday, July 15th, 2008

A Message From the Doctor Horrible team:

“We love you for crashing the site, we really do. In the meantime, those of you who have iTunes capabilities can go there and get your fix. Our site should be up and running again in a few hours. Your support is warming our hearts and kicking our asses. So thank you thank you. J, M, J, Z”

Grrr. Argh.


Update: Success!!!!!!!!!!!!!! (Lee – it’s pretty awesome :)