BlogSat

One of my favorite frameworks to think about building and shipping products is Larry Keeley 's Desirability-Viability-Capability model. Most great products get these three aspects right... or right enough; inevitably finding the balance and making the right trade-offs is part of the journey. In the book I've linked above, Alan Cooper suggests the way to find that balance is to have 3 different people responsible for each aspect. He suggests the Engineering Lead worries about Capability ( i.e. what's possible and how to do it) , a UX Lead focus on Desirability (i.e. what makes your users love the Product) and a Business/Product person own Viability (i.e. why will this work and how to get it there.) He makes the case that this is necessary not only because these are different skills that require specific training and instincts, but also because of the tension between them and focus each requires. I'm curious what people think though, and how they approach this. Often ...

Painters and sculptors sign their art. Writers have their names on the jacket of their books. Journalists get bylines. Their name is forever tied to the what they worked on. Some of this is the narcism that we all have and the desire to mark ownership we all crave, but I remember reading that it started as a way to take responsibility. You put your name on what you worked on so that people would know that it was your brilliance, and your errors and faults, that were on display. A question that I'm now teaching myself to ask and wish more people shipping software would ask themselves is "Would I ship it if it had my name on it?" Not just my company's or my products, but mine. Releasing products, especially in a fast-moving industry and in a launch-and-iterate culture is often about what you leave out, and what you will get to later. You have a vision to begin with or at least a plan, but then as deadlines approach or other evil things happen, you decide what features...

I got the reminder to install a bunch of stuff from Apple on my machine from their Software Update  Tool (iTunes etc.) So I did. It went as planned. So what's the point of this post?  After the installer runs, what does it do? It shows me the dialog again. I know, its a minor thingy, but still: I needed something to complain about today.:) Don't ask me if I want to run something after I just ran it! C'mon

It was a more innocent time: a long, long time ago. I still thought I was young, couldn't complete a sentence without trying to work in a pun, and my parents were still asking me questions like, "So how do we turn on the Internet?" OK, lying a bit about the last one; they'd stopped asking that much earlier. But about two-ish years ago when someone first told me about a startup called Writely that wasn't half-bad, and everyone couldn't stop talking about the inevitability of the online office suite, I'd heard an interview with a Microsoft Product Manager, who was rolling out a collaboration suite for Office products (which after all of Msft's branding fits and feature roll-backs is now called: Office Live Small Business and has fewer-even-than-promised features) . He maintained (I paraphrase from memory now), "We don't think there's much value in an online office suite. We believe that people want to collaborate online and share docs, ...

I finally finished "Dreaming in Code" by Scott Rosenberg last week. I absolutely loved it! (BTW, it was brought to my attention that I seem to "absolutely love" everything I review/watch. The person who pointed this out believes its a personality trait/problem.) The book chronicles the development of "Chandler" , an open-source Personal Information Manager whose development was sponsored by Mitch Kapor . However what makes the book so great its use of this story as a way to frame explanations and discussions about the development, design and process of software. While reading it, I found myself smiling and nodding in agreement with so many issues and situations I recognized from work, and from school; issues fundamental to writing software, issues unavoidable in managing large software projects and frankly so many things I thought we did so well at work (when I say "we" here I really mean my managers.:)) I also ended up learning a lot: about th...