Sanaz Ahari: “Just ship it!” 06 Mar 2006
13 comments Latest by sanaz
A lot of people think Getting Real is impossible inside a large company. But even if your company typically runs on long-term schedules with big teams, there are still ways to get real. For the book, we asked Sanaz Ahari, Program Manager of Start.com at Microsoft, to discuss the “Just ship it!” attitude that her team uses.
Just Ship It!
In big companies, processes and meetings are the norm. Many months are spent on planning features and arguing details with the goal of everyone reaching an agreement on what is the “right” thing for the customer.
That may be the right approach for shrink-wrapped software, but with the web we have an incredible advantage. Just ship it! Let the user tell you if it’s the right thing and if it’s not, hey you can fix it and ship it to the web the same day if you want! There is no word stronger than the customer’s - resist the urge to engage in long-winded meetings and arguments. Just ship it and prove a point.
Much easier said than done — this implies:
* Months of planning are not necessary.
* Months of writing specs are not necessary — specs should have the foundations nailed and details figured out and refined during the development phase. Don’t try to close all open issues and nail every single detail before development starts.
* Ship less features, but quality features.
* You don’t need a big bang approach with a whole new release and bunch of features. Give the users byte-size pieces that they can digest.
* If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that.
The faster you get the user feedback the better. Ideas can sound great on paper but in practice turn out to be suboptimal. The sooner you find out about fundamental issues that are wrong with an idea, the better.
Once you iterate quickly and react on customer feedback, you will establish a customer connection. Remember the goal is to win the customer by building what they want.
[From P. 11 of Getting Real, the new book by 37signals that helps you discover the smarter, faster, easier way to build a successful web application.]
Also, here’s what Robert Scoble, Technical Evangelist at Microsoft, has to say on the subject:
I notice that as I go around Microsoft the teams that are doing the most interesting stuff are really the small teams. In fact, the products you probably know the most at Microsoft. .NET. Xbox. Tablet PC. Were done by small teams.
Yes, there are things that need big teams. Windows, for instance, has thousands of people working on it, but each task is ultimately split up to a small team.
I like 37signals because of its tight coupling to customers and its small team that has a very high focus on shipping. Ship great stuff fast.
I meant it when I said big companies like Microsoft could learn something from small companies like 37signals.
13 comments so far (Jump to latest)
dmr 06 Mar 06
Just how many people are in the teams at MS that Scoble is talking about?
RMG 06 Mar 06
It takes over a week at my shop to fix a typo. Count yourself lucky if you never have to deal with the nightmare called ITIL…
Mark Gallagher 06 Mar 06
It’s very tough for small teams in big companies to function like 37signals.
I agree the themes of your book are useful to big companies. But the amount of internal process is directly linked to the size of the organization.
Big companies go through cycles where they centralize decision making (adding bureaucracy, slowing innovation) and then they realize they have gone too far so they announce they are moving decision making to small teams in the field.
But the change is usually small and they cycle back to centralized decision making soon enough.
Some big companies do this (act small) better than others (like Apple), but it’s very hard as you get big.
37signals should stay under 10 people and make fewer than 10 products. Despite the excellent themes in your book, it will become increasingly difficult to follow if you get bigger.
Thanks.
Mike 06 Mar 06
I’m all for less meetings but not crazy about the customer telling me what is wrong with my product. So often, you have one shot at winning a customer and if the product doesn’t function correctly, they will go someplace else.
scott 06 Mar 06
…and subsequently return as soon as you fix whatever was broken. and likely become fans of your company in the process, not just your product.
i mean exactly how many customers react negatively to a company that responds to their needs?
Edmundo 06 Mar 06
What is the difference between start.com and live.com? One looks more like the google personalized home than the other, but other than that…
Mike 06 Mar 06
Scott
…and since they have likely purchased a functioning product from somebody else, how exactly do you plan to re-win them over? Undercut on pricing? Other incentives? You’ve already lost the opportunity at that point.
Danno 06 Mar 06
Honest question: How does this mesh with the no betas mindset?
I mean, I thought beta meant feature complete but with various grotty spots?
Isn’t the idea of Just Shipping It very close to releasing a beta?
Greg 06 Mar 06
Nice - 37signals is taking advise from Microsoft (who I personally don’t believe is as evil or bad as 37signals makes them out to be).
This post makes me very happy.
scott 06 Mar 06
Mike:
if they bought your product, stopped using it because they disliked it, and bought another, why wouldn’t they do so again?
if company B had a better product in the first place it wouldn’t be your customer to win back.
maybe you’re focusing too much on the short term?
all software requires upgrades. when a customer shops around for the latest version, you can be ready and waiting with a product that addresses all of their concerns, or you can bitch about how you never get a second chance to make a first impression (and other tiresome, outmoded cliches).
with a subscription model, you’ve got a month to regain their confidence and business. hell, they don’t even have to be looking for the latest version; provided when they signed up you gave them the option of receiving news about your software, you can email them a little heads up that you heard their complaints, addressed them, and here’s a free trial to see for themselves.
or you can pretend it’s all hopeless and no one ever tries something twice.
a scientist 07 Mar 06
@scott: “all software requires upgrades.”
you know, i’ve been thinking about this particular supposition for quite a few years now. when is software “done?” is there ever a point when a company should say, “that’s it. it’s done.”
i’d like to know if the signals think that basecamp or backpack will ever be “done” or if that’s a goal. or if it’s possible at all. is “done” a part of “getting real?”
it seems to me that the “less” line of thinking feeds directly into a terminal end. i think “done” is a good thing. for example, to the end user goggle search is “done.” it works how it works. there may be technical improvements that users don’t see, but the functionality is done.
thoughts?
scott 07 Mar 06
if it’s functional, it requires maintenance.
users change. the environment changes. requirements change.
time reveals security issues, usability issues, growth issues, et al.
the “less” line of thinking doesn’t imply “terminal”; it means recognizing and doing what is required at this time.
why refuse to rely on the strength of adaptability?
sanaz 28 Apr 06
you love me