spencerfry.com
Original comment thread: http://news.ycombinator.com/item?id=779378
1) You said that the business guy should keep his eye on the macro focus. I find myself doing this to a point of fault. One of my cofounders works in the same room as I do and one day he just had to say: "Look, I can't work with you talking about the future all the time, we need to keep our heads down and develop at this exact moment." I'm curious: do you guys have physically separate work spaces or are you just better able to control your forward looking urge than I am?
2) Customer service: I've taken over most of this, and it's been great. I love interacting with customers (even if I get some requests about a hundred times), and as we grow, I'm ecstatic to report it's eating up larger and larger chunks of my day. Eventually I'll have to figure out a way to continue producing new content (I double as the designer, but I traded that workload with our third guy for the book keeping), but for now it's great. I was curious, we have a one day policy so that people always get a response in a day, oftentimes it's much faster, but sometimes we'll be focused on designing a new feature together, it slips. People have told us they don't mind getting a response one or two days after, do you think it's worth investing high energy in making sure it's super fast?
3) We've been having troubles with our user's guide and we're thinking about pulling it altogether in favor of a more dynamic feature-specific overlay system. We're keeping the FAQ though. Do your customers appreciate a user's guide because it's a collected resource, or do you think it would work as an enhanced tooltip system? This is just personal style, but I was curious.
Again, I really appreciated your comment back when I posted, and this blog post is great. Thanks for helping me out.
1. Dave (designer) works in our NYC across office right across from me (http://www.carbonmade.com/blog/2009/09/24/150000-portfolios-...). Jason (programmer) works back in Chicago and is moving to NYC in May or sooner. What I find works best is to plan for the future, but not to necessarily bring it up with the other folks until it's time. I actually find myself saying "let's focus on the present" a lot more than I find myself sharing my thoughts for the future. Sharing those thoughts are best left for when you've completed a new version or a major segment of your product. Keep everyone focused on the task at hand and bring out your plans for the future only at the appropriate times.
2. Someone mentioned in a response to one of my posts (and I'm paraphrasing) that "a response to a support ticket takes the same time today as it does tomorrow, so you might as well answer it today." I think that's very true. You shouldn't let it derail you if you're deep in concentration, but if you see it and you can take a minute to respond, why not respond then and there? By responding it won't weigh on you for the rest of the day and affect your other work.
3. What troubles have you been having? I think the decision of having a user guide or not should be based on whether your product needs one or not. Luckily, ours is simple enough that a few FAQs do all the work for us.
Let me know if you have any other questions here or via email [at] spencerfry [dot] com. I'm also open to having lunch/coffee/beer with you if you're in NYC at any time.
Here's the original thread: http://news.ycombinator.com/item?id=779378
Thanks for sharing!
2. Doing all the business related tasks.
3. Doing all the customer service.
4. Handling all incoming e-mail.
5. Doing all of the social networking stuff (facebook, twitter).
8. Tracking all of our expenses, etc., into Excel and getting everything ready for accountant (see 7).
13. Handling payroll. I do that.
14. Dealing with the bank accounts. I deal directly with the small business rep at our bank.
16. Handling all incoming advertising requests, setting up their campaigns, etc.
17. Dealing directly with all our merchants (credit cards + PayPal). Dealing with the very few chargebacks we receive.
18. Paying all of our bills (server expenses, software licenses, domains, advertising, etc.) and monitoring our cash flow.
20. Anything that requires a phone call. Incoming or outgoing.
1. Writing the copy for the website. Mainly keeping the support documents up-to-date.
6. Doing all of our marketing. Handling Google AdWords, banner advertising, text advertising, etc.
7. Dealing exclusively with our accountant
9. Handling all legal work with our lawyer.
11. We all come up with ideas for product development.
10. Doing all of our networking. I'm the guy that goes to all of our relevant events.
12. Blogging. I do all the blogging.
15. Market research. I find out as much as I can about our competitors, what they do, etc. I also learn about our market as a whole.
19. Pitching. I handle all of that.
If the scope of business and the size of the startup justifies it a business minded founder can certainly be a good thing.
And it allows the business guy to grow. Eventually you will want to have a business guy anyway, so it's a sound approach to train him from day 0.
As a very technical, yet non programming, individual who is interested in start-ups and entrepreneurship, I really appreciate this list. As I work on my MBA and dream of one day starting my own company, I often wonder if I should relearn programming or focus on other skills. The more I think about it, the more I realize that my time would be better spent actually running a company and letting others program. Your list is a fantastic resource for the things I need to be thinking about and learning in order to be better prepared!
It was a little depressing to read that list b/c I have to do all that stuff and code, and I'm doing it part time. Very jealous of the people working full time.
While today, it's amazing to have Spencer taking care of these things, delegating my workload in the beginning was a bit painful. We had stacks of paperwork to exchange and coordinate with our lawyers and accounting company. With OCD, was also difficult not to nit-pick ever single detail in the beginning. But as it began evident that he knew his shit (having ran several companies before joining us as an equal partner), these tendencies quickly subsided and our productivity skyrocketed.
Just to disclaim my bias: as a designer, I've slowly dropped the more esoteric UX/interaction tools like card sorting or mental models over the last 2-3 years as I've focused more on startups but usability testing is the one most resistant to being dropped and I still see it as pretty much the gold standard of design feedback.
I think we'll get more heavily into some A/B testing, but really only on select pages. For example, I want to set up A/B testing for our new sign up page. Right now you can't upgrade immediately when first signing up. You instead need to sign up for a regular Meh account and then upgrade to Whoo! later. I want to test allowing people to upgrade immediately when they first sign up and see how that goes.
That works pretty well for a v1, Tim O'Reilly had the colorful phrase "fishing with strawberries" to explain why it works so well:
http://www.oreillynet.com/pub/a/oreilly/tim/articles/straw.h...
I'm down with user feedback and a/b tests, I guess I was asking specifically about usability testing though since I don't see it talked about much around here. It's categorically different from the other stuff and yields much more qualitative insights (why did they just do that?) versus the more quantitative results (which page layout has a higher conversion rate?). Plus it's actually a hell of a lot of fun to do! If done right.
"On one level, the difference between the two points of view is simply the difference between selling one on one to a very targetted prospect and selling to a mass market, where you are casting a wide net, and some set of potential customers will match your own "strawberry" profile."
Product testing is really everyone's jobs (in software it's much easier to manage your app if it's something you engage every day).
Great list though!
I'm just curious, as I'm doing Ruby (for the obvious RoR), but python also seems smart.
Or would recommend people start more basic, like with Scheme or something? Scheme was my true first language in school way back when, but I think others could benefit from a comment that dealt with some advise on recommendations about languages that I'm not qualified to give.
Every language is useful in a different way and each have a domain or two in which they excel at.
The real takeaway is that the shift from knowing one language to another is fairly easy. The real trick is knowing the idioms of the particular language and how to use them.
I learned C64 Basic, QuickBasic, C, Pascal, some Prolog and Lisp, Forth, Redcode (assembly), more Scheme, C++, and Python, Java. (And later Clean and Haskell.) I would not call this an optimal sequence. And it heavily overlapped. E.g. I only really got Scheme after playing around with Python a bit. And for some strange reason, I saw the light of higher order functional programming only when I began with Clean. In Scheme it felt too clumsy.
But what's `optimal' depends on what your goals are. If you happen to be in that part of the population that just can not not program, then you will eventually learn how to do it. Even if somebody locked you up in a dimly lit closed with just a reference manual. Just the amount of fun you will have, and projects you accomplish will vary. I learn programming languages for fun.
Python has a very nice library called PyGame that let's you produce some interactive graphics and sound (i.e. a game) quite fast. It's nicely documented. And in PLT Scheme images are first class objects, you can even embed them in your source code. I looked into Squeak, a smalltalk implementation, once, but it did not click for me.
If I had to start again on the same hardware, I'd spend less time with C64 Basic and tried to get Forth for the C64 or do some assembly there. On modern hardware I'd take Python as the first conventional language, and Haskell or Clean as the first real language. (I am not sure whether I should start with a conventional language.)