Bryan Dunn

Productivity

Evernote

I was surprised when I realized this is really the only productivity app I used with any regularity in 2011. Any note I take or idea I have that doesn’t belong in basecamp for the larger group lands in evernote. My only complaint is the lack of a todo list, but word on the street is that it’s coming this year.

Reading

Twitter

Reeder

Up until the redesign of Google Reader, I had used it to read my feeds for many years. The redesign bothered me enough to look for an alternate solution and I came to Reeder. I still read lots of content on my MacBook and Reeder’s simplicity and beauty make it a pleasure to do so. The only reason I’d consider jumping at this point is if flipboard released a mac (or web) app.

Flipboard

The information architecture and art direction in Flipboard is second to none. I use it on the iPhone and iPad to run through my RSS feeds. I probably open flipboard 5-10 times per day to check in.

Zite

The suggested content in Zite seems to have improved a great deal since I initially tried it last year. I use it a couple times a day on the iPhone or iPad, mostly to discover new sources of content or articles that I didn’t get via twitter or RSS.

Instapaper

I use Marco’s awesome app in conjunction with all the services above to save articles for later reading when the article is too long to read or I want to study it more in-depth later on.

Misc

Fluid (with Campfire & Instapaper)

Fluid’s growl notifications for Campfire are worth the price of admission alone. I’ve been getting by with the free version up until now but it’s about time I pony up the dough.

Instagram

Simple, easily sharable and filters that can make even my pictures look good. No idea what happens when they try to monatize, but a solid option for now.

Pixelmator

I still use Photoshop for most of my graphic work but with the introduction of vector graphics in Pixelmator 2, I’m going to attempt to ween myself off of it. I’m always happy when I can avoid an Adobe product.

Trillian

I switched because iChat couldn’t combine contact lists from various sources (AIM, GMail, Zimbra, etc). Nothing groundbreaking, but it does the job.

Last.fm

I scrobble everything because I find it interesting to look back at what I listened to at various points in my life. If I could scrobble all aspects of my life, I would.

Mint

There’s been very little improvement to Mint since Intuit took over but we still use it at home for our personal finances and budgeting. It’s a really solid app despite the lack of new features.

Books Read:

• Steve Jobs Biography
• Unbroken
• 59 Seconds: Think a Little, Change a lot
• Anything you want
• Poke the Box
• Water for Elephants
• Making Ideas Happen
• Rework (again)

Music Listened to:

You need me to say no to your feature. No is the most important word in a product owner’s vocabulary. Each line in the image above is a feature I’ve said no to over the past week. Here’s why it’s important to say no:

It’s less time spent on the core product - Every second of focus spent on an ancillary feature is a second we aren’t spending on improving the core product.

It’s going to make releases take longer - Every feature means more to test and more that can possibly break when we release other features. The more features, the longer the regression cycle, the more potential bugs, the slower the release.

It’s going to add bloat and complication - Products tend to become more complicated, slower, and more confusing over time. Every single feature added to the product should be agonized over. Does it compliment or subtract from the core feature set? How does it complicate test efforts? Is it something most of our users are going to take advantage of?

It’s hard to turn down customizations that come with money attached to them. In addition to the vigilance required to avoid UI bloat, you tend to hear things like “All they are asking for is…” or “How hard is it to…” In reality, what is being asked is not only to develop this feature, but ignore the core product for a bit, develop tests for the feature and take time to regression test it when core features around it change. 

I was cleaning up some old basecamp writeboards and found this plan myself and the other software lead/manager created for some (at the time) wild changes to our development process. I’ve annotated the notes below to reflect how the reality ended up.

Goals - faster releases, shorter QA cycles, accurate estimates, better quality

Groups made up of 2 devs and 1 QA person 

This has been a huge success - the focus has become about the team rather than Dev vs QA. The team sizes haven’t always stayed the same, but the concept is solid. 

Group sits together 2 week sprints, entire group is dedicated to the sprint

Again, the focus on the team has resulted in better products

1 product is worked on during each sprint Small releases - even if code isn’t used it prevents large merges

The one product thing is hard when you have legacy products. The only way to do this effectively is to put legacy products in ‘maintenance mode’. No new features and we only fix big problems (which mostly coincide with browser updates). It’s worth fighting for though - limiting the problem set intensifies the focus and produces a better result.

Group members may change from time to time when needed just to keep things fresh and prevent pigeonholing

This hasn’t really worked due to the differing skill sets - we’ve had iOS developers that couldn’t effectively jump to web development and vice versa. We’re taking more care to hire for versatility but it’s likely to be an issue going forward.

QA to run regression every release as a team or rotating assignment

We’re just now making progress here after 18 months of tweaks. In theory we should be able to release after each sprint, but we haven’t been able to effectively limit our regressions, which are lengthy. We see two things that can get us closer to faster releases:

1. Say NO - the more features you pack in, the longer the regression. Keep the focus on the core feature set and iterate on it. In most cases, if you can articulate the above point (more features, less releases), everyone stays happy.
2. Understand what you have touched - Several of our use cases for restricting access are really complicated and take a long time to test (we didn’t always obey rule #1). We try to limit the number of times we touch those bits so we don’t have to do a full regression every release.

At the end of each sprint, developers demo features to Product Owner(s) (and any other interested chickens :-)

Any time you can shorten feedback loops, you should. We’ve fixed lots of design problems based on feedback from demo meetings which previously would have made it into in the hands of our users. We’re actually trying to expand this effort by using tools like Appblade to get as much feedback as we can before release.

Hiring a talented design firm is a lot easier than hiring a talented designer. You don’t have all the overhead that comes with hiring an employee, you get the experience of an entire firm as opposed to a single person and you can fire a design firm with little repercussion if it doesn’t work out.

The single item that makes relying only on an outside design firm impossible is the fact that everything is iterative. It is never the case that the initial design for a product is perfect. You can not tell how a product is going to ‘feel’ by looking at a photoshop document. How a prototype feels isn’t necessarily how the final product feels. Maybe during development you find that you need adjustments due to a performance problem or a changing business requirement. Someone needs to be on the ground working with the team in the trenches making those hundreds of small decisions that are required during the development cycle.

There is nothing like working with a great design firm, I’ve been lucky to work with the best. It’s not enough though, you need to supplement that talent with some of your own who understands your business, products and restrictions. 

Anything You Want was a great, short read. Highly recommended.

Make every decision—even decisions about whether to expand the business, raise money, or promote someone—according to what’s best for your customers.

It’s counterintuitive, but the way to grow your business is to focus entirely on your existing customers. Just thrill them, and they’ll tell everyone.You can’t pretend there’s only one way to do it. Your first idea is just one of many options. No business goes as planned, so make ten radically different plans.

That’s the Tao of business: Care about your customers more than about yourself, and you’ll do well.

Banks love to lend money to those who don’t need it. Record labels love to sign musicians who don’t need their help. People fall in love with people who won’t give them the time of day. It’s a strange law of human behavior. It’s pretty universal. If you set up your business like you don’t need the money, people are happier to pay you. When someone’s doing something for the money, people can sense it, like a desperate lover. It’s a turnoff.

Whoa! Wow. Steve Jobs had just dissed me hard! I was the only one charging $40. That was me he was referring to! Shit. OK. That’s that. Steve changed his mind. No independents on iTunes. You heard the man. I hated the position this put me in. Ever since I started my company in 1998, I had been offering excellent service. I could make promises and keep them because I was in full control. Now, for the first time, I had promised something that was out of my control.

I’ve had my Kindle for 2 weeks and I’ve torn through a couple books from the Domino Series. I was hesitant to buy one for several reasons I won’t get into but it’s really fantastic. The highlighting feature is hugely useful. Here’s what I highlighted in Seth Godin’s Poke the Box:

Doug Rushkoff and Mark Fraunfelder have both written about the new willingness to surrender control to the objects and organizations in our life. As soon as we willingly and blindly accept what’s given, we lose all power. Only by poking, testing, modifying, and understanding can we truly own anything, truly exert our influence.

In the short run, playing your strongest player, following the play-book, rewarding someone who has done it before—these are all great ways to win. In the long run, though, all you’ve done is taught conformity and punished initiation. One reason organizations get stuck is that they stick with their “A” players so long that they lose their bench. In a world that’s changing, a team with no bench strength and a rigid outlook on the game will always end up losing.

If you hide your spark, bury your ideas, keep your questions and notions from the team, you have hurt them as badly as if you had stolen a laptop and fenced it on eBay.