Great Post on Deciding What Not To Do (via Raymond Chen)
Posted on March 24th, 2007 in Business, Product, Technology |
Whether it’s product or business strategy, until you decide what you’re not doing, you’re not going anywhere. Dreaming about the end state when your product is all-conquering and you’ve gone public on the NASDAQ is all well and good (and necessary), but you have to sit down, prioritize, decide what’s in and out of scope based on time and resources, before you have a hope in hell of going anywhere.
Raymond Chen has a great post along these lines:
Whenever I see a project description, I pay close attention to the section titled “What we don’t do.” That tells me how serious they are about shipping. And if there isn’t a “What we don’t do” section at all, I sigh quietly, since that tells me that they don’t yet know what they do.
His point is spot on. If you’re not telling people what a release won’t do, you haven’t thought it through enough. While this is something I’ve done to a certain degree in our design/spec work at Judy’s Book, I will be focusing on it more going forward. (It’s always cool when someone’s writing influences your actions. Don’t worry Raymond, I won’t blame you for anything in therapy. It’s all about personal responsibility after all.)
Thank you to Dare Obasanjo’s Top 10 Reasons your software project is doomed for pointing me to Raymond’s post.
8 Responses
raymond is a smart guy. always worth listening to.
You’re absolutely right, John. For some unknown reason, Raymond’s Blog wasn’t a fixture on my reading list. That will change.
I enjoy reading your thoughts on software development, I often find a new blog to read from your site.
I read the post on blog.judysbook.com about Bug Bash Friday. I like the idea, but I was a little suprised that it was a bit of a free for all for prioritizing bugs to be fixed. It seems like ultimately somone in the organization should be saying this is what is most important for the business to fix (likely by triage). While having a dev get beer to fix someone’s pet bug is fun, it doesn’t seem to get you to the end game. What are your thoughts on this?
Morgan,
Thanks for the kind words. Feedback is always nice.
Regarding the Bug Friday, the intent is to provide a day where only the bugs that aren’t high priority are fixed. This allows little annoyances on the site to be ironed out. This way we allocate a little time for bugs that would never make it through triage to get fixed.
The high priority items are scheduled explicitly to happen during the normal product cycle.
The reason I like the setup is that you don’t lose a lot of time, your dev team gets a mental break and the satisfaction of checking off a lot of things and we end up improving things in lots of little ways.
The hope is that these add up. Otherwise, the annoying breadcrumb behavior never gets fixed because you can’t justify scheduling it ahead of other features.
Does this make sense?
Rahul
Thanks for the clarification. This makes more sense. I was under the mistaken impression that this was a weekly event, but it sounds like it’s an “every once in a while” thing.
My pleasure, Morgan. I think currently this is going to happen every two weeks (although that may well change).
Rahul,
Here are a couple of interesting bug related blog posts that I thought you might find interesting:
http://www.codinghorror.com/blog/archives/000498.html
http://compoundthinking.com/blog/index.php/2006/04/28/over-1000-defects/
Morgan,
Great links. Thanks for sending them along. As always, it comes down to a judgement call. What’s worth fixing, what can wait? Also, there’s the issue of broken windows. Leaving little issues lingering can lead to a downward spiral because people perceive you don’t care creating a negative impact on developers and users alike.
Why is there no free lunch?
Rahul