Why you’ll always think your product is shit | Hacker News Reader

Why you’ll always think your product is shit

andrewchenblog.com

203 pointsnreece46 comments

So true. I think the sign of a great PM is the ability to see all the imperfections but the self-control to focus on the things that matter and to de-prioritize the things that don't.

It's easy to make a list of everything wrong with your product and spend eternity trying to fix it all. It's harder to reconcile imperfection with the reality of limited resources and business objectives.

+1. (I'm the author of the article)

Thanks for the article, Andrew.

Content has a way of their own. Appreciation never really reaches upto the perceived recognition. Being in content game and UX occasionally gives in the same.

Awesome read. Makes me want to go see Pixar! Thanks for the eye-opener.

I also think the fact that you see all the imperfections in your product is what will eventually make the product not just good but great. The key though is to release early and release often. This allows things to get fixed faster, and get to where you want to be.

LedgerSMB has had one horrendously slow release (1.3). It was driven around the wrong priorities and tried to fix too much. The mistake nearly sunk my business. We learned our lesson and will continue to plan for significant but manageable releases in the future.

>Pixar’s teams are ultimately a collaboration of creative people and software engineers.

Grrr.

Can you explain to clarify? I and perhaps a few other people do not have enough background information to deduce the reason of your 'Grrr'.

The implication that software engineers aren't "creative" people.

Many believe that software engineering is closer to art then it is to engineering.

I guess prejudice is in the eyes of the beholder... "creative" (at least for me) = "people that draw or play stuff". Therefore, designers, music composers and painters/whoever-draws-cartoons. I don't see how this implies that software people don't "create" stuff (and at the same time, I don't understand the need of some to be seen as "software artists" when writing raytracing software or "engineers" when writing a bloody webapp...)

I could be wrong, but I think what you're seeing is industry jargon more than a slight on software engineers. In movies and theatre, the "creative team" refers to designers, directors, writers, etc. "Technicians" like camera operators, CGI engineers, props people, etc, aren't on this team. It's not meant to be a comment on their level of creativity, it's just a way of delineating roles.

Probably because it implies that software engineers are not creative.

Similarly, I've always found the description of the designers in agencies as "the creatives" as a weird and troubling siloing.

The term "creative" has multiple meanings, and I think in the sense they intend, the software engineers at Pixar are in fact not creative.

The following story may make the difference easier to see. I've been interviewing a lot of independent filmmakers, asking if they'd be interested in pitching ideas for webisodes to brands that want entertaining content. The prize if their pitch is chosen is that the brand would pay for them to produce the series. So far the filmmakers I've talked to fall into two camps (actually one camp and one individual, but I'm sure there are other filmmakers like this person): the first absolutely love the idea, and the second basically said the money would never be worth it. The essential difference is whether they are creatives.

All of these filmmakers are paid very well for taking someone else's creative idea and converting it into a video. All of them love their jobs. But the first group of filmmakers then spends all their extra time and money making their own creative work. The second group has no narrative films of their own, and talked about what a relief it is that they don't have to be involved in the script, the storyboard, or any other part of "creative" (their word).

Software engineering is similar. I became a software developer after being a jazz trumpet player for 10 years, and the single biggest surprise for me was how creative programming is. You can come up with an idea and create almost anything with nothing but your brain and an internet-connected computer! The creativity in that is awesome.

But many developers don't actually have an interest in coming up with the concept or UI. And certainly most developers, whether they'd like to or not, have very little involvement in the core concept behind the software they're developing.

At Pixar, the software engineers have little to do with the plot, characters, dialog, or storyboarding. While I'm sure they solve problems creatively, and they do actually create the story by bringing the already drawn characters to life with realistic animation, this isn't what Pixar means by creative.

I've had to counsel (for lack of a better word) team members who got excessively demoralized and cynical about the product we were working on, because all they ever hear about is what is broken, who is pissed about it, and what deal fell through because of it, on what is largely a successful product making a decent number of people happy. Make sure that you don't just look up and check the global context sometimes, make sure your team members do too, and help them if you have to.

I've been in that spot. Actually going to where users are using the product was a big lift. They liked it, despite the "code warts" that they are blissfully unaware of.

I am reminded of the 'Cool Cam' anecdote, in which morale was shifted from "Not only that, but everyone had grown tired enduring the stress of the weekly 'why-shouldn't-we-cancel-this-project' meetings with the executives" to "The weekly meetings got easier, more developers were brought on, and the team managed to put together one hell of a game."

http://thedailywtf.com/Articles/Classic-WTF-The-Cool-Cam.asp...

A friend of mine says that in the aerospace industry they have a saying that goes something like: "Eventually you have to shoot the engineers and fly the damn thing"

I suppose when you're strapping jet engines onto a metal tube, filling it with people and hurling it into the sky you have to accept that things are never quite going to be perfect.

In the same manner, it seems like the take-away is: if you create something, then you'll always spot the flaws, but when the benefits outweigh those drawbacks enough, you'll probably be the only one who really notices them.

Or as I like to put it (regarding LedgerSMB):

All accounting software sucks, LedgerSMB included. We are working hard to reduce that until eventually we will be the first accounting software that doesn't suck. But that is no reason to withhold our progress from our userbase!

I think LessAccounting may have beat you to that particular line of branding: http://lessaccounting.com/

Well,not sure I would want to build a brand on that. It's not very customer-positive. But I am glad they realize the same as well.

A friend of mine always tells me how buggy and terrible the software he works on is. He says it's amazing that people even pay money for it.

I've used the software, and it's pretty great. It's easy to use, powerful, and nothing else really compares to it, but he still thinks it's shit.

It's funny how spending your days making your product awesome will warp your mind into thinking it's terrible.

Almost all software is buggy and terrible if you look at it closely enough. There are few truly elegant, robust programs out there. Even PostgreSQL has its warts....

However, the fact is..... you have to release continuously to make the software better, and quality is also relative. As a friend of mine said, if you are with a dwarf and you run into a dragon, you don't have to outrun the dragon, only the dwarf!

I like to think as bad as the software I work on is, we are outrunning the dwarves!

This is a great article.

What if your product actually is shit though? To all the wannabe entrepreneurs on here, if you feel that your product sucks, it's probably because it does, not because it's a beautiful gem that you'll never be satisfied with.

If it really sucks, people will tell you. So build something and ask for feedback.

One of my favorite quotes, from Lee Unkrich of Pixar: "We don’t ever finish a film, I could keep on making it better. We’re just forced to release it." http://m.wired.com/magazine/2010/05/process_pixar/all/1

Pixar is such an inspiring company when it comes to creativity, innovation, and values. If you've never seen the excellent documentary "The Pixar Story", I highly recommend it.

Then the question becomes how do you know your product is good enough for release despite all the shortcomings you know inside?

My 2¢:

If it's a software product, and you're debating whether it's time to release, it's probably time to release.

If your customers try your product and quickly abandon it because of it's imperfections, you prioritize fixing those imperfections. If they complain a little, and a few of them leave after a while because they're fed up, it's probably worth fixing those imperfections at some point, but you may want to focus on other priorities.

What about the importance of the 'first impression'. This is an overwhelming concern for the PM of my current product, and going for that 'extra 10%' is causing many delays to launch.

In November of 1999, I decided to write my own blogging engine (back then though, I was thinking more of an online journal than a blog). At the start, I had grandiose features, and in the mean time, I kept the journal/blog private (first post in December---http://boston.conman.org/1999/12/04.1) only a few people knew of its existence) as I worked on the code base.

Nearly two years later, in October of 2001, when I wrote what I felt was a great post (http://boston.conman.org/2001/10/23.1) that I said "to hell with this, this goes live!" and bam! Whatever I had at that point went "live".

So, for me, I released the program despite all the shortcomings because I wanted it released. Since October 2001, it's gone through three (four maybe?) major revisions and while it's closer to what I envisioned, I still have some work to do on it.

As an aside, certain features I envisioned, but never got around to implementing, turned out to be The Wrong Thing To Do. Also, one feature that took the longest to implement (and for the most part, hasn't changed at all in twelve years) rarely gets used in the manner I expected it to (it's used, but it has way more flexibility than I've ever used and there are still some corner cases not handled properly even today).

So so true.

On the flipside - there is usually also a bunch of stuff that you know is freakin' awesome, but which sits way in the background, and explaining what it is and why it is nearly impossible without the context of having worked on the project.

I’ve heard something like that phenomenon called a black triangle. It’s a thing that took a lot of effort to make, that’s awesome on the inside; when you run it, all the developers see the output and know it is deeply meaningful—but all anybody else sees is something as meaningless as a spinning black triangle.

As far as I heard it referred to a game development company which had spend weeks making sure the code could compile for the new platform, setting up asset pipelines, etc.

In the context of this article, it is only true for people who care as much, have spent years caring about their work and continue to do so. Surviving sufficiently long enough in the world where you get to a point where you are truly awesome at your craft and still get to make these choices and worry about them and think about them and have those choices bother you is the realm of very few fantastic people.

I think the root cause of this is that engineers are constantly working on things that are broken or not working properly yet. By definition of our jobs: it wasn't broken, we would stop working on it.

Consequently I think engineers naturally focus on what is undone, rather than what is finished.

By definition of our jobs: it wasn't broken, we would stop working on it

This is inaccurate, IMO. Rather, engineers are constantly working on improving things. If it was perfect, we would stop working on it, but nothing is ever perfect.

Hence why knowing what is worth fixing and what is not can be just as valuable as knowing how to fix it.

I see this all the time with clients & projects and it's quite simple:

- The familiar becomes common quickly, thus losing the shine & new car smell.

- Your imagination will always outpace your productivity and imagination is where the fun is...

Nice article. Its true every developer knows the weakness about his product and when other users use his product he just hopes that they don't catch those weak points of his product. But still a product maker should always love and admire his product. If we won't love the things that we make how can we expect others to love it. Sorry, but I won't be the one who thinks his product is shit.

Ofcourse, I think everybody agrees that there are shitty products. I would not be surprised if somebody told me that there are products which are considered shitty by overwhelming number of people (developers and users alike). Now that said, whats a good metric to fairly evaluate if a product is shitty or not? May be sales? may be something else?

Corollary: accept that your product has imperfections, and be forthright about it. An imperfect thing that works, that you can talk about and improve upon, is infinitely better than promises, excuses, or silence. Even if the thing you made is not the thing you meant to make, it is 100% more thing than the nothing you had before.

I think most people create software (and food and everything else) to add some enjoyment or lift some burden.

The desire to be perfect is part of that. We wish to delight, not annoy.

But sometimes we are just afraid of having our egos bruised.

Something that adds to this is that kudos are mentioned in passing but screw ups are the end of the world. You can service thousands of clients a day but that one that gets pissed ...

Ira Glass has a great take on this:

http://www.youtube.com/watch?v=BI23U7U2aUY

I usually compare software development to painting, it's always hard to know when is the final brush stroke.

Surely this can be classified as one of the many cognitive fallacies, which one though?

There will always be top ten things that need work.

Reply on news.ycombinator.com