You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Ask 37signals: How do you say no?

Jason Fried
Jason Fried wrote this on 25 comments

Greg asks:

When your product just launched and the user base is starting to grow, you’re happy about any positive feedback you receive from your first users. But just as soon, you start receiving feature requests from the same users. While it’s easy to say “No” to a feature as a team internally, I found it less easy to tell a customer that their suggestion won’t see the light of day anytime soon (for any number of reasons). How do you respond to such requests — especially when the feature “makes sense” as an extension but might be too much of a niche (a power-user feature) or not a top priority right now. The answer might be to just say it, but I thought I’d ask anyway to see what your experience has been and how users responded.

We say no to a lot of ideas — including most of our own ideas. But it’s important to remember that no can be temporary. No now may be yes later. Or it may be no forever. The trick is to figure out which camp a certain no falls into and then respond appropriately.

For example, if someone asks you to add something to your product that you absolutely know you won’t be adding (Gantt charts to Basecamp, for example), you can be clear. “We appreciate the suggestion, but we will not be adding Gantt charts to Basecamp. We’ve taken an entirely different approach to project management with Basecamp…” And so on. If you are going to give an absolute no, it’s nice to briefly explain the thinking behind that decision. It helps people understand that you’ve thought about the no.

However, if the idea sounds reasonable and interesting, but you just don’t have plans for it right now, you can turn that no into a thank you. “Thanks for sending the suggestion over. While we can’t guarantee we’ll be adding this feature, we can promise you we’ll review it and possibly consider it for a future version.” Even though we say no to just about everything by default, we do read and consider every suggestion. Some make it in, some don’t. Some show up in weeks, some may take years. Plans change, markets change, products change.

But most of all, being clear, direct, and honest is the best policy. Don’t string a potential customer along. Don’t make promises you can’t keep. Just be clear and set realistic expectations. Telling someone yes when you really mean no is a recipe for a bad experience down the road.

Padded link targets for better mousing

Ryan
Ryan wrote this on 44 comments

Among the minor tweaks we introduced with the new Basecamp project switcher are some larger link targets at the top of the screen. Since then I’ve been paying extra attention to link target size. Here are a couple examples of generous link targets for inspiration.

Threadless has featured large link targets on its main navigation for a long time. Here’s what the nav looks like:

Threadless links

As a user, when you glance at this nav, you might imagine the specific pixel areas that you need to target like this:

But when you move your mouse toward the nav, you’ll be pleased to discover the actual link targets are much larger:

The end result is a feeling of comfort. It’s just really easy to click the links. It feels like the links are working with you instead of against you.

Flor does the same thing with their links. Here’s the navigation:

Here are the targets you might aim for:

And here are the actual targets:

You might have noticed both of these sites use images for their navigation links. The same effect is easy to achieve with HTML links. Just use padding where you might have had whitespace.

Normally you might have white space between your links like this:

<div class="nav">
  <a href="">First link</a> <a href="">Second link</a>
</div>

Instead, use clickable padding on the anchors to create space between them:

<style>
  div.nav a { padding: 5px; }
</style>

<div class="nav">
  <a href="">First link</a><a href="">Second link</a>
</div>

Note how the anchors touch each other with no white space in the second example.

We do this in quite a few places in our apps and think it’s one of those small things that makes a big difference.

How "Why Startups Fail" Fails

Jason Fried
Jason Fried wrote this on 41 comments

David Feinleib at Mohr Davidow Ventures pens a piece called, “Why Startups Fail.” Here are his four reasons with my thoughts below.

1. Spending too much on sales & marketing before they’re ready

This is exactly why we encourage new companies to stay as far away from venture funding as they can. VC’s encourage you to spend! And since software is virtually free, and hardware is dirt cheap these days, and you only need a couple people to get your company and product going, the only place to spend your money is on sales and marketing. And spend you do, cause there’s nothing easier in this world than spending other people’s money.

2. The market outpaces the startup’s ability to execute

I hear this one discussed a lot, but I rarely see evidence of its impact. The market doesn’t really move that fast. Things generally move pretty slowly. Consumers move even slower, and consumer loyalty is built through great experiences over time not through early availability. First mover or early advantage is overrated. Google was late to search, Flickr was late to photosharing, Facebook was late to social software. Being late gives you a chance to watch the market develop and spot what’s actually working and what isn’t. Take your time, build something valuable, and then go to market. No, you can’t wait 36 months to release something that’s 3 years behind, but if you’re a few months “late” (whatever that means), and you’re great, you’ll do just fine.

3. There is no Entrepreneur

This one I do agree with. Every great company has a great leader who is willing to make decisions, say “no” more often than “yes,” and see a clear vision through to fruition.

4. The market takes too long to develop

If the market takes too long to develop, there is no market… it doesn’t exist. Unless you have one of those rare products that can create a market, you’re dropping a product into a void. So don’t blame the market, blame the entrepreneur’s judgement.

(One other thing)

One more thing I want to comment on. At the end of the article there’s this sentence: “A startup that struggles for reasons beyond the entrepreneur’s control.” This deflects blame in the wrong direction. If the entrepreneur finds themselves in a situation they can’t control it’s almost certainly because they put themselves in that position — either by borrowing too much, spending too much, rushing too fast, creating a false sense of urgency, hiring the wrong people, attacking a market that doesn’t exist, or not focusing on generating revenue early enough. Natural disasters are out of our control, bad business decisions are in your control.

(And another thing)

“It’s not just how fast you run the race that matters. It’s how fast the race is run. When it comes to startups, speed wins.” That’s just ridiculous.

Ask 37signals: How do you handle disagreements?

Jason Fried
Jason Fried wrote this on 12 comments

BJ asks:

How do you handle disagreements? What happens when David and Jamis disagree on the best way to implement something? What happens when Ryan and Jason disagree on the best way to interact with a new feature? How do you avoid arguing for hours about the (seemingly) tiny details?

Luckily, we don’t run into extended disagreements all that often. Disagreements can certainly be a good thing from time to time, but extended ones often have a negative impact on morale. We try to treat morale as the most important limited resource we have.

But when we’re deadlocked, eventually (usually 10-15 minutes into a discussion) someone is going to propose a solution. The solution usually involves the stronger advocate taking full responsibility for the decision.

For example, if Jamis feels a lot stronger about something than David does, Jamis will “win” but he’ll also be responsible for any bugs or support related issues due to this decision. This forces the winner to think about if they really believe in their position strongly enough to deal with the possible demands on their time post launch. If they still do, they usually accept the deal. If not, the “loser” gets his way without the support strings attached.

That’s just one example. It doesn’t always work this way, but that’s been a successful model we’ve used in the past.

One thing to keep in mind is this: Make sure you’re disagreeing on point. It’s really easy for arguments and disagreements to flare up quick. Flare-ups often lead to two people talking right past each other. They stop arguing with each other and instead argue at each other. At that point the discussion is lost and someone has to rein it back in.

Got a question for us?

We’ve received over 100 “Ask 37signals” questions so far. If you have a question about design, programming, entrepreneurship, marketing, or anything related, drop us an email at svn at 37signals dot com and include “design decisions” in the subject line. Thanks.

Let's forget about Google, Apple, Microsoft, Amazon, and Facebook for a minute

Jason Fried
Jason Fried wrote this on 108 comments

A lot of entrepreneurs are inspired by Google, Apple, Microsoft, Amazon, Facebook and other megacompanies. But let’s face it — these are outliers. They are exceptions. They are the rarest of rarest cases.

That’s not to say they aren’t worth paying attention to, dreaming about, and otherwise admiring, but it’s handy to have success stories that are a bit more common scale. A company doesn’t have to earn billions to be a great inspiration for budding entrepreneurs.

So, ignoring the usual suspects for now, which companies inspire you? Which companies do you respect enough to say “I love what they’re up to. We’d like to achieve their level of success.”

Shout-out: Mix 1 protein drink

Jason Fried
Jason Fried wrote this on 46 comments

I’ve been looking for a modest protein drink that doesn’t taste like a protein drink. Something silky smooth, not grainy thick. Something with some legitimate flavor, not sorta flavor. Something all natural, not mostly natural.

I finally found one I like. It’s called Mix 1. All natural, 200 calories, 15 grams of protein, 2.5 grams of fat, 3 grams of fiber. 22 grams of sugar, but that’s not too bad.

I’d been buying them at a local market and at Whole Foods, but I just discovered that Amazon sells them by the case as well. With free shipping and no tax it’s an especially good deal.

So if you’re in the market to add some quick protein to your diet, check out Mix 1. It’s a nice product.

"Owning the launch too" and "The 2-week plan"

Basecamp
Basecamp wrote this on 28 comments

A couple of new internal rules at 37signals that we thought we’d share:

Owning the launch too
Lately we’ve had a couple of features, fixes, and tweak lately that have been sitting idly done waiting either for deployment or for input from someone else like design.

So we’re establishing a ground rule: If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving. And do it forcefully.

If you’re a developer and you need input from design, grab a designer and tell them that the feature won’t launch until they deliver X. That’ll get ‘em fired up to get it done!

If you need to have the feature deployed and you’re not confident doing it on your own, book a specific time with Mark to make it happen, so you both can be around.

It feels great to be done with something on the programming side and then feeling free to move on to the next thing. We all do that at times. But it’s not really real until our users are able to enjoy it.

The 2-week plan
We’re also worried that we’re keeping our heads down too long on projects. We’re not stopping, looking around, and deciding where to go next early enough. Things are lingering too long without reality checks.

So here’s the rule moving forward: If someone is working on something for two weeks, stop. Then post a message to the Basecamp project. Use one of three choices (you can also pitch multiple options):

1. Provide an ETA on completing the project and create corresponding milestones in BC for the phases/completion.
2. If you don’t see an end in sight, ask for judo help to get it done sooner. Always consider that there’s a significantly simpler solution than the one you are working on.
3. Suggest abandoning/shelving the project.

The goal here is to not let weeks and weeks and weeks pass before deciding to either judo something or kill it. We’re not using our time efficiently if we’re tangled up and not asking for help. There’s no pride in pushing through something without being able to see the end.

Launch: The Backpack Journal

Jason Fried
Jason Fried wrote this on 64 comments

A few weeks ago we gave everyone a peek at in/out, our internal app for keeping track of who’s doing what and what everyone’s recently completed.

We mentioned that we were considering building it into Backpack. Today we’re pleased to announce that the Journal is now part of Backpack. Just log into your Backpack account and click the Journal tab. The Journal is available on all plans—from free to Max.

The Journal eliminates the need to constantly ask each other “What are you working on right now?” and “What did you do today?”

Watch a video

A full-size video is also available.

RSS and an API too

As part of the Journal launch, we’ve updated the Backpack API to include journal entries and status listings. We’re excited to see what people build with the journal API.

The Journal also has its own RSS feed so you can keep up to date on what people are doing without having to log into Backpack.

We hope you find the Journal useful

The Backpack Journal has become an integral part of our work day. We’re checking it all the time to see what everyone is working on and what’s been finished. We don’t have to bother each other to find out what everyone is up to. It’s a huge interruption saver (and we know how interruption is the enemy of productivity).

Special thanks to Jamis for prepping the Journal for launch and documenting the API at the last minute.

The infographic that saved a million lives?

Matt Linderman
Matt Linderman wrote this on 10 comments

“No graphic in human history has saved so many lives in Africa and Asia,” says NY Times columnist Nicholas Kristof about an infographic in a ‘97 Times article that spurred Bill and Melinda Gates to take action on public health.

in september i traveled with bill gates to africa to look at his work fighting aids there. while setting the trip up, it emerged that his initial interest in giving pots of money to fight disease had arisen after he and melinda read a two-part series of articles i did on third world disease in January 1997. until then, their plan had been to give money mainly to get countries wired and full of computers.

bill and melinda recently reread those pieces, and said that it was the second piece in the series, about bad water and diarrhea killing millions of kids a year, that really got them thinking of public health. Great! I was really proud of this impact that my worldwide reporting and 3,500-word article had had. But then bill confessed that actually it wasn’t the article itself that had grabbed him so much—it was the graphic. It was just a two column, inside graphic, very simple, listing third world health problems and how many people they kill. but he remembered it after all those years and said that it was the single thing that got him redirected toward public health.

No graphic in human history has saved so many lives in africa and asia.

The piece says that Jim Perry, a veteran graphics editor, produced the chart. Too bad the actual graphic isn’t shown though. It’d be interesting to see. Update: The chart is below (source).

chart

Continued…