In my mind, good product design cannot exist without constraints. If you have infinite time, money and developers and you develop a great product, so what? You’re were expected to do that. Coming up with a great product when you have 2 months, a small team and limited degrees of freedom, that’s something I really admire.

At a startup, you are, by definition, in a resource-constrained, time-sensitive environment. If you’re not, you’re over-funded, not paranoid enough and you’re likely going to be overtaken by someone hungrier and scrappier than you.

Define the dream product

At the start of the design phase, you still have to sit down and think about your ideal end state. The question you have to answer is, what do I need to build to delight my chosen audience. How can I make a product they will love to use and talk about.

Werner Vogels has a great post about Amazon’s approach:

The product definition process works backwards in the following way: we start by writing the documents we’ll need at launch (the press release and the faq) and then work towards documents that are closer to the implementation.

The Working Backwards product definition process is all about is fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build.

In this phase, you shouldn’t close yourself off. Seek input, talk to current and prospective users, talk to people within your company. Having said that, advance your vision, don’t design to achieve consensus. To quote a friend of mine, “that’s how crappy products get built.”

Face facts

Once you’ve designed that ideal state, you need to face reality. The basic questions:

  • How long will the ideal state take to build?
  • What is the minimum functionality needed?
  • Are there intermediate steps that can be taken en route to your final goal?
  • Are there features for which the cost/benefit equation does not make sense?

Decide where to compromise

What you’ll find is that your development team will tell you that the 3-d DHTML spinning picture cube will require a fundamental change in image handling and they’ll ask you whether users absolutely have to have this. If so, why? In some cases you’ll need to go ahead and build it anyway, in others, you’ll accept that perhaps this feature can wait.

S ome of the hardest design tradeoffs come when deciding between features that payoff in the short term versus features that pay off in the long term. For example, when designing a deals site, creating better deal pages clearly pays off for the business immediately but making it easier for users to post deals only pays off in the longer term.

Deciding how to balance long term versus short term payoff is one of the hardest elements of product design. It’s human nature to look for the quick hits but if you constantly borrow from the future to fund the present, you’re going to end up in a place you don’t like.

There will be pain and that’s a good thing

As your design progresses from an idealized version to the product you can actually get released, there will be pain. Designers will cringe as functionality is cut down and developers will be unhappy because they are being pushed to do things that are hard. I think this is healthy. If you don’t have tension between product management/design and development, you’re not making good choices.

Build it and release it

The most important thing to do here is pick a date and start trying to hit it. You may learn things as you get into development that force you to adjust your date, but that’s ok. Until you are confronted with the harsh clarity provided by a deadline, things just don’t happen quickly enough. There’s a lot of talk and hand waving, but the real issues don’t get surfaced. People will complain - management will tell you it’s taking too long and developers will tell you there’s not enough time. Welcome to product management. This is normal and healthy.

While you’re developing the product, don’t forget about things like messaging and managing user transition. It will bite you in the ass if you release a new product and don’t tell people where the old product went. We experienced this first hand with our initial home page change as we transitioned from reviews to deals. A flurry of angry user emails and blog posts greeting us within 30 minutes of release. We ultimately gave legacy users their old home page back but showed new users the deals home. Trust me, this is not fun. Avoid it if you can.

You’re not done. Measure & Iterate. Do it Quickly.

While we are all convinced that our initial designs are great, chances are, they will need to evolve. Early in our deals history, we released what we thought was a store page updgrade and watched as our on-page conversion to click was cut in half. In today’s world with tools like Google Analytics it is criminal to not measure where users are coming from, what they are doing and where they are going. As an organization, we haven’t been great at this. We’re getting better, but need to keep pushing ourselves to do more.

Unless you’re measuring how your product is performing, you’re not going to learn what to change. Once you know that, you then have to have the discpline to iterate quickly. This is hard because you probably didn’t release everything you wanted in the first place and need to add in features you left out while at the same time improving what’s already out there and dealing with user issues and bug fixes.

It’s supposed to be hard

Clearly, you’re sensing a theme here. Product design and development requires tough choices and it requires you to be flexible. This stuff is not supposed to be easy - we’re trying to create value here. Dave and I were having a conversation last night in which I was talking about some of these choices and Dave simply said, “There are always going to be tradeoffs, you’ve got to figure that out.” Dave is almost always right.

Constraints force you to be creative, to make good decisions and to work hard. If you do it right, you creat value for users and ultimately, that’s what you have to make happen if you want to be successful.