AlexBlom

Feel free to shoot me an email (on profile) and I can share details / connect you with some involved.

I'm an Australian who has been in Canada since 2009. The current iteration of the startup visa has some odd restrictions on Canadian capital imo.

You are generally better doing WHP to FSW

Disclaimer: ianal

I went through a similar thing in my first few trips to the Bay area, and ultimately decided to not move there for the same reasons.

I've found subsequent trips to be much easier. Unfortunately, the most vocal and easiest to meet within the community were the most abrasive / kool aid driven. Keep digging.

Link is down. Cached page at: http://webcache.googleusercontent.com/search?q=cache:ybdWn7-...

tl;dr: most feedback on twitter ads assume it is intent driven (i.e. google adwords), when in most cases it is not.

IMO, it's the root of many social companies struggle to monetize with ads. We've been spoiled the last while because we knew what people were looking for, and could promote directly against that. In some ways, social ads are a step backwards from this.

The 4 and 7 has been an ongoing debate among marketing academics, it seems. I recall the "right" answer alternating course by course through school, pending the professors interest.

If I recall, the 4 P's are the standard marketing mix, with the 7 P's being called the extended marketing mix. FWIW, the 4 was definitely more central at my school.

On top of this, once the coding starts, too many languages focus on command / effect (note: not cause / effect). This is arguably fine for basic looping and data structures.

The problem is I see this knowledge break when 1) it is applied to a more difficult problem that 2) is outside of the scope of the provided loop.

Spending time understanding the conceptual elements (when, where, why) before the how doesn't give immediate results, but it saves many headaches down the road and makes future tools / languages much easier to learn.

Thanks for organizing, Dave.

I think you make some valid points, and as somebody who self-taught, I get the pain. That being said, I also agree with the common sentiment here "help yourself a little first".

If you consider yourself a technology company, you need an understanding of your technology and what goes into making it. You may not be a master at each part, but you need _something_. It doesn't mean you are not marketing, but like marketing a technology implementation has several nuances that can't be overlooked. Tension always arises when these aren't well understood. Times this problem by 10 if you want "magic" / algorithms which little concept of how they will work (note: you don't need computing studies to figure this out, generally).

Note that I said 'consider yourself a technology company'. There are many companies based on technology that are not, themselves, technology companies (you can argue either way whether this is the right model, but it works). From my experience, these are the companies hunting less for technical co-founders (and who have less excuse for no traction pre product).

I found the SEE (free Stanford) courses to be best: http://see.stanford.edu/see/courses.aspx

I'm unsure this is true anymore. If you know how to play B2B (the same lies true for B2C), it's entirely plausible to get the first 1-5 deals pre-build (I did).

If you consider that equal to the first traction burst in B2C, then I'd argue that the ambiguity for B2C is just as large, if not larger, in the early days.

It is my no means an overall risk / reward inflection point (and if you are referring to 'this company is guaranteed to exit' I agree), but as an early 'this might have something' B2B can validate fast.

I'm unsure the perception of B2B among VC's is as bad as commonly thought.

My last startup was pure B2B, and during our valley runs I found most potential partners / vc's / workers were very excited (in part because of the opportunity, in part because of perceived market movements, and in part because B2B can be fun) at the prospect of growing in B2B.

B2B companies may not spawn a media darling, but it doesn't make the business itself unsexy.

Thanks Yoseph

Hi, just to address, there are two options I'm working on at this point:

1) App-less (just changed your contact settings); and 2) I am tinkering with some local app stuff for the folks who want it.

The focus right now is 1), but the point of getting out so early is to validate these assumptions.

Thanks for the feedback / questions.

Good call. Would love to see it integrated.

Perhaps I mis-spoke above. An issue can be associated with multiple tickets, just as a ticket can be associated with multiple issues. The latter is not beefed as much in the code, as I found the use case to be less once live.

Appreciate the feedback. Will see how often this is reported. The fading is also handled in the main JS file, so you can disable it there.

I'll admit there is not much logic here. Was not needed for my use case. Feel free to contribute it, though!

Sure. You create a support e-mail. Customers send to this e-mail, and tickets are auto-created.

Hi. I may flesh it out, but I've also opened up the software. If you have extension ideas, please feel free to fork / contribute. You can flip me an e-mail (my first name @ my HN username . com) if you want to go further, or flip a note on Twitter.

An issue has a one to many relationship with tickets. I built it, as I found I'd get many tickets about the same thing from different users. I wanted to be able to focus on solving the macro issue and not manage many issues. Terry Smith is one of the thinkers behind it.

Thanks. It's easy to keep things simple when you are building for my use case, which was rather basic.

That being said, I see the value of tagging. Perhaps a future addition.

Demo is up (loaded with some of my testing data, so no real guarantees):

www.ticketdesk.co [email protected] 123456

I've disabled much of the cron / emailing.

For my use case it's fine. If the software was going to be commercial, this module would be the first to need beefing. I've toyed with re-running delayed jobs, but this setup has worked for me (Micro EC2 instance).

Fair. I've got an EC2 instance booting up right now.

Is anybody else getting "Sorry! This document is not publicly available."?

Eh. Yes and no, sales is a different beast. I'm not saying it should be, but it generally is. If you judge your sales process like your technology process (without building the right culture), you're readying yourself for a mighty flop.

By nature, the more high-contact sales people are the stronger the personalities. Documenting and tight record management just don't come naturally, and unlike engineering, are generally considered immaterial to the roles. Sales resources are hired, fired and incented by sales, and the good ones will focus only on what will help increase their sales in. Again, I see startups always overlook the dynamic and motivations they are creating, and then wonder why it didn't work out.

I'm reminded of some of the larger sales forces (fortune 50) I've interacted with. The running joke is that the sales people with the best documentation should be fired, as their sales would be the lowest. 9/10 times, this turned to be true.

I agree it's easy to reproduce. Not an easy problem by any measure.

Putting in my credit card (or revealing any information I don't deem relevant to the company / form) is always an immediate deal breaker. For Yelp, a critical mass of reviews is needed, I'm not sure they can afford that.

Agreed. As somebody who has self-taught / is self-teaching, many of the guides become very complex very quickly. I'm fine with that now. At the start it was a frustrating experience, and I'm one of the people who wikipedia's everything he doesn't know.

There's no problem with books set for different levels. In-fact, I hate those beginner books now as they move too slow. The issue I see is most publishers incorrectly bucketing their guide as beginner-level, and either going too deep too fast or writing code without explaining the mechanics.

I've seen many people get frustrated, lost and give up as a result. You can argue they didn't have the mind / passion for this type of work, however I observe many people who stop before they get started.