I’ve been posting raw notes from panels all morning. I blogged about Beyond Folksonomies over at the blog for my book, The Power of Many and I blogged a presentation by a Harvard psychology professor about why people make poor decisions, How to Do Precisely the Right Thing… on my personal blog.
I’ve just been taking notes at the keynote conversation and it’s the first topic of the day that I thought was appropriate for Extra! Extra!
Both Coudal and Fried were witty speakers. Coudal led off and made excellent points about the importance of curiosity and a willingness to learn with each new project and then Jason took over with his familiar rants about not overengineering things and how functional specs are the devil.
Here are my raw notes from the discussion, printed as is in the spirit of launching a 1.0 version with limited time and effort and then revisting later (maybe) to improve it:
Jim Coudal
Imagine “Chris” – your friend who’s hipper to you than everything, used to have a band, then was making indie films, now building a tagging web 2.0 social web app
Noticed a trend in SXSW panels: used to be about making tools, now about making real businesses with those tools
37 signals (Jason’s company) used to do client work, now they do: ruby on rails, econferences, books, backpack / basecamp / campfire / ta-da lists
Coudal partners still does some partner work, mostly naming and identity work but also has some business: jewelboxing, the show (on tour with bands , record / mix / master / design / manufacture / fulfill limited edition concert dvds), the deck – targeted ad network (includes only signal vs. noise, the mighty, a list apart, waxy.org, and coudal.com).
When someone says they work in-house as a creative at product company, Jim smiles nad nods, thinking: awful newsletters, Comic Sans, sales videos based on the reality show of the moment, cubicles full of toys.
Running the whole show is better than being an employee. It’s better to be the boSs than to work for the boss. But there are always problems. Example, with products: fulfillment, for example, a minefield, though: international shipping / customers regulations, etc. Part of craft is to be able to learn quickly
Questions Coudal asks before taking work:
- Will we be able to do good work?
- Will we be able to make money?
- Will we be able to learn a little something new along the way?
These criteria are not equal. Sometimes we take a project to do good work but get mediocre pay. Sometime the reverse (not proud of this). We won’t do mediocre work for mediocre pay. We won’t do a project where we can’t learn something new along the way
In work-for-hire world you must be flexible, curious, learn quickly. It’s always a new industry with a new problem. You need to be able jump right into the deep end of the school and start swimming, and we’ve got to like doing it.
The meek won’t inherit the earth; the curious will.
Jason Fried
on “the how”
How to take skills and turn them into a business. Now we all know css, blogs, semantic web, web standards. Starting something new is intimidating.
One way to start is to quit your day job, business plan, predict the future, get vc, hire, get office, aluminum sign with neon backing on your web page. That way is expensive and stressful, doesn’t put the product and customer first, puts the investor first.
Fried’s advice:
- don’t quit your day job
- don’t get money, hire
- start something on the side
Examples: delicious, basecamp (launched on 10 hrs. a week – “we were a consulting company”), jewelboxing, blinksale (josh williams)
advantages:
- obscurity
- less
Obscurity:
You learn more by failing in obscurity without the ego-hits, public criticism – removes fear of failure.
Less:
Less comes for free, is a plus not a minus, underdo: simplicity, clarity, work well, not too clever (one-down, not one-up) – less time is good, avoid overwork (functional specs, abstract things, wasted time, procrastinate… then rush), don’t try to be big, less red tape; less money is also good… you don’t need a lot of the stuff you think you need — 6 yrs. ago companies were spend millions on oracle, windows servers they didn’t need, insane scaleability (“ridiculous bullshit”).
Now, infrastructure software is fee, hardware is cheap (basecamp had one app server for one year, $150/month – don’t need all this redundancy, terabytes of tape backup), you need money for salaries, but if it’s on the side it’s just you or your partners also donating time
Seeing the 90s mentality again: Get $2 million bucks…. let’s get some nice desks, aluminum sign, etc.
Polish 10 features instead of 50 mediocre features. Get a few things right. There’s an endless amount of time to add stuff later. You can’t take things away.
If you make a big huge thing, tech support will kick your ass.
Build simple software that does a few things very well, not clever (like software we all hate: the kind that capitalizes for you). Software is not the solution to everything. Don’t build software that gets in people’s way. Build less software. That clever stuff takes a lot of time.
One “more” thing: more constraints
Bootstrapping model. Jason is anti functional spec. Just use it as you build it and you’ll learn what it needs to do.
Question and Answers
Coudal on web design: Use a subtractive process, take away what you don’t need (like Hemingway’s comment about writing).
Fried on venture capital: With vc money, you keep needing more of it, series a, b, c; those who don’t take it always seem to have enough.
Fried on hiring: Don’t hire with a long bullet list of expertise requirements. you want passionate, curious people who can learn what you need to do. are you good at what you do, motivated, passionate, curious
Fried on making money: How do make money? charge for your work. Charge a monthly fee. Everything doesn’t have to be free. It’s hard to make money from advertising. Also, lower-paying customers complain more. When you make a change for the better, people still bitch. Resist the urge to change it back just to please them. Wait them out.
Fried on functional specs: Why do I hate functional specs? They are political documents. They are about covering your ass. “We all signed off on it and we all agreed on it.” Mostly they’re illusions of agreement. (It’s usualy a matter of interpretation.) We build the interface first… we build it in HTML… you can all touch it, agree on real stuff.
Very little cost is involved in adding in a new feature to a functional spec…. In the real world there are real costs involved
Coudal on RFPs: “The RFP” rule. If the RFP is more than two pages, we won’t do it. If they spent all that time, imagine what a pain they’re going to be on the project.
Coudal on a possible motto: we’re making it up as we go along
Question: I work for Yahoo and we write functional specs. Eliminate them and a few people will lose their jobs. How to migrate to a better way? Isn’t it utopian to eliminate specs?
Fried’s reply: What’s utopian is thinking you know everything about how the app should work. We don’t know anything. What we do is write stories… we keep them to one paragraph. The story is a scenario, not technical or confusing. If necessary, we’ll mock it up to show how it works
Fried on specialization: When you’re small, you want to be generalists… don’t be just an information architect.
Fried on scope creep: We fix budget and time frame… whatever fits is version 1… adding more time and money will add scope.
Update: Scot Hacker took notes on this panel too.
tags: sxsw2006, sxsw