Based on our experiences at Filepicker.io we learned that
it is important to delineate the differences when
planning initiatives that drive growth, the amount of
resources needed and the profile of team members required
to drive the initiatives.
I agree that it isn't very well worded but it does make sense.
* There are distinct focus-areas on the business side, just as there are on the coding side
* Identifying the differences helps us figure out what to do, when, and how
That just sounds like advertising & PR. There is a lot more to marketing. To crib the definition from Wikipedia (which sounds pretty close to the one I learned):
Marketing is "the activity, set of institutions, and
processes for creating, communicating, delivering, and
exchanging offerings that have value for customers,
clients, partners, and society at large."
Marketing is used to identify the customer, satisfy the
customer, and keep the customer.
- defining who your customer is (demographics, income, etc.)
- gathering feedback from the customer through surveys
- using that information to iterate on products/launch new products that solve your customers pain points (if half your customers are left handed this will tell you that you need to design your product for left handed people as well)
- packaging and designing how your product will look on the shelves
- defining price points based on the data you gathered from your surveys
Not to be a jerk but it sounds like the author of this post hasn't even taken a Marketing 101 course if he's defining marketing as writing blog posts...
As a startup, the key question that helps prioritize between everything you mentioned is "what activities are hygiene activities, versus what are growth enhancers?". Defining your customer, gathering feedback, iterating on product and packaging all fall under hygiene activities. Meaning-if you dont get them right they will hurt your ability to grow. Pricing the product right and the rest of biz dev, marketing and sales activities are focused on enhancing growth. In a startup, the center of gravity for the hygiene activity is the product team (of course this depends on the type of startups). Thus, the job of the non product folks is getting the product found and getting folks to use the product.
define your customer: use analytics to find out where your visitors are coming from. Is your audience just English speaking or should you internationalize your site? What income brackets is your web app designed to cater to? Lower end 99 cent app? Higher end quality software?
Gathering feedback: Startups can easily email their customers surveys and ask for feedback
Iterate: When you talk to your customers, ask them what they like and don't like about your app. Iterate based on their suggestions
Packaging: Landing page. Having good copy and a strong selling page. Simple sign up flow and an on-boarding plan to help them get started and using your app
Price points: Use surveys and the customer "persona" you defined above to break up your customers into different price brackets and sell them features based off what they want and what they can afford.
1. Generate brand awareness, get people interested in your product and bring in leads/customers (depending whether you're B2B of B2C)
2. One that includes all that, plus the market research necessary to figure out how to do all that stuff
For lots of startups, the second part is really part of the entire product/customer development cycle, where product managers figure out what the customers need and how to talk about it in their language. This leaves the "marketing" people to really just focus on the more narrow definition. But in more traditional businesses, lots of that market research falls under the label of "marketing."
As a guide for hackers, the most important two marketing activites are "getting the word out" and optimizing your funnel from visitor to lead to customer.
There is so much more what falls under the label marketing. From Pricing, Distribution all the way to Data Analysis. I really like the definition posted by mindcrime/AMA's.
Don't get me wrong, I very much enjoy the Filepicker.io blog. I have never used their product, but from their website, API docs, and blog they seem like a well-run startup with a value-adding service.
Nonetheless, they are hurting themselves with such a specific name. It creates the negative perception of "Feature, Not A Company" that Mark Suster talked about on his blog: http://www.bothsidesofthetable.com/2011/08/22/fnac-feature-n...
1. its a known (brand) name
2. it tells where your product is strong
But I suggest to change the Enterprise pricing tag:
1. Don't tell a price for enterprise. Enterprise customers have a high COCA, so price is always negotiation.
2. Offer enterprise features = Your services runs at their servers, under their control, not as a SaaS, but as a normal enterprise software that comes with installation support, consulting, ...
You'd be amazed at how much an enterprise is willing to pay for software, if you have the right niche and are going to make life easier for a bunch of people.
Many in the 'business community' don't understand the differences as well. Not being an ass or making assumptions - I'm speaking from first hand experience here.
you can reduce all NP problems to 3-SAT because 3-SAT is NP complete. you cannot reduce all NP hard problems to 3-SAT. for example, all problems in NP reduce to SUCCINCT-SAT, an NEXP-complete (and therefore NP-hard) set. good luck reducing SUCCINCT-SAT to 3-SAT (despite how little progress in separation of classes we've made, the time hierarchy theorem still indicates this is impossible)
This link has a basic primer http://en.wikipedia.org/wiki/AIDA_(marketing)
Apart from not knowing the exact nomenclature, it's embarrassing if programmers don't know these things. It's pretty much common sense.
But now we know.
So, when will business people understand software development?
No. This is the thinnest sliver of a fraction of what business people think hackers should know about business. See the link above to the "outline of marketing," for example. Just marketing is a huge discipline with a very large body of knowledge... add in distribution, support, finance, business development, sales, etc., and there's a whole world of knowledge that a lot of programmers don't generally have.
Sure, at the 60,000 foot level. But the devil is in the details.
Seriously, as popular as it is for hackers to mock "business people" and MBAs and business school, do you really think that business school doesn't exist for a reason? You think these guys just sit around and spew bullshit at each other all day, graduate, then go on to run successful, real-world businesses?
Business, especially at scale, is fracking complicated. And a successful technology company can't be all about just technology OR just "the business." You really need a holistic approach (which means somebody, or multiple somebodies have to understand the big picture) where technology and the "business side" complement each other.
Ya know, it would almost be fair for the business people to ask "when will software developers understand software development?" We, as a group, still don't do a good job of giving good estimates and delivering things that work reliably without constant hand-holding and patching. But, to be fair, that's often back to ill-defined requirements and unreasonable schedule pressure, which still - IMO - argues for the need for a holistic understanding of what's going on - that is, a shared understanding that's common to the "business people" and the hackers.
In fact, I almost wish we could get away from making the distinction "business people" and "technology people" (or "hackers") and drop the antagonistic, adversarial atmosphere that often seems to exist.
This sounds like programmers need to know a lot about business. Of course knowledge is a light burden and all that, but do really programmers need to know that much outside their area of expertise? Isn't a shallow understanding enough? Otherwise, what would you need dedicated business people for?
> Ya know, it would almost be fair for the business people to ask "when will software developers understand software development?"
Good point! But then again, software development is difficult. It is hard if not impossible to estimate the schedule and cost of creating something that nobody has ever done before. And perhaps that is what the business folks need to understand. The tricky thing as a developer is explaining this without sounding like you're coming up with excuses for being late.
Sorry, my reply was coming from the point of view of "hacker as potential entrepreneur", not "hacker as employee of $FIRM." Yeah, if you're writing code for an existing business, just doing normal "business as usual" stuff, then you wouldn't need to know as much about the details of the business. I would think you'd still be better off with some knowledge of the "business side" of things though.
BTW, I think that there's misunderstanding between software developers and business people because software development is not as much about technology and hard facts as non-developers tend to think. It is very much about organization, people and processes. So in that way, software development is more similar to business than business people expect.
Seriously learn some English man.
The worst part about this is you're arguing that programmers should learn business directly after stating that you argue about business managers not needing to learn programming... Seriously where is your logic sir?
Maybe you can write an article about why you think business managers do not need to learn programming (something I would agree with as a programmer), and make sure you have it edited before posting.
I agree with their points, but overall the article is just a little bit "off". Maybe it's the bit about the integral. If you had a customer pay you $1 every month, and they on average stayed for one month, your LTV is $1, not the integral of 1*x (1/2).
Customer lifetime value is something calculable, even if crudely -- its amortized revenue per customer as retention approaches zero. "Long term value" is more of a concept.
Also, Avinash Kaushik, author of one of the best books on Web Analytic and previous Google Evangelist, uses LTV as well.